Voting starts in March for the Drupal Association Board election.
This is part of.
Updated: Comment #111
Formatter and widget constructors currently receive a $instance config entity, with no type hint, and use it as an array, thereby potentially relying on any arbitrary (public or private) FieldInstance property. This couples formatters and widgets too tightly on $instance as a config entity, preventing them from being reliably applied to node titles or any other nonconfigurable field, effectively also preventing node titles and other nonconfigurable fields from being translatable or in-place editable without adding lots of new custom code for each such field.
- Create a FieldDefinitionInterface that encapsulates the information that formatters and widgets need about a field (other than its item values within each entity, since those are passed separately to the formatter and widget interface methods as needed so that a single formatter or widget instance can operate on multiple entities).
- Have $instance config entities implement that interface.
- Change formatter and widget constructors from receiving an untyped $instance config entity to receiving a $field_definition object typed to FieldDefinitionInterface.
- EntityDisplay and EntityFormDisplay can still pass $instance as that object, since it implements that interface, though see about abstracting that.
- Also make $field config entities implement that interface, and remove the Drupal\field\Plugin\views\field\Field::fakeFieldInstance() hack currently employed for allowing Views to collect formatter settings to apply to results across multiple bundles.
User interface changes
In addition to what's listed above in "Proposed resolution", various functions and hooks called by formatters and widgets are affected:
- Changed hook_field_is_empty() from receiving $field to receiving $field_type, since it should only depend on the type, not anything else in the field definition.
- Changed file_field_widget_upload_validators() and file_field_widget_uri() from receiving $field and $instance to receiving $field_settings, since that's the only part of the field definition they depend on.
- Changed entity_reference_get_selection_handler() and the corresponding ER selection plugin constructors from receiving $field and $instance to receiving $field_definition.
- Changed hook_options_list() and options_allowed_values() from receiving $field and $instance to receiving $field_definition.
- Made $entity a required parameter to options_allowed_values(), just as it is for hook_options_list(), and because 'entity_type' and 'bundle' can no longer be retrieved from $instance.
- Removed $field_state['field'] and $field_state['instance'] and its accessor functions field_widget_field() and field_widget_instance(), because there's no good reason for element callbacks to need them. Instead, widgets should set $element['#custom'] properties that are needed by those callbacks. Updated the docs in WidgetInterface accordingly.
- Changed the $context received by hook_field_widget_form_alter() and hook_field_widget_WIDGET_TYPE_form_alter() from having 'field' and 'instance' to having 'widget', 'field_definition', and 'entity'.
Also, strengthened hook_field_access() to type hint $field, which is already the intent, but the lack of it being explicit caused tests to pass that shouldn't have (see #62).
Once this issue andare both in, work on having nonconfigurable fields implement FieldDefinitionInterface and apply formatters and widgets to them: see and .