Bug #99377
closed
Constant substitution not working
0%
Description
Using the following typoscript constants
test {
a = Hi
b = {$test.a} everybody
}
with the following typoscript setup
page.1 = TEXT
page.1.value = {$test.b}!
produced until TYPO3 v11 the following output:
Hi everybody!
With TYPO3 v12.1 the substitution from a constant used in a constant doesn't work any more and as a result the following will be rendered:
{$test.a} everybody!
Updated by
Updated by Christian Kuhn about 2 years ago
- Status changed from Accepted to Rejected
I'm afraid v12 does not support constants in constants. This has been documented as breaking:
Recursive constants were possible with the old parser but are not supported with the new parser anymore. This was never documented, the Backend Template module never showed them as resolved, only the Frontend parsed recursive constants. The simple rule is now: Never access a constant within another constant. Instances using a construct like the below one need to untie constants.
constants:
foo = fooValue
# This does not resolve to "fooValue" but is kept as string literal "{$foo}"
bar = {$foo}
Updated by Christian Kuhn about 2 years ago
- Related to Feature #97816: New TypoScript parser added
Updated by Christian Kuhn about 2 years ago
It might be possible to scan for this in my upcoming syntax checker, though. the "template analyzer / Include tree" will then show such violations.
Updated by Kay Strobach over 1 year ago
Ok, where would you kick in to solve that? we have tons of projects using that functionality and this will cause have hefti migration problems.
Updated by Ingo Fabbri 2 months ago
Kay Strobach wrote in #note-5:
Ok, where would you kick in to solve that? we have tons of projects using that functionality and this will cause have hefti migration problems.
I fear this will cause us problems as well. We have been using the feature described in this documentation (https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/10.4/Feature-91080-SiteSettingsAsTsConstantsAndInTsConfig.html#feature-91080-site-settings-as-typoscript-constants-and-in-tsconfig) since it was introduced in TYPO3 v10.
Until now, it was no issue to use constants (generated from site settings) within TypoScript constants. This allowed us to reference the constant from the constants template in the plugin's TypoScript, as usual. In the constants template, we could choose to either set a value directly or inherit it from the site settings.
This no longer works, and the change is not clearly documented. The reference to this breaking change (https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-97816-TypoScriptSyntaxChanges.html#streamlined-constants-usage) feels incomplete and insufficient.
Regarding documentation: as a typical TYPO3 integrator, I would never have thought of using constants within constants. This "supposedly undocumented" possibility only became apparent to me through the introduction of the site-settings constants feature: Feature #91080 (https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/10.4/Feature-91080-SiteSettingsAsTsConstantsAndInTsConfig.html#feature-91080-site-settings-as-typoscript-constants-and-in-tsconfig).
It was only through these site constants that I even got the idea (albeit unintended) to use constants within constants. However, I never perceived these site-settings constants as "real" constants. For me, it was more like an "automagic" injection of site settings for use in TypoScript. There was absolutely no indication—ever—that these site-settings constants were only to be used in the TypoScript setup. The communication always referred to "TypoScript."
We’ll manage and will likely have to swallow this bitter pill during the upgrade to TYPO3 v12 by migrating these site-settings constants into the TypoScript setup. However, it’s frustrating because:
a) The breaking change was, in my opinion, poorly and non-transparently documented in the changelog.
b) This increases the upgrade effort unnecessarily.
No offense, but breaking a feature introduced in v10 already in v12—without proper warning—feels off. Justifying it with "new TypoScript parser; your fault for misunderstanding; and our TYPO3 documentation, which, of course, documents 100% of all TYPO3 functionality in excruciating detail (sarcasm alert), never explicitly mentioned this feature, so tough luck. Bye!" leaves a bitter aftertaste.