Voting starts in March for the Drupal Association Board election.
change notice) introduced EntityDisplay objects on the entity_view() side. An EntityDisplay (config entity) object centrally stores the list of components (fields, "extra fields", contrib additions like field_groups...) displayed for a given entity type & bundle in a given view mode, along with the corresponding display options (weight, formatter, formatter settings...).
This removed the various scattered locations where those settings were stored in D7:
- in $instance['display'] for each individual field,
- in the 'field_bundle_settings_[entity_type]_[bundle]' variable ('display' entry) for 'extra fields',
- in other places for contrib additions that are not one of the two above (field_group ...)
This issue is about applying a similar pattern on the "form" side.
It is a pre-requisite for , since it will provide a location to store "assignement of widgets + settings to base (non-Field-API) fields" configuration.
(The existing EntityDisplay objects already provide such a location for formatters on base fields)
- Introduces EntityFormDisplay config entities.
Most of the associated methods and business logic is shared with EntityDisplay objects through a common abstract EntityDisplayBase class.
- Just like EntityDisplay objects are associated to an entity bundle and a view mode, EntityFormDisplay objects, at the API level, are associated to an entity bundle and a "form mode".
"Form modes" are typically intended to differenciate between "user edit" and "user register" forms, or possibly "add" and "edit" forms.
The patch only adds support for "form modes" at the EntityFormDisplay storage level, but does not have core entities use them for now. Only the 'default' form mode is actually used - thus, no visible functionnal change on this regard.
- Modifies EntityFormController so that the correct EntityFormDisplay is fetched, lets modules alter it in one pass (instead of one alter invocation per field previously) and placed in $form_state for the rest of the form building callstack to use.
- Widget plugin objects are instanciated from (and persisted in) the EntityFormDisplay object rather than each $instance object. This part is 1:1 with what is done for formatters and EntityDisplay objects.
- Modifies Field UI to store widget configuration in EntityFormDisplay rather than $instance['widget'].
- Removes $instance['widget'] and the rest of the 'field_bundle_settings_[entity_type]_[bundle]' variable,
provides the corresponding upgrade path, and related test.
- Provides the CMI file for article nodes (entity.form_display.node.article.default.yml) in standard.profile's default config
(Page node type only contains the "body" field, which is created programmatically)
None (see followups below)
User interface changes
Quite similar to the API changes introduced by EntityDisplays:
- New entity_get_form_display() API function to access EntityFormDisplay objects:
entity_get_form_display('node', 'article', 'default') ->setComponent('body', array( 'type' => 'text_textarea_with_summary', 'weight' => 1, )) ->setComponent('field_image', array( 'type' => 'hidden', )) ->save();
- Support hiding "extra fields":UI + default setting in hook_field_extra_field() + make all the code that adds the actual elements in $form check the configured visibility from the EntityFormDisplay first
- Decide how core can actually leverage form modes (what they are exactly, how they are exposed / added, UI...):
- Introduce config schema for EntityFormDisplay (and EntityDisplays that still lack them), move over the existing config schemas for $instance['widget'] and widget settings for the various widget types.
PASSED: [[SimpleTest]]: [MySQL] 55,710 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 55,842 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] 55,931 pass(es), 4 fail(s), and 1 exception(s). View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch entity_form_display-1875992-129.patch. Unable to apply patch. See the log in the details link for more information. View