Bug #101523
closed
Config `page.config.headerComment` can not resolve TS constants anymore
0%
Description
Since Typo3 v12 the config `page.config.headerComment` can not resolve TS constants anymore. They will be printed as raw strings like "{$constantName}".
With v11 and before this was possible.
System:
- Typo3 v12.4.4
Updated by Christian Kuhn 9 months ago
- Related to Feature #97816: New TypoScript parser added
Updated by Jasmina Ließmann 9 months ago
- Status changed from New to Needs Feedback
I cannot reproduce this problem. Tested with the v12.4.6-dev.
My test setting:
Placed a TypoScript record on a page with constant site.headerComment = XY company and as setup page.config.headerComment = {$site.headerComment}.
This works for me as the constant is replaced in the source code.
Updated by Julian Mair 9 months ago
Thank you both for your investigation.
It was odd to me that this works for anyone but me. So i looked at it again and found out, we used nested constants – not just single ones. (Sorry, I didn't mentioned that)
Minimal steps to reproduce:¶
Constants:
normal = World
nested = Hello {$normal}
Setup:
page.config.headerComment = {$nested}
Current output:
Hello {$normal}
Wanted output:
Hello World
Updated by Riccardo De Contardi 9 months ago
I am not sure that it is even supposed to work at all... Can't find anything in documentation that could confirm that it's possible...
Updated by Julian Mair 9 months ago
well, we used this "undocumented" feature since at least Typo3 v7. It was always there... till a new TS parser was introduced :)
It would be a pity if we can't use this anymore... the upgrades to v12 won't be fun then.
Updated by Riccardo De Contardi 9 months ago
- Status changed from Needs Feedback to New
Updated by Riccardo De Contardi 9 months ago
- Status changed from New to Needs Feedback
Ok, I've found it:
It looks like the old behavior you describe is no more possible.
Updated by Simon Schaufelberger 9 months ago
The old nested way was so dirty that Lolly decided to drop it as it was also never officially supported.
You can use constant variations and then do a switch in the setup.
What is the reason why you used nested constants actually?
Updated by Julian Mair 8 months ago
That's a pity...
We use them throughout the whole projects, e.g.
name = Company Name
company_type = GmbH
slogan = Whatever slogan you want
copyright = {$name} {$company_type} | {$slogan}
#> we use this constant in meta tags and footer
# --- --- ---
legal_menu := addToList({$pids.imprint})
legal_menu := addToList({$pids.privacy})
legal_menu := addToList({$pids.sitemap})
#> we use this constant in menu processors or TS conditions to exclude those ids
# --- --- ---
breakpoints {
# ...
tablet = 1024
phablet = 767
phone = 480
phone_small = 350
# ...
}
mq {
# ...
tablet = (max-width: {$breakpoints.tablet}px)
phablet = (max-width: {$breakpoints.phablet}px)
phone = (max-width: {$breakpoints.phone}px)
phone_small = (max-width: {$breakpoints.phone_small}px)
phablet_asc = (min-width: {$breakpoints.phablet_asc}px)
phone_asc = (min-width: {$breakpoints.phone_asc}px)
# ...
ranges {
# ...
xs = {$mq.phone}
s-no-xs = {$mq.phablet}
s = {$mq.phone_asc} and {$mq.phablet}
m = {$mq.phablet_asc} and {$mq.tablet}
# ...
}
}
#> we use this constants in TS and fluid to define media queries centrally
Those are only a few of which we are using. The upgrades to v12 would be horrific without this feature.
If we can make this working again, that would be really, really cool.
Updated by Christian Kuhn 8 months ago
- Status changed from Needs Feedback to Rejected
Hey.
There are various reasons to not implement this in core anymore. One main reason is that I did not find an acceptable simple solution to implement this better than "O(m) * O(n)" with m being the substitution depth and n the number of nodes in the tree.
I know Kay Strobach (find him on slack) faces a similar issue in a project, and I talked with him about options to add this as an extension when the performance penalty has to be accepted due to refactoring trouble. Maybe ping him to find out if he came up with something or to join forces?
At the moment I'll close here: The issue went into a different direction (from "config.x does not deal with constants" to "nested constants are impossible"). The latter is documented well and known as such. In case anyone could come up with code that solves nested constants in a quick and non-ugly way, we could look at this in a fresh issue (which can be linked to this one).
Updated by Julian Mair 8 months ago
This is unfortunate... but I understand. Will try some things, maybe I find something.
Thank you for your explanation and time.
Updated by Georg Ringer 8 months ago
- Related to Feature #101752: Add event to the Typoscript FE Controller to let the users replace nested TS constants added