Bug #92528
closed
TypoScript site constants not always populated
0%
Description
Under unknown circumstances it happens, that TypoScript constants are not populated from site constants (see for feature reference here https://forge.typo3.org/issues/91080).
I did not find out why this happens until now - but did not dig into deep. Needs some investigation how and why this can happen.
Files
Updated by Anonymous over 3 years ago
- Related to Feature #91080: Populate site settings to TypoScript constants added
Updated by Česlav Przywara about 3 years ago
I might have the same problem with Page TSconfig. I have a following snippet in Page TSconfig (where $pids.styleguide is configured via site settings):
[{$pids.styleguide} in tree.rootLineIds]
TCAdefaults.pages.no_index = 1
TCAdefaults.pages.no_search = 1
[end]
The condition works great when I create new pages via List module. When I view PageTS config via Info module the condition also works as expected. But as soon as I switch to Page module and just click around, I'm getting following errors in log:
[ERROR] component="TYPO3.CMS.Backend.Configuration.TypoScript.ConditionMatching.ConditionMatcher": Expression could not be parsed. - {"expression":"{$pids.styleguide} in tree.rootLineIds"}
It seems that PageTS config is not being populated correctly in that case.
Updated by Česlav Przywara about 3 years ago
I tracked the issue I described above to be caused by Grid Elements (https://gitlab.com/coderscare/gridelements/-/issues/171), so it's not TYPO3 core problem. However, I found out that this error will be always triggered when an admin selects page with UID 0 in the backend (regardless of active module), since there is no site associated with that page. I'm not sure what can be done about it...
Updated by Markus Klein about 3 years ago
Česlav Przywara wrote in #note-5:
However, I found out that this error will be always triggered when an admin selects page with UID 0 in the backend (regardless of active module), since there is no site associated with that page. I'm not sure what can be done about it...
How do you set the page TSconfig for the root node of the tree?
Updated by Marco Huber almost 3 years ago
- Related to Bug #94150: Constants in Page TsConfig with multiple sites, caching problem added
Updated by Philipp Kitzberger over 1 year ago
@Ingo Fabbri, please have a look at my comment #93746#note-3 as I believe this is probably fixing your issue as well.
Updated by Anonymous over 1 year ago
Philipp Kitzberger wrote in #note-8:
@Ingo Fabbri, please have a look at my comment #93746#note-3 as I believe this is probably fixing your issue as well.
I can't see any relation to this issue here.
Updated by Česlav Przywara over 1 year ago
Markus Klein wrote in #note-6:
Česlav Przywara wrote in #note-5:
However, I found out that this error will be always triggered when an admin selects page with UID 0 in the backend (regardless of active module), since there is no site associated with that page. I'm not sure what can be done about it...
How do you set the page TSconfig for the root node of the tree?
I'm sorry Markus, I somehow missed your reply. I used to use ExtensionManagementUtility::addPageTSConfig() for that, but I realized it's not the best way to include site-specific TSconfig, so now I'm doing it differently (see #93746#note-4) and don't have any issues anymore.
Updated by Markus Klein over 1 year ago
- Status changed from New to Needs Feedback
I lost track here a bit. Is this still an issue on v11?
Updated by Anonymous over 1 year ago
@Česlav Przywara Your problem and how you resolved it sound to me completely unrelated to my issue.
But I am aware of, that my initial description of the issue was lacking a lot of context and information.
In short: it happened in FE context (not in BE).
Updated by Anonymous over 1 year ago
Markus Klein wrote in #note-11:
I lost track here a bit. Is this still an issue on v11?
I lost the track here too. Not so easy to track down 2 year old issues nobody cared about such long time (including myself). But it is likely still an issue in v11. As we all know: bugs do not just self-resolve themselves usually. Not even after doing great refactoring of core. In most cases the underlying logic remains the same. The answer is hardly never "yupp, magically resolved" in old forge issues I was watching, when someone from core-teams asked this question. In fact, usually the issue author does not reply anymore (or does not care anymore - gone for good) and the issue is closed.
Updated by Markus Klein over 1 year ago
We have no clear path on how to reproduce, so not much of a grip here to start with.
Updated by Gerald Rintisch 12 months ago
I have the same issue in FE where a plugin uses the settings from `config.yaml` and sometimes failes.
Here is how to reproduce it:- Click "Flush all caches"
- Change a record (tried it with by creating a new content element). It does not happen if I skip this step.
- Surf the frontend of a page where the constant is needed.
- See the error.
It will test whether it also happens when there is no EXT:flux installed (I mean... it creates a lot of trouble :D ).
EDIT 26.08.2023
The problem is not flux as I expected but it is a bug in the core (fixed with https://forge.typo3.org/issues/97172) which is triggered by the solr Extension, see https://github.com/TYPO3-Solr/ext-solr/issues/3766.
Updated by Markus Klein 12 months ago
So this is related to "some" extension and not to Core.
I guess we can close this one then!?
Updated by Wittkiel Gruppe 12 months ago
- File typo3-constant-bug.png typo3-constant-bug.png added
Markus Klein wrote in #note-16:
So this is related to "some" extension and not to Core.
I guess we can close this one then!?
Since TYPO3 12 we also have this nasty bug. Our setup is TYPO3 12.4.1 (non-composer), PHP 8.1 and some extensions (container, content_defender, mask, wkgsource (sitepackage)). We can reproduce the problem for example after using extensionmanager and install some extension, now open frontend and typoscript-constants of site-settings are not converted/resolved, instead you can see the string and not the defined value. Because of that data-attributes and menus are completely wrong. Perhaps related to #92979?!
settings.yaml
wkgsource:
googleAdsId: ''
googleAnalyticsId: ''
googleMapsKey: ''
pidImprint: 3
pidPrivacy: 4
pidCookie: 9
setup.typoscript
page = PAGE
config {
//HTML-Tag
htmlTag.attributes.class = no-js
htmlTag.attributes.data-googleads = {$wkgsource.googleAdsId}
htmlTag.attributes.data-googleanalytics = {$wkgsource.googleAnalyticsId}
htmlTag.attributes.data-googlemaps = {$wkgsource.googleMapsKey}
}
page.10 = FLUIDTEMPLATE
page.10 {
file.stdWrap.cObject = CASE
file.stdWrap.cObject {
key.data = pagelayout
//Backend-Layout 1
default = TEXT
default.value = EXT:wkgsource/Resources/Private/Templates/DefaultTemplate.html
}
layoutRootPaths.10 = EXT:wkgsource/Resources/Private/Layouts/
partialRootPaths.10 = EXT:wkgsource/Resources/Private/Partials/
dataProcessing {
//mainNav
10 = TYPO3\CMS\Frontend\DataProcessing\MenuProcessor
10 {
entryLevel = 0
levels = 3
excludeUidList = {$wkgsource.pidImprint},{$wkgsource.pidPrivacy},{$wkgsource.pidCookie}
as = mainNav
}
//footerNav
20 = TYPO3\CMS\Frontend\DataProcessing\MenuProcessor
20 {
special = list
special.value = {$wkgsource.pidImprint},{$wkgsource.pidPrivacy},{$wkgsource.pidCookie}
as = footerNav
}
//Site
30 = TYPO3\CMS\Frontend\DataProcessing\SiteProcessor
30 {
as = site
}
}
}
Updated by Markus Klein 12 months ago
- Related to Feature #92979: Missing TypoScript constants are treated as strings added
Updated by Markus Klein 12 months ago
- Status changed from Needs Feedback to Accepted
Updated by Nikita Hovratov 5 months ago
- Related to Bug #102357: PageTsConfig: site settings / constants are not substituted in FormEngine added
Updated by Nikita Hovratov 5 months ago
- Related to Bug #102452: TypoScript constants from site settings are not substituted in Backend Extbase Modules added
Updated by Christian Kuhn 3 months ago
- Status changed from Accepted to Needs Feedback
Hey.
I'm pretty sure site settings substitution in FE works in both setup conditions as well as setup itself by now in v12. Early v12 releases had a cache related bug in this area that has been fixed meanwhile.
For BE, I just rechecked pageTsConfig site settings substitution in FormEngine with #102357 and was unable to reproduce an issue.
For BE extbase modules not in page context, I just fixed a bug with #102452.
Is there anything left to do with v12?
Updated by Christian Kuhn 3 months ago
- Related to Feature #97816: New TypoScript parser added
Updated by Wittkiel Gruppe 3 months ago
Christian Kuhn wrote in #note-22:
Hey.
I'm pretty sure site settings substitution in FE works in both setup conditions as well as setup itself by now in v12. Early v12 releases had a cache related bug in this area that has been fixed meanwhile.
For BE, I just rechecked pageTsConfig site settings substitution in FormEngine with #102357 and was unable to reproduce an issue.
For BE extbase modules not in page context, I just fixed a bug with #102452.
Is there anything left to do with v12?
With newer versions we can't reproduce the FE-problem posted before (note 17).
Updated by Markus Klein 3 months ago
- Status changed from Needs Feedback to Closed
Updated by Christian Kuhn about 2 months ago
- Related to Bug #103070: After clearing System Cache TypoScript conditions are parsed before substituting constants added