Currently, we have a hook_field_extra_fields() which works like this:!field!field.api.php/function/ho...

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:

  1. 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() !
  2. A hook to define sortable display elements for enity bundle view modes.
    This will be similar to!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:

  1. 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.
  2. 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.


tim.plunkett’s picture

Note, there is a step 3, or alternate to step 2.

That is, using the 'display' part of hook_field_extra_fields(), and then using hook_entity_view() to display it.

As long as equivalent functionality exists, I'm fine with that, but it's not just about the form.

donquixote’s picture

Ah, yes, the display part.
I have some difficulty to understand why this is currently in the same hook. I suppose it is just bad design, but maybe you can shed some light into this?

Sure, these two parts, in case of the poll, do kind of belong together. But the weight of the displayable elements is independent from the weight and settings of the form elements.

Also, as far as I understand, the system leaves you alone for actually inserting those elements into the form or the render array.
The display part does not help you to skip the hook_form_alter(), you still need to do that, to insert your form elements. And in addition you need hook_entity_view().

So, as a complete replacement, you would now implement two hooks, and independently declare the form elements and the display elements.
The profit comes when you no longer need hook_form_alter() and hook_entity_view().
You just implement the builder callbacks that create the form element and the display element, but you don't bother anymore with where and how they are inserted to the entity form or entity display.
And, if the element has been disabled for this view mode, the callback is simply not called.

andypost’s picture

There's a duplicate of the issue #1954188: Revaluate the concept of 'extra fields'

longwave’s picture

yched’s picture

Status: Active » Closed (duplicate)

Yes, the (D9) fate of hook_field_extra_fields() is discussed at #1954188: Revaluate the concept of 'extra fields'

yched’s picture

Issue summary: View changes

Example about other modules using the API for author + date info or alias/redirect settings