Fluid
Fluid copied to clipboard
TYPO3
Ternary expression: string constants with "special" characters
When using ternary expression and string constants with "special" characters like '-'
then the expression is not parsed, for instance:
{settings.false ? 'foo-bar' : 'xyz'}
This also results in the expression not being parsed in case of e.g.:
{'{settings.false}' ? 'foobar' : 'xyz'}
where one tries to retrieve the value by using '{value}' in the condition.
The same for:
{settings.false ? '{foobar}' : 'xyz'}
where foobar is retrieved and the output is then: {settings.false ? 'VALUE OF foobar' : 'xyz'}
Please do not use this (officially unsupported) syntax. Hardcoded string values are "working" only by coincidence and should not be allowed by design - but the use of an incorrect internal API causes string trimming and passthrough of strings which do not refer to variables.
The expression is exclusively for variables:
{ifVariable ? thenVariable : elseVariable}
Might be the case, however that expression is especially useful for adding additional CSS classes, which is why it would be really nice if it supports strings too.
Without going into too much detail that isn't relevant here: the problem is that the content of your expression has to be detected with regular expressions. Those expression detections currently allow for a limited set of characters, e.g. anything valid for a variable reference plus anything valid for normal programatic/arithmetic expressions. The fact that this expression even supports detection of single quotes is an issue in this regard.
You can imagine the additional pressure on the TemplateParser if it were to simply allow anything inside expressions - which would be the end result; we would need to support things like escaped curly braces, ViewHelper expressions recursively in strings you use, and much more.
This is why the expressions were initially designed to only allow variable references. The "odd man out" here is the math expression node which is the source of this entire problem now: it introduced a method that allowed working without having to detect if left/right hand side of expression was a variable reference or a hardcoded number (e.g. {variable % 4}). Because the math expressions must support hardcoded numbers they are capable of returning either the value of a reference or the initial value of the reference name if no variable was resolved. This was the originally designed purpose, but at some point the expression was extended to trim quoted strings which was never the intention as you can see from the above.
If there is a solution to this one - which I don't know that there is, at least not a consistent one - then it would probably also imply a more or less complete redesign of the TemplateParser. Our first step would be to remove the support for the undocumented/unintended usage to remove the expectation that this will some day be consistently supported, hence my recommendation to not use this syntax at all ;)
In that case I would think the syntax should at least be modified to not support "fix" strings. One can use the alias ViewHelper to make values out of those constants. Then it would be immediately obvious :)
But in theory to get it to work this: [a-zA-Z0-9.\s'"]+
espression for the then and else side would only have to be modified to allow - etc. Or in order to make wrong not work at all remove the ' from it.
Ok. Great. I am happy with removing not correctly working fix completely as long as they don't work at all and it is clear they are not supposed to work :)