Bug #104490
closedUndocumented effects of avoiding registerTagAttribute() in VH's
100%
Description
With commit https://github.com/TYPO3/typo3/commit/21d3f18b0ee8c7e2915f2ca3d054704ce06a4ec4 occurrences of registerTagAttribute()
in VHs were removed.
The HTML output behaviour of Boolean attributes, which were previously defined via registerTagAttribute()
, has changed in the event that the attribute was set without a value .
It can happen that inline conditions are used in extensions in the context of the fluid attribute, which should be decisive for whether the boolean attribute should be output in HTML or not.
Example
<f:form.textarea name="myname" value="myvalue" readonly="{f:if(condition:anyCondition,then:'1')}" />
If in the example anyCondition
is FALSE
, then the attribute readonly
is not used in HTML in TYPO3 v12 and is now used in TYPO3 v13. This is therefore a breaking change that should be documented so that extension maintainers can react appropriately to the new feature.
EXT:translate_locallang
can also be analysed to evaluate the possible effects.
Issue: https://github.com/rrrapha/translate_locallang/issues/81
Fix: https://github.com/rrrapha/translate_locallang/pull/82
Updated by Eric Harrer 6 months ago
- Related to Task #104443: Avoid registerTagAttribute() in VH's added
Updated by Simon Praetorius 6 months ago
Thank you for your report. This is an unfortunate shortcoming of Fluid at the moment, see: https://github.com/TYPO3/Fluid/issues/911
For now, we probably need to re-implement boolean behavior manually for the arguments that were previously registered as boolean, although it makes things more inconsistent in templates…
Updated by Eric Harrer 6 months ago
Since the migration to the new behaviour is easy once the problem is known, I think it would be sufficient to document the new behaviour or record it in the changelog instead of increasing complexity/inconsistency.
Updated by Simon Praetorius 6 months ago
- Status changed from New to Needs Feedback
Interesting find, thank you again! Can you test if your issue is resolved with the following change in Fluid Standalone?
https://github.com/TYPO3/Fluid/pull/940
(note that the branch is based on main, not on 2.x)
Updated by Eric Harrer 6 months ago
Thanks for the patch. I can confirm that the former behaviour is restored with this PR #940 (based on the main
branch) of the typo3fluid/fluid
package.
In addition, I have tested whether there was/is any form of interpretation of the values.
The following values were tested in TYPO3 12.4.16, 13.2.1 and 13.3.0-dev:
<f:form.textarea name="myname" value="myvalue" readonly="1" /> <f:form.textarea name="myname" value="myvalue" readonly="0" /> <f:form.textarea name="myname" value="myvalue" readonly="readonly" /> <f:form.textarea name="myname" value="myvalue" readonly="true" /> <f:form.textarea name="myname" value="myvalue" readonly="false" />
This resulted in the following HTML code in all tested versions
<textarea readonly="1" name="myname">myvalue</textarea> <textarea readonly="0" name="myname">myvalue</textarea> <textarea readonly="readonly" name="myname">myvalue</textarea> <textarea readonly="true" name="myname">myvalue</textarea> <textarea readonly="false" name="myname">myvalue</textarea>
So now it's safe. The only difference was the different handling of the empty value, which is fixed by your patch. Any other value is transferred directly to the HTML output in all tested versions.
Updated by Simon Praetorius 6 months ago · Edited
Thanks to Garvin's input we found a few more edge cases, which should now also be handled properly: Passing true
, false
, null
and a undefined variable directly to the ViewHelper, not as string.
Could you check if the linked PR still works for you?
Updated by Eric Harrer 6 months ago · Edited
I ran the above tests again with the latest version of the PR. Your changes to the PR had no effect on the results already mentioned.
At Garvin's request, I also tested the following scenarios in TYPO3 13.3.0-dev:
{f:form.textarea(name: 'myname', value: 'value', readonly: 'readonly')} {f:form.textarea(name: 'myname', value: 'value', readonly: variableTrue)} {f:form.textarea(name: 'myname', value: 'value', readonly: variableFalse)} {f:form.textarea(name: 'myname', value: 'value', readonly: variableNull)} {f:form.textarea(name: 'myname', value: 'value', readonly: notDefinedVariable)}
with the following assignments in the Extbase Controller:
$this->view->assign('variableTrue', true); $this->view->assign('variableFalse', false); $this->view->assign('variableNull', null);
With the current main branch of typo3fluid/fluid
I get the following HTML results:
<textarea readonly="readonly" name="myname">value</textarea> <textarea readonly="1" name="myname">value</textarea> <textarea readonly="" name="myname">value</textarea> <textarea readonly="" name="myname">value</textarea> <textarea readonly="" name="myname">value</textarea>
With latest version of your patch #940 I get the following HTML results:
<textarea readonly="readonly" name="myname">value</textarea> <textarea readonly="1" name="myname">value</textarea> <textarea readonly="" name="myname">value</textarea> <textarea name="myname">value</textarea> <textarea name="myname">value</textarea>
therefore the case of a "real" FALSE
value still seems to lead to the output of the attribute with an empty value.
BUT we also have this behaviour in TYPO3 12.4.16 (also tested)!
Accordingly, we can state that the inline notation with the cases mentioned are also set to the original behaviour by the patch, even if it seems a bit illogical that TRUE
becomes 1
and FALSE
becomes an empty value instead of 0
or an attribute not set.
Updated by Garvin Hicking 6 months ago · Edited
Many, many thanks to you both for working this out. This saved at least one of our projects from a possibly gritty v12 patchlevel update. 👏
Updated by Gerrit Code Review 6 months ago
- Status changed from Needs Feedback to Under Review
Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/85420
Updated by Gerrit Code Review 6 months ago
Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/85420
Updated by Gerrit Code Review 6 months ago
Patch set 3 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/85420
Updated by Simon Praetorius 6 months ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 7f279f23fc3289ce2039317767e7a46a6f0b32de.
Updated by Gerrit Code Review 6 months ago
- Status changed from Resolved to Under Review
Patch set 1 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/85422
Updated by Simon Praetorius 6 months ago
- Status changed from Under Review to Resolved
Applied in changeset 93ef207d7be7ffd1599c22016779b670204f0e65.