Bug #91361
closed
TypoScript - PageTS not loaded if a bracket exists in the key
Added by Christian Hackl over 4 years ago.
Updated over 2 years ago.
Description
After updating from TYPO3 7 to 9 I noticed the following:
PageTs will not be loaded if a bracket exists in the key.
Strangely explained I try to show it with an example:
TCEFORM {
tt_content {
pi_flexform.ttaddress_listview.sDISPLAY.settings\.displayMode.addItems {
mykey(something) = label
}
}
}
RTE {
default {
preset = rte_theme
}
}
Then everything after this "mykey(something)" is no longer loaded.
If you remove the brackets, the remaining TS (here RTE) is loaded.
(yes brackets in the key are not good - but I think I should at least be logged or something like that)
- Category set to TypoScript
- Status changed from New to Needs Feedback
If those parenthesis worked before as a name I would consider it a bug or unwanted side effect as it does not conform the rules of typoscript.
Any opening parenthesis before an equal sign should open a multiline value, which ends with a line starting with a closing parenthesis (after white space), while the rests of these both lines are ignored.
Maybe the handling of whitespace as a seperator of object-/property-names and operator has changed and the splitting (and interpreting) is done different than before.
An explaining error message about unbalanced parenthesis would be required.
- Subject changed from TypoScript - PageTS not loaded if to TypoScript - PageTS not loaded if a bracket exists in the key
- Status changed from Needs Feedback to New
- Status changed from New to Rejected
Round brackets '(' are NOT valid keys of an identifier, since they are used for multiline assignments. The docs says valid chars are a-z,A-Z,0-9, but in practice colon : is used, too.
foo (
multiline
value
)
Unsure what the old parser does here, but the new parser creates mykey identifier with value 'something' and "= label" is a comment.
This won't change. Don't use these chars in identifiers. Won't fix.
It was not about the fix, but that you get an error message at all or a corresponding entry is written in the error_log or something.
I don't know the parser now, but in general I would consider characters that are not allowed in certain places, but are still somehow taken into account as here, as a question of security, or not?
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by