Active
Project:
Drupal core
Version:
main
Component:
field_ui.module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
25 Sep 2023 at 02:31 UTC
Updated:
15 Oct 2023 at 22:34 UTC
Jump to comment: Most recent
Problem/Motivation
In EntityDisplayFormBase::getRegions() there is a hard-coded list of region names: 'content' and 'hidden'.
These are added to all of the fields and extra fields.
Also the fields and extra fields are not easy to alter per view mode.
Modules that want to add additional regions need to do one of two things:
- Create two (!) subclasses that extend EntityFormDisplayEditForm and EntityViewDisplayEditForm, and that override the getRegions() method. This is what the experimental field_layout module does.
- Alter the form, and process all of the fields and extra fields, to add the additional region options. This is what contrib Display suite module does.
Both of these options are bad.
Steps to reproduce
Proposed resolution
We could inject an object (a service?) that acts as a region provider.
Or we could invoke hooks that provide regions or alter the existing region list.
Comments
Comment #2
donquixote commentedComment #3
donquixote commentedComment #4
andypostComment #5
donquixote commentedAn alternative i could think of:
Make the lists of rows, regions and groups alterable in the form array.
To do this, we have to delay the full preparation of the rows to a '#process' callback.
Possibly there could even be an element type for tabledrag with regions and groups.
So:
- The initial form builder adds stubs for the rows, and a '#regions' property.
- A row can be marked as a group.
- Other modules can add rows and regions using hook_form_alter() or possibly other ways.
- Later, a '#process' callback adds the weight fields and tabledrag controls.
I'd say this will make the job easier for modules like field_group (contrib) and field_layout (core).
On the other hand, it could break existing versions of such modules, depending how it is done.
i could start building this, but I am afraid this will be stuck in the sand..
Comment #6
donquixote commentedIn fact the form already uses the element type 'field_ui_table'.
It currently does not have a '#process' callback.
So we can easily add one, either directly to the element type, or in the form.
Still this would be a BC break, I think.