TYPO3 Core

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 ?

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 "" ;-(

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.

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})

[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.