TYPO3 Core

Hi Claus,
first things first. I totally agree with you.

But I have a question, just because I don't know better. How do we force to have several TS active without letting the user activate it?
There are some settings, that need always to be set. e.g. in Extbase. How do we do this? Immediately switch to always loaded YAML?

Please drop some lines here.
Thanks.

Hi Alex,

Regarding the question: t3lib_extMgm::addTypoScript allows adding TypoScript, as string (supporting INCLUDE if that's your poison of choice) that's always loaded. That being said, as much as possible of this should ideally not be enforced but should, like css_styled_content, be something you include using static TS templates. I don't think the solution is to switch to YAML (major break in upgrade process) but rather use an approach that's built on the correct API, subsequently attempt to clean up a bit in what's actually necessary to force-include...

Allowing the integrator to control this allows us to build TYPO3 sites with much better performance when we can for example cut the size of the TS before even including it - rather than unsetting (with some blockers as noted in #22169 fx) which just causes unnecessarily wasted CPU cycles. After all, TS accounts for somewhere around 50% of the processing required to render a completely blank TYPO3 site and it only gets worse the more you add...

Ideally, TYPO3 would ONLY use static TS templates that need to be included - but would include them in a root TS template created during the install process, depending on which extensions were enabled.

-1.

This feature (ext_typoscript_setup / ext_typoscript_config) must stay. It is the only chance to force loading of some TS, without fiddling with DB stuff. This makes it very convenient for deployment issue if used wisely.

BTW: Where exactly is this deprecated in the core? This should be rolled back.

As Christian wrote before - this is a main feature to give extension authors the possibility to add needed TypoScript from the beginning.

• Using Static Template (this will lead to a fatal error, if FE of your extension is opened without static template)
• Inject with PHP (why the hell for some lines of TypoScript?)

-1 from me

The actual Extension builder uses it.

It is the only chance to force loading of some TS, without fiddling with DB stuff.

Plain wrong. Just above, I gave you all the example on how to do this. There is also a hook for it which I neglected to mention: $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tstemplate.php']['includeStaticTypoScriptSources'].

This makes it very convenient for deployment issue if used wisely.

Same thing with an inclusion statement in PHP or a hook subscriber. It can also point to a file. It can be included automatically. And that approach has the added benefit of not being deprecated for eight years. Why am I even arguing about this, seriously? You should know these things!

BTW: Where exactly is this deprecated in the core? This should be rolled back.

No, it should not be rolled back. Instead, you guys should keep track of deprecated stuff an avoid using it - regardless of how convenient it makes your deployment. It was deprecated for a reason and that reason is that TS is completely uncontrollable after it has been included this way. Do not roll back. Instead use your API as it should be used!

https://git.typo3.org/Packages/TYPO3.CMS.git/blob/HEAD:/typo3/sysext/belog/Classes/Controller/AbstractController.php#l98 (written by you yourself, Christian, nonetheless!)
https://git.typo3.org/Packages/TYPO3.CMS.git/blob/HEAD:/typo3/sysext/beuser/Classes/Controller/BackendUserController.php#l92 (by Felix Kopp, same verdict - "nasty", needs alternative, etc.)

And here's the nasty condition it takes to control whether ALL ext_typoscript_setup.txt files get loaded before or after the current template - but that's all the control you get; if set incorrectly you get NO control whatsoever:

https://git.typo3.org/Packages/TYPO3.CMS.git/blob/HEAD:/typo3/sysext/core/Classes/TypoScript/TemplateService.php#l753

You yourself call this feature "nasty", Christian, and you call for an alternative, of which I've just now given you TWO. Yet you want the deprecated and "nasty" feature reintroduced and its use encouraged.

I could not find the actual deprecation notice - only a mention of it around when it happened and yet another suggestion for an alternative approach: http://typo3.toaster-schwerin.de/typo3_english/2005_07/msg00249.html.

As Christian wrote before - this is a main feature to give extension authors the possibility to add needed TypoScript from the beginning.

No, plain wrong. Don't you read what I write and the issues linked? You're really frustrating me right now. Two people not understanding the issue at hand, yet voting it down and arguing against it.

Using Static Template (this will lead to a fatal error, if FE of your extension is opened without static template)

This is why you ask the integrator to include the template instead of forcing your huge chunk of TS on him. To do so, use the already explained alternatives which allow the exact same degree of version control an deployment friendliness - without being deprecated. Don't just throw it all in there - try to think about what REALLY makes sense to enforce and stick to just that; make the rest optional!

Inject with PHP (why the hell for some lines of TypoScript?)

Why the hell create another file for some lines of TypoScript?

I don't get you guys, I just don't.

The actual Extension builder uses it.

Yes, hence the "continually encouraged" argument I started out with. Too many official sources use this bad practice and this should be stopped.

@Claus
I get your point and agree as its another layer of TS magic and hardly controllable but I think we, sadly, need another deprecation period. Aa you stated this feature seems to be deprecated since I've started with TYPO3 -- an I never noticed its deprecated. A lot (!) of extension rely on this so we need to make sure everyone has time to upgrade.

https://git.typo3.org/Packages/TYPO3.CMS.git/blob/HEAD:/typo3/sysext/belog/Classes/Controller/AbstractController.php#l98 (written by you yourself, Christian, nonetheless!)
https://git.typo3.org/Packages/TYPO3.CMS.git/blob/HEAD:/typo3/sysext/beuser/Classes/Controller/BackendUserController.php#l92 (by Felix Kopp, same verdict - "nasty", needs alternative, etc.)

These are both no deprecation notices for ext_typoscript_setup.txt in my opinion but for Extbase needing TS to work.

I could not find the actual deprecation notice - only a mention of it around when it happened and yet another suggestion for an alternative approach: http://typo3.toaster-schwerin.de/typo3_english/2005_07/msg00249.html.

So I guess it never was officially deprecated? What about that mentioned notice in the doc?

Easy to use? Sure. Impossible to handle? That too, that too...

ext_typoscript_setup.txt is convenient to add default typoscript, yes, but the major problem of this is that it is loaded AFTER static templates, which means "My default configuration will override the one you choosed to load".
In the other hand, t3lib_extMgm::addTypoScript allows to load our "default typoscript" where we need it (so, just after css_styled_content)

I'd say, let's get rid of this old broken legacy thing, then we will be able to think about a real and clean replacement of it (guess what, there's already some replacements out there), if t3lib_extMgm::addTypoScript is still too hard to use for some Extbase folks.

It's not evident and not fully controllable magick. I prefer to use PHP to control the process. And I vote to move the core configuration into standalone TypoScript files.

Look on the content of beuser's ext_typoscript_setup.txt :

    <INCLUDE_TYPOSCRIPT: source="FILE:EXT:beuser/Configuration/TypoScript/setup.txt">

We could do the same include with PHP and it should work, isn't it ?

Core should be as much simple and clean as possible.

The bug is the deprecation notice, not the feature of ext_typoscript_setup.txt itself.

It is useful to add default TS. It is way simpler than using some PHP-API or hook for the simple (and valid use case) of forcing some TS-setup to be loaded without any further user interaction. I am fine if there is an adaequate replacement, but just dropping it because it causes some problems in some circumstances is not a reason for removal.

Greets,
Peter
<TYPO3 since 2000/>