Voting starts in March for the Drupal Association Board election.
Currently, we have a hook_field_extra_fields() which works like this:
Field UI's "Manage fields" and "Manage display" pages let users re-order fields, but also non-field components. For nodes, these include the title, poll choices, and other elements exposed by modules through hook_form() or hook_form_alter().
1) Implement hook_field_extra_fields() to add the field to the sortable elements on the bundle's fields configuration page.
2) Implement hook_form_alter() to put your elements into the renderable array, and to add a submit handler.
This is awkward.
Another, related issue: On the view mode display configuration, you can only rearrange "field" elements (where field = storable attribute of an entity). Only with Display Suite, you have the option for displayable and sortable "fields" that are not defined with field module.
Here is what I imagine:
- A hook to define sortable form elements for entity bundle forms.
This hook will combine the first two steps from above. That is, it defines how these elements are presented on the fields configuration page, the options you can configure, and a callback to build the form elements to add to the entity form, in the specified position. No more hook_form_alter() !
- A hook to define sortable display elements for enity bundle view modes.
This will be similar to http://drupalcontrib.org/api/drupal/contributions!ds!ds.api.php/function...
It will tell the system how to present this option on the field UI, which display options (e.g. formatters) you have, and how to render the field.
The actual field.module will use these two hooks for its own fields:
For every "field" (= storable property of an entity), it uses the first hook to register the sortable form element, widget options, and the callback to build it, and the second hook to register the sortable display element, formatter options, and the callback to build or render it.
Other modules can add author and date information as a rearrangeable display element (with no form counterpart), and path/alias or redirect options as a rearrangeable form element (with no display counterpart).
In addition, we could have:
- A hook to define "form element generators", that is, those extra rows in the field UI that currently lets you add new fields, reuse existing fields, or add field groups.
- A hook to define "display element generators", that is, extra rows in the field UI that let you add new element groups or new custom fields via the UI.
I did not think much about this one.
This system would have some nice benefits:
- No more messing around with hook_form_alter() in the usual case
- It becomes easier to define custom stuff in entity forms
- It becomes easier to define custom stuff in entity display
- Everything in an entity form becomes rearrangeable: Publishing options, etc.
- Everything on entity display becomes rearrangeable: Node links, comments, author and date information, etc.