Bug #103953
closed
Site config settings can't be used in TypoScript conditions anymore
100%
Description
TypoScript conditions generally support the usage of constants.
But with the refactoring of the TypoScript parser in version 12 site constants cannot be used anymore!
- Add a constant to a site's
settings.yamlfile - Create a condition based on it
[{$foo} == 'bar']
page.20 = TEXT
page.20.value = the site constant "foo" is "bar"
[global]
For a constant set in regular TypoScript constant files or sys_template records it's still working though.
Files
Updated by Philipp Kitzberger about 1 month ago
- Related to Bug #103364: Site config settings can't be used to override constants anymore added
Updated by Philipp Kitzberger about 1 month ago
- Related to Bug #102452: TypoScript constants from site settings are not substituted in Backend Extbase Modules added
Updated by Philipp Kitzberger about 1 month ago
- Related to Feature #97816: New TypoScript parser added
Updated by Philipp Kitzberger about 1 month ago
Just found out that accessing that same constant via the site configuration is a working workaround:
[traverse(site("configuration"), "settings/foo") == "bar"]
Updated by Christian Kuhn 26 days ago
ยท Edited
tl;dr:
broken:
[{$foo} == 'bar']
working:
['{$foo}' == 'bar']
Long story: I played around on this in v12 again:
- Create a root page
- Have a site settings.yaml parallel to config.yaml is the site config folder of that new site, with this content:
foo: bar
- Create a root TS template on the page with this setup content:
page = PAGE page.10 = TEXT page.10.value = HELLO WORLD! page.20 = TEXT ['{$foo}' == 'bar'] page.20.value = the site constant "foo" is "bar" [else] page.20.value = the site constant "foo" is NOT "bar" [global]
- Go to TypoScript BE module "Included TypoScript".
- Look at the "Constants" "Configuration" tree and see there is a node "Site constants settings of site "..."". Clicking the {} button should show you the 'constant' foo being set to bar -> the site setting is turned into a constant.
- See the condition being listed in the "condition" section, with its value being updated to bar. See screenshot, too.
- Call FE and see condition kicks in.
- Change the constant value in settings.yaml from 'bar' to 'baz', and see the condition no longer kicks in in FE and [else] branch is rendered.
Your example above uses
[{$foo} == 'bar'], but it should be ['{$foo}' == 'bar']. I rechecked this in v11, and the condition does not work in v11 with the missing ticks, either, but does works if the constant is surrounded by ticks.
-> Using site settings as constants in conditions does work, imho. Could you recheck, please?
Updated by Christian Kuhn 26 days ago
Updated by Philipp Kitzberger 26 days ago
Using site settings as constants in conditions does work, imho. Could you recheck, please?
Yes, your workaround (wrapping the constant in quotes) does work in setup conditions, but not in constant conditions. The latter is probably due to the fact that constants are not being resolved recursively anymore, right?
My workaround is working in both setup and constant conditions:
[traverse(site("configuration"), "settings/foo") == "bar"]
Updated by Christian Kuhn 25 days ago
- Status changed from Needs Feedback to New
I see. Yes. Accessing constants does not work within constants at all, and as such, not in constant conditions, either.
We may want to clarify this in the docs.
Updated by Gerrit Code Review 25 days ago
- Status changed from New to Under Review
Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/84497
Updated by Gerrit Code Review 25 days ago
Patch set 1 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/84460
Updated by Christian Kuhn 25 days ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset e2ccdaa1a6c2e7d7f66e570ef1006b4ac75934e5.