Feature #92979
closedMissing 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 about 4 years ago
- Target version changed from 11.0 to Candidate for Major Version
Updated by Christian Kuhn over 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 over 2 years ago
- Related to Feature #97816: New TypoScript parser added
Updated by Markus Klein almost 2 years ago
- Related to Bug #92528: TypoScript site constants not always populated added
Updated by Christian Kuhn about 2 months ago
- Status changed from New to Closed
Hey. I'm going to close here for now: We can not change this behavior since it would be heavily breaking - we have to keep the fallback to the string literal in case the parser finds a constant that can not be resolved. Having a warning in the backend modules about such unresolved constants can go to a new issue when it is implemented.