Feature #92979
open
Missing TypoScript constants are treated as strings
0%
Description
This has probably been the behaviour of the TS parser since forever, but IMHO it is very confusing.
When a TS constant is not defined, it is treated in the setup as a string.
This causes various hickups, since conditions "if a constant is defined" don't work, any other usages like in TEXT values etc. also just output the constant name as a string.
The condition documentation only shows usecases with comparison to integers or strings, and these usecases are covered, since the value is the constant string itself. But there is no way to simply check for the existence.
https://docs.typo3.org/m/typo3/reference-typoscript/master/en-us/Conditions/#constant
If i only need the constant in e.g. one language, i have to first initialize it with an empty value, then it can be set in the condition.
Now it is always replaced and i can check the constant to be empty or filled. IMHO it should always be empty in the TS if it is not defined.
Updated by Benni Mack over 3 years ago
- Target version changed from 11.0 to Candidate for Major Version
Updated by Christian Kuhn almost 2 years ago
- Tracker changed from Bug to Feature
- TYPO3 Version deleted (
9)
We can't change that, and i decided in the new TS parser in #97816 to NOT change this behavior, either:
The problem is that values (especially in multiline assignments) can be JavaScript which kinda often comes with a {$...} char combination. The TS tokenizer MUST treat them as possible constants, and if they can't be resolved, they should fall back to their string literal.
What we maybe could do, is showing a warning in the backend object browser, if an attempt to resolve a constant failed. This would make this request a feature of the object browser.
Updated by Christian Kuhn almost 2 years ago
- Related to Feature #97816: New TypoScript parser added
Updated by Markus Klein 12 months ago
- Related to Bug #92528: TypoScript site constants not always populated added