Project

General

Profile

Actions

Feature #92979

open

Missing TypoScript constants are treated as strings

Added by Andreas Kießling almost 4 years ago. Updated over 2 years ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
TypoScript
Start date:
2020-12-03
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

This has probably been the behaviour of the TS parser since forever, but IMHO it is very confusing.

When a TS constant is not defined, it is treated in the setup as a string.
This causes various hickups, since conditions "if a constant is defined" don't work, any other usages like in TEXT values etc. also just output the constant name as a string.
The condition documentation only shows usecases with comparison to integers or strings, and these usecases are covered, since the value is the constant string itself. But there is no way to simply check for the existence.
https://docs.typo3.org/m/typo3/reference-typoscript/master/en-us/Conditions/#constant

If i only need the constant in e.g. one language, i have to first initialize it with an empty value, then it can be set in the condition.
Now it is always replaced and i can check the constant to be empty or filled. IMHO it should always be empty in the TS if it is not defined.


Related issues 2 (0 open2 closed)

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

Actions
Related to TYPO3 Core - Bug #92528: TypoScript site constants not always populatedClosed2020-10-09

Actions
Actions #1

Updated by Benni Mack almost 4 years ago

  • Target version changed from 11.0 to Candidate for Major Version
Actions #2

Updated by Christian Kuhn over 2 years ago

  • Tracker changed from Bug to Feature
  • TYPO3 Version deleted (9)

We can't change that, and i decided in the new TS parser in #97816 to NOT change this behavior, either:
The problem is that values (especially in multiline assignments) can be JavaScript which kinda often comes with a {$...} char combination. The TS tokenizer MUST treat them as possible constants, and if they can't be resolved, they should fall back to their string literal.
What we maybe could do, is showing a warning in the backend object browser, if an attempt to resolve a constant failed. This would make this request a feature of the object browser.

Actions #3

Updated by Christian Kuhn over 2 years ago

Actions #4

Updated by Markus Klein over 1 year ago

  • Related to Bug #92528: TypoScript site constants not always populated added
Actions

Also available in: Atom PDF