Project

General

Profile

Actions

Bug #99292

closed

TypoScript/TSConfig tree.rootLineIds Symfony Express condition broken if constant/setting can't be

Added by Josef Glatz over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
TypoScript
Target version:
-
Start date:
2022-12-06
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
11
PHP Version:
8.1
Tags:
conditions, symfonyexpression, expressionlanguage, typoscript, tsconfig, pagetsconfig, usertsconfig
Complexity:
Is Regression:
Sprint Focus:

Description

Problem/Description

Given:

Site config:

...
settings:
  site:
    foo: 3
    bar: 4

PageTSConfig:

[{$site.foo},{$site.bar} in tree.rootLineIds]
    condition = works
    mod.web_list.allowedNewTables = tx_news_domain_model_news,sys_note
    TCEFORM.tx_news_domain_model_news {
        type {
            keepItems = 0
        }
    }
    TCAdefaults.tx_news_domain_model_news.type = 0
    # ...

[end]

Pagetree with only 3 Pages

In the example are only 3 page, page with UID 4 does not exist in the database.

Actual behaviour:

Condition evaluate not to true if you are on page with UID 3.

Actual workaround:

Check always before, if all constants can be resolved or adopt the condition

ToDo(s)

The behaviour is not as before using Expression Language. The fact that an extension or any Sitepackage can ship such a construct with conditions makes it mandatory to add a check if a constant or site setting could not be resolved.

Acceptance Criteria

The condition must also work in the example above. Or in other words: even page uid 4 is not present, the condition must work if the expression already validates to true for the first variable site.foo (which is value 3).


Related issues 1 (0 open1 closed)

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

Actions
Actions #1

Updated by Christian Kuhn over 1 year ago

  • Status changed from New to Needs Feedback

First: To my findings, both the new and the old TypoScript parser (v11 & v12) do properly substitute the constants within the conditions. This can be verified by setting a breapoint on AbsractConditionMatcher->match(), to see that $expression receives the two id values.

Apart from this, this is related to the ConditionMatcher, and not the new v12 TypoScript parser. It seems there is at least no change in behavior between v11 and v12.

I think the syntax `[1, 2 in tree.rootLineIds]` is invalid?! It works with something like `[1 in tree.rootLineIds]` and maybe when having multiple values, this either needs to be changed to multiple conditions, or some clever traverse() has to be used. As such, I think we should find a correct syntax for this scenario, have a functional test about this for the ConditionMatcher, and document a working solution in /m/typo3/reference-typoscript/main/en-us/Conditions/Index.html along the way.

What do you think? Would you like to play around on this a bit?

Actions #2

Updated by Christian Kuhn over 1 year ago

Actions #3

Updated by Christian Kuhn about 1 year ago

  • Status changed from Needs Feedback to Resolved
[{$site.foo} in tree.rootLineIds || {$site.bar} in tree.rootLineIds]
Actions #4

Updated by Christian Kuhn about 1 year ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF