- πΊπΈUnited States smustgrave
Wonder if this is still a valid task in D10?
In other issues (e.g., π Add ability to insert FAPI wrapper element without modifying #parents of children Needs work ), we explored the problem of modules using hook_form_alter() to alter display-only decisions. For example, CCK's fieldgroup.module uses hook_form_alter() to put fields into a fieldset. The problem with this is that anything done in hook_form_alter() affects the processing of the form, so validation and submit handlers need to be aware of whether or not fieldgroup.module is enabled. Things get even worse when similar rearrangement of elements results in the #parents property being affected (if you move things around in $form when #tree is in-use, then that affects #parents), so code that thinks it's only affecting display ends up affecting where form values are located within $form_state['values'].
In some cases, this can be solved using #pre_render. But, the problem with the way we have separated the Form API and Render API, is that during rendering, we don't have access to $form_state. The implementation of vertical tabs functionality is an example where things got convoluted because of this. Also, the goal of #591794: Allow themes to alter forms and page β was to make it easier for themes to have control of forms. Most of the time, themes should only alter the display of the form, not its processing, but without a hook_form_view_alter(), they'll end up using hook_form_alter(), but without sufficient awareness of how form processing works to steer clear of changes that affect that.
The proposed hook follows the same pattern established with hook_(node|comment|user|block)_view_alter(). Once a final render array has been built, run a hook_*_view_alter() on it. Unlike the other major render arrays, we'll have both a hook_form_alter() and a hook_form_view_alter(), but that's because forms have this double identity of needing to be both processed and rendered.
Postponed: needs info
9.5
Last updated
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Wonder if this is still a valid task in D10?