TYPO3 Core

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618

if ($cc = $this->getCurrentPageData()) {

also delivers the page data if the page is called with &no_cache=1, while

if ($GLOBALS['TSFE']->all) {

doesn't. I'm not sure if that behaviour is a problem.

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618

My stomach feeling is that this is not the right solution, because this particular API is not intended to be used that way. This is expected to be called from the frontend context only and thus having a working and reliable TSFE set up.

Since Extbase needs this in the backend, I think the least disturbance in this area would be to improve on the "dummy-TSFE" creation process in Extbase to make sure TSFE->all is also available for later caching.

Just a random thought without digging concretely into the code. I fear that we cannot predict the side effects of the proposed patch so far.

Hey Ernesto,

i updated the code accordingly. At the moment there is no "dummy-TSFE" in backend context, but I think it's allright to set up TSFE->all for this.

At the moment it simply does not work, because of the blocking issue #54813.

So we will have to fix that first.

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618

Actually this patch now has become an extbase-only patch. :) so someone might just move that ticket ...

Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618

Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618

Patch set 9 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618

Patch set 10 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26618

First of all: thanks to all of you for commenting. I would like to move the discussion from gerrit to forge to keep some overview.

Alexander Stehlik
This is definitely a breaking change. Before the templates included in the first root page were loaded. Now they are not available any more.

That is right. I am not entirely sure, but I think this was wrong in the first place. In a module without pagetree no page is present and thus no TypoScript from the pagetree should be loaded.

Benjamin Mack
can we also please get rid of the constant and the function "getDefaultBackendStoragePid()" as well in order to keep the code clean?

Oliver requested this constant and I thought it might make sense to use it instead of writing some magical integer into the code.

Removing the method would need some more inspection. I think it's there between some interface-dependency and difference between backend- and frontend-configurationManager.

If we still need this number, we should keep it as a constant instead of a magic number. Magic numbers are no-gos as far as readability is concerned.

Oliver Klee wrote:

If we still need this number

We will - anyway - need it, yes. ;)

I think Marc Bastian Heinrichs' idea is also quite interesting for generating the configuration in the Backend (quote from https://review.typo3.org/26675/):

I would like to see this change reverted and have a better solution than having to use ext_typoscript_setup.txt, which is inofficially deprecated since ages. E.g. "registering" the backend context page id for a separated module where the typoscipt is integrated. By this solution the TS for BE and FE is separated and could be parsed in the single context.

Basically the only configuration that is independent from the Pagetree is Extension configuration or LocalConfiguration.

As far as I can see we have these contexts where we do not have a PID:

• Scheduler tasks
• Backend Modules without Pagetree
• Command line controllers

So what I suggest are two possibilities to influence the building of the TypoScript from the Pagetree in these cases:

1. add an Extension setting (for the ExtensionManager) where a default PID can be set from which the configuration for pageless contexts should be build (maybe there can be one setting per case - scheduler, Backend Module, Command line?)
2. allow passing the PID from which the configuration should be read to the ConfigurationManager so that Extensions can provide their own way to determine the PID from which the configuration should be build.

I'm looking forward to your feedback.

The new solution for all the frontend typoscript hassle in backend modules should also have in mind getting rid of all the ext_typoscript_setup.txt files in core backend modules, which need to work also without a pagetree.
So we should discuss, if also registering a typoscript file directly for backend modules could be a way to handle this.

Because atm all the typoscript from the ext_typoscript_setup.txt files in core backend modules are parsed and available in frontend without need.

Marc Bastian Heinrichs wrote:

So we should discuss, if also registering a typoscript file directly for backend modules could be a way to handle this.

I like this idea! Alternative would be to assume a certain location for extbase extension backend TypoScript-Configuration, e.g. Configuration/Backend/Module.ts
We could then load and cache the configuration for all modules of one extension.

Because atm all the typoscript from the ext_typoscript_setup.txt files in core backend modules are parsed and available in frontend without need.

Agreed.

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26876