Bug #55028

Static TS must be available even when there is no page UID

Added by Claus Due over 1 year ago. Updated over 1 year ago.

Status:Closed Start date:2014-01-15
Priority:Should have Due date:
Assigned To:- % Done:

100%
Category:Extbase Spent time: -
Target version:6.2.0
TYPO3 Version:6.2 Is Regression:No
PHP Version: Sprint Focus:
Complexity:easy

Description

Commit ba2386e7305e0d6e64db5cc485bc38728728ad8e https://review.typo3.org/26675 must be reverted - it destroys Extbase operability under the following criteria:

  • Editing any record (pid is not set).
  • Using any BE module that does not use the page tree.

Before, Extbase would look for the first root template. Felix removed this behaviour completely, replacing it with a raw $_GET['id']. This should be considered a HUGE breaking change for any third-party Extbase extension that operates in the BE without using a page tree. As such, it should not be allowed in the LTS.

Core extensions are not broken by this simply because they abuse the ext_typoscript_setup.txt pattern to load (massive) amounts of TS that cannot be controlled.

Related issues

related to Core - Task #54701: Cache global TypoScript template in backend New 2014-01-02
related to Core - Task #54813: BackendConfigurationManager figures out wrong pid New 2014-01-07

History

#1 Updated by Anja Leichsenring over 1 year ago

Discussion goes here: http://forge.typo3.org/issues/54701
Please comment there.

#2 Updated by Marc Bastian Heinrichs over 1 year ago

  • Category set to Extbase
  • Status changed from New to Closed
  • Target version set to 6.2.0

Patch is reverted.

Claus Due wrote:

Core extensions are not broken by this simply because they abuse the ext_typoscript_setup.txt pattern to load (massive) amounts of TS that cannot be controlled.

But you would even have the same with typoscript on pid 0. But this is another story and should be discussed somewhere else.

Also available in: Atom PDF