Make regions and fields pluggable or alterable in EntityDisplayFormBase

Created on 25 September 2023, 9 months ago
Updated 15 October 2023, 8 months ago

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.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

πŸ“Œ Task
Status

Active

Version

11.0 πŸ”₯

Component
Field UIΒ  β†’

Last updated about 5 hours ago

Created by

πŸ‡©πŸ‡ͺGermany donquixote

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @donquixote
  • πŸ‡©πŸ‡ͺGermany donquixote

    An 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..

  • πŸ‡©πŸ‡ͺGermany donquixote

    In 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.

Production build 0.69.0 2024