Bug #103364
open
Site config settings can't be used to override constants anymore
0%
Description
Before TYPO3 12 it was possible to have recursive constants, which made it possible to set TS constants to values defined in the site config settings.
I get that the (undocumented) 10-step-recursion-resolving had to go. So no argument with that. But I'd like to find a solution for the evident drawback I'm facing now.
As soon as I include an extensions TypoScript (that is constants+setup, with constants usually set to empty values), it's not possible to override those constants with "site constants" anymore.
A workaround could be to override those parts of the setup (where the constants are being read) and change the name of the constants! Since variables are often being used in multiple parts of the setup stack that cannot be the solution.
Take this (randomly chosen) snippet from EXT:powermail's TypoScript setup:
plugin.tx_powermail.settings.setup.main.pid = {$plugin.tx_powermail.settings.main.pid}
In order to override that setting I would have to change the TypoScript setup to this e.g.
plugin.tx_powermail.settings.setup.main.pid = {$plugin.tx_powermail.settings.main.pid_override_from_site}
And add this new constant to the site config:
settings:
plugin:
tx_powermail:
setup:
main:
pid_override_from_site_config: 123
Here's a screenshot of how the constant stack is being put together:
With TYPO3 11 one simply had to set the extension's constant to the custom constant (and it's been resolves correctly) while the extension's setup could remain untouched.
plugin.tx_powermail.settings.main.pid = {$plugin.tx_powermail.settings.main.pid_override_from_site}
Files
Updated by Philipp Kitzberger about 2 months ago
- File Bildschirmfoto vom 2024-03-11 18-36-54.png added
- Description updated (diff)
Updated by Christian Kuhn about 2 months ago
- Related to Feature #97816: New TypoScript parser added
Updated by Philipp Kitzberger about 2 months ago
- File deleted (
Bildschirmfoto vom 2024-03-11 18-36-54.png)
Updated by Philipp Kitzberger about 2 months ago
Updated by Stefan Bürk about 2 months ago
You already described what to do - set your custom constant setting in the TypoScript SETUP to your constant (from SiteConfig).
Not tested, but maybe it works also if you use the "powermail" default constant name in the SiteConfig ?
Updated by Philipp Kitzberger about 2 months ago
· Edited
Stefan Bürk wrote in #note-7:
You already described what to do - set your custom constant setting in the TypoScript SETUP to your constant (from SiteConfig).
That's not a good solution, it's merely a workaround. The whole purpose of constants is that they can be adjusted once and affect multiple (unknown) parts of the setup where they're being used.
Not tested, but maybe it works also if you use the "powermail" default constant name in the SiteConfig ?
As I've mentioned above, that isn't working as soon as a extensions static TS has being included. Because this then overwrites the constants with "" ;-(
Updated by Christian Kuhn about 1 month ago
· Edited
I've had a look at this issue together with Benjamin Franzke, who is currently working on a revamped 'settings' API:
This is essentially a load-order issue that stems from the situation that site settings 'constants' are loaded first, and extension includes afterwards. The v13 works in this area will lead to the situation that sites define such extensions TS like powermail as 'dependencies', will load them first, and afterwards 'overload' with own (site specific) settings. (This will also allow instances without sys_template records).
However, there may be an additional solution (but I did not had a look if that could be implemented easily): We could implement a TS 'function' that does this: "some.constant := ifNotDefined(42)" Thus, a TS function that says "set this constant to a default value, if not yet set". A "late default", so to speak. Extensions like powermail would then have to be changed to actively use this, though. But it would resolve your scenario.
Updated by Philipp Kitzberger about 1 month ago
· Edited
Christian Kuhn wrote in #note-9:
However, there may be an additional solution (but I did not had a look if that could be implemented easily): We could implement a TS 'function' that does this: "some.constant := ifNotDefined(42)" Thus, a TS function that says "set this constant to a default value, if not yet set". A "late default", so to speak. Extensions like powermail would then have to be changed to actively use this, though. But it would resolve your scenario.
I'd prefer an alternative approach to this, mainly because it's unlikely that all extension authors will change their TS to use that new function.
So what about the other way round?
some.constant := overrideWithSiteSetting(some.constant)
That way an integrator could do the following:
- Include an extensions TypoScript (constants + setup)
- After that: modify that extensions constants
- either by setting it to a hard coded value (like always)
- or by setting it to the new
overrideWithSiteSetting()function to basically explicitly allow TS constants being set in the site settings
For example:
@import 'EXT:powermail/Configuration/TypoScript/Main/constants.typoscript'
plugin.tx_powermail.settings.main.pid := overrideWithSiteSetting(${plugin.tx_powermail.settings.main.pid})
On some deeper level of the page tree, it'd be still possible to override that constant of course:
[page|uid = 3] plugin.tx_powermail.settings.main.pid = 123 [global]
This would basically be a comeback of the former recursive voodoo but explicitly used and much cleaner.