Project

General

Profile

Actions

Bug #93746

closed

Conditions in Page TSconfig using site settings trigger errors when page with UID 0 is selected in BE

Added by Česlav Przywara about 3 years ago. Updated 3 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
TypoScript
Target version:
-
Start date:
2021-03-15
Due date:
% Done:

0%

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

Description

The subject says it all.

An example of error:

[ERROR] component="TYPO3.CMS.Backend.Configuration.TypoScript.ConditionMatching.ConditionMatcher": Expression could not be parsed. - {"expression":"{$pids.styleguide} in tree.rootLineIds"}

Since there is no site attached to page with UID 0, there are no site settings to be populated either.

Perhaps conditions that have variables in them should be simply ignored on page with UID 0?


Related issues 3 (0 open3 closed)

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

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
Actions #1

Updated by Česlav Przywara about 3 years ago

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

Updated by Česlav Przywara about 3 years ago

The same error is triggered when an extension requests Page TSconfig for page with UID 0 (for whatever reason) like Grid Elements currently does: https://gitlab.com/coderscare/gridelements/-/issues/171

Actions #3

Updated by Philipp Kitzberger over 1 year ago

Just had the very same issue. I resolved it via declaring that constant globally (so it's also present on the root level)

From the docs we know the sequence of how the stack of constants is being put together:

The TypoScript constants are evaluated in this order:
  • Global 'defaultTypoScript_constants'
  • Site specific settings from the site configuration
  • Constants from sys_template database records

So all I had to do is this in a ext_localconf.php:

        \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTypoScript(
            'my_extension',
            'constants',
            '@import \'my_extension/Configuration/GlobalSettings.typoscript\''
        );

Cheerio ;-)

Actions #4

Updated by Česlav Przywara over 1 year ago

I solved this issue as well, albeit differently:

Instead of including TSConfig globally via ext_localconf.php :

ExtensionManagementUtility::addPageTSConfig('<INCLUDE_TYPOSCRIPT: source="DIR:EXT:my_extension/Configuration/TsConfig/Page">');

I just register main (bootstrap) file in Configuration/TCA/Overrides/pages.php :

ExtensionManagementUtility::registerPageTSConfigFile(
    'my_extension',
    'Configuration/TsConfig/Page/example_site.tsconfig',
    'Example site'
);

I then include the registered file on root page of the site it relates too. This way the TSConfig is not evaluated on global root page and there are no parsing errors.

Actions #5

Updated by Christian Kuhn 4 months ago

  • Status changed from New to Needs Feedback

Hey, in general extensions like gridelements should of course fire tsconfig fetching with the correct page id. I hope this was fixed meanwhile.

Apart from that, I had a look at the current site settings substitution in both FE and BE (see #92528) and fixed a bug in extbase BE modules with #102452.

Is there anything left to do for v12 and upwards?

Actions #6

Updated by Christian Kuhn 4 months ago

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

Updated by Christian Kuhn 4 months ago

Actions #8

Updated by Česlav Przywara 4 months ago

Christian Kuhn wrote in #note-5:

Is there anything left to do for v12 and upwards?

Hallo Christian,

we have a work-around for TYPO3 10 and no problems with TYPO3 11 or newer, so I would say the issue can be closed.

Actions #9

Updated by Christian Kuhn 3 months ago

  • Status changed from Needs Feedback to Closed
Actions

Also available in: Atom PDF