Story #69712: Further FormEngine development
Remove name="foo[bar]_hr" from input fields
In FormEngine most rendered fields consists of a form field that is used for display and a second (hidden) one that is used to transfer the real value to the DataHandler, example:
<input type="text" data-formengine-validation-rules="" data-formengine-input-params="..." id="formengine-input-55f4253656de0150227335" name="data[tt_content][header]_hr" value="" ... >
<input type="hidden" name="data[tt_content][header]" value="">
This issue is about "input" fields rendered by "InputElement" only: Both fields have the same "name" attribute, except that the displayed field has the suffix _hr (this is probably for "human readable").
This means, if pressing save, both (!) fields are transferred back to the server to the DataHandler, so PHP receives two fields:
data[aTable][aField]_hr = "shown value"
data[aTable][aField] = "real value"
The fun part is that PHP creates an array in _POST from the [ and ] things, so it will become $GLOBALS['_POST']['data']['aTable']['aField']. So, PHP has no idea on what to do with the _hr suffix and throws this away. So, it basically gets two fields with the same name submitted. The second field (that is always the hidden field) then overwrites the value of the first field. The result is then: $GLOBALS['_POST']['data']['aTable']['aField'] = "real value"
This is really funny, since it means that the value of the "_hr" field is always transmitted back to the server, and then thrown away when PHP creates $GLOBALS['_POST']. So basically, we're transmitting the double amount of data that is needed ...
Goal of this patch: Remove the name="" attribute from the input field for the InputElement altogether. This is valid HTML (having no name) and browsers will then just not send this value on submit to the server.
So: remove the name attribute, but adapt any JS in a way that the hidden field is still updated if the shown field changes. Most of this will affect the JS "eval" handling, but also the DateTime stuff and maybe some wizards. Basically, the first tab of ext:styleguide should compile most use cases already.