Project

General

Profile

Actions

Bug #92528

closed

TypoScript site constants not always populated

Added by Anonymous over 3 years ago. Updated 4 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2020-10-09
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
7.4
Tags:
Complexity:
Is Regression:
Sprint Focus:

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

typo3-constant-bug.png (8.27 KB) typo3-constant-bug.png Wittkiel Gruppe, 2023-05-10 08:06

Related issues 7 (1 open6 closed)

Related to TYPO3 Core - Feature #91080: Populate site settings to TypoScript constantsClosedBenni Mack2020-04-17

Actions
Related to TYPO3 Core - Bug #94150: Constants in Page TsConfig with multiple sites, caching problemClosed2021-05-18

Actions
Related to TYPO3 Core - Feature #92979: Missing TypoScript constants are treated as stringsNew2020-12-03

Actions
Related to TYPO3 Core - Bug #102357: PageTsConfig: site settings / constants are not substituted in FormEngineClosed2023-11-09

Actions
Related to TYPO3 Core - Bug #102452: TypoScript constants from site settings are not substituted in Backend Extbase ModulesResolved2023-11-22

Actions
Related to TYPO3 Core - Feature #97816: New TypoScript parserClosed2022-06-27

Actions
Related to TYPO3 Core - Bug #103070: After clearing System Cache TypoScript conditions are parsed before substituting constantsClosed2024-02-07

Actions
Actions #1

Updated by Anonymous over 3 years ago

  • Related to Feature #91080: Populate site settings to TypoScript constants added
Actions #2

Updated by Anonymous over 3 years ago

  • Description updated (diff)
Actions #3

Updated by Anonymous over 3 years ago

  • Description updated (diff)
Actions #4

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.

Actions #5

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...

Actions #6

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?

Actions #7

Updated by Marco Huber about 3 years ago

  • Related to Bug #94150: Constants in Page TsConfig with multiple sites, caching problem added
Actions #8

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.

Actions #9

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.

Actions #10

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.

Actions #11

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?

Actions #12

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).

Actions #13

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.

Actions #14

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.

Actions #15

Updated by Gerald Rintisch about 1 year 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:
  1. Click "Flush all caches"
  2. Change a record (tried it with by creating a new content element). It does not happen if I skip this step.
  3. Surf the frontend of a page where the constant is needed.
  4. 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.

Actions #16

Updated by Markus Klein about 1 year ago

So this is related to "some" extension and not to Core.
I guess we can close this one then!?

Actions #17

Updated by Wittkiel Gruppe about 1 year ago

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
        }
    }
}

Actions #18

Updated by Markus Klein about 1 year ago

  • Related to Feature #92979: Missing TypoScript constants are treated as strings added
Actions #19

Updated by Markus Klein about 1 year ago

  • Status changed from Needs Feedback to Accepted
Actions #20

Updated by Nikita Hovratov 6 months ago

  • Related to Bug #102357: PageTsConfig: site settings / constants are not substituted in FormEngine added
Actions #21

Updated by Nikita Hovratov 6 months ago

  • Related to Bug #102452: TypoScript constants from site settings are not substituted in Backend Extbase Modules added
Actions #22

Updated by Christian Kuhn 4 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?

Actions #23

Updated by Christian Kuhn 4 months ago

Actions #24

Updated by Wittkiel Gruppe 4 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).

Actions #25

Updated by Markus Klein 4 months ago

  • Status changed from Needs Feedback to Closed
Actions #26

Updated by Christian Kuhn 3 months ago

  • Related to Bug #103070: After clearing System Cache TypoScript conditions are parsed before substituting constants added
Actions

Also available in: Atom PDF