Project

General

Profile

Actions

Bug #104490

closed

Undocumented effects of avoiding registerTagAttribute() in VH's

Added by Eric Harrer 6 months ago. Updated 3 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Fluid
Target version:
Start date:
2024-07-26
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
13
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

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


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Task #104443: Avoid registerTagAttribute() in VH'sClosed2024-07-20

Actions
Actions #1

Updated by Eric Harrer 6 months ago

  • Related to Task #104443: Avoid registerTagAttribute() in VH's added
Actions #2

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…

Actions #3

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.

Actions #4

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)

Actions #5

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.

Actions #6

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?

Actions #7

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.

Actions #8

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. 👏

Actions #9

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

Actions #10

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

Actions #11

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

Actions #12

Updated by Simon Praetorius 6 months ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #13

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

Actions #14

Updated by Simon Praetorius 6 months ago

  • Status changed from Under Review to Resolved
Actions #15

Updated by Benni Mack 3 months ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF