Bug #80490
Updated by Olaf Hoffmann over 7 years ago
While fixing a problem for a customer regarding the form extension I ran into a bug.
In @typo3/sysext/form/Classes/Utility/CompatibilityLayerUtility.php:471@, the variable @$elementType@ is used in an @if@ but has never been set before. The fix is to set the variable to the value returned by @$element->getElementType()@.
How I found it, and why I think it's important to fix:
I tried to override the layouts for the form components @SELECT@, @TEXTAREA@, @SUBMIT@, @BUTTON@ and @TEXTLINE@ using the @tt_content.mailform.20.form.layout@ settings for the corresponding objects with the goal of providing a uniform form layout that used certain HTML classes without the customer not having to specifiy the HTML classes in the wizard manually everytime when creating a new form. What I noticed was that when having a layout like
<pre>
textarea (
<label />
<textarea class="some-class" />
)
</pre>
the HTML class @some-class@ would simply get lost in the rendering process. As I tried to find the reason for this behavior, I stumbled upon the TypoScript configuration for the @FORM@ element, where in version 7.6.0 of EXT:form, the setting @plugin.tx_form.settings.registeredElements.FORM.compatibilityMode@ is set to @1@ by default. This leads to @CompatibilityLayerUtility@ being responsible for setting the layouts for the rendered form.
In the method where this actually happens - @setElementLayouts@ - the @textarea@ tag first gets replaced by a marker, which later is replaced again by the real tag, after which the HTML class of the element is added again which happens on line 479. There, the HTML class is fetched by getting the corresponding tag from the layout @DOMDocument@. The tag name is determined based on the @$elementType@ (line 471), which unfortunately never gets set in this method.
This leads for the @CompatibilityLayerUtility@ to always believe that it has to fetch a class from an @input@ tag, which simply is not present in the case of rendering a @textarea@ or a @select@. The result is, as said above, that the class is not re-added to the tag.
Moreover did I notice that most of the methods in the @CompatibilityLayerUtility@, this method included are deprecated. The deprecation notice is valid for TYPO3 version 7 and the methods will be removed in version 8. This would mean that a fix for version 7 should be provided in spite of the deprecation.
So my next step was to follow the deprecation notice, where it's stated that @.layout@ should not be used anymore as the functionality is done via fluid, which after further inspection of the code implies that the @plugin.tx_form.settings.registeredElements.FORM.compatibilityMode@ has to be disabled.
I assumed that in the documentation for EXT:form version 8 the correct way using fluid would be documented, which is not the case. As stated "there":https://docs.typo3.org/typo3cms/extensions/form/8.0/Configuration/Layout/LayoutViewSpecific/, the way to do still seems to be using TypoScript.
Now when I deactivate the @compatibilityMode@, the fluid templates of the extension are getting used, but I still see no possibility of configuring template-wide attributes in as initially intended besides from copying all of the templates I want to change to a user extension and adjust the attributes there.
I don't know if such functionality was intended or how it should be done with fluid, but as for the issue with the @CompatibilityLayerUtility@ I could provide a pull request if desired.