TYPO3 Core

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

textarea (
    <label />
    <textarea class="some-class" />
)

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