Voting starts in March for the Drupal Association Board election.
Configurable fields were ported to the @FieldType Plugin type. They use plugin ID's like text, email, entity_reference. They are then also exposed as typed data plugins as derivatives and are prefixed with field_item:, so e.g. field_item:text, field_item:entity_reference.
For a while, in the Drupal 8 development cycle, base field types (e.g. StringItem, IntegerItem, EntityReferenceItem) were directly exposed as Typed Data (with ID's like string_field, integer_field, entity_reference_field).
To be able to instantiate all field types using the field type plugin manager, base fields need to be exposed as @FieldType plugins too.
The @FieldType plugin definition has therefore been extended with a
no_ui flag, that disallows to add those field types in field_ui manage fields screen to fieldable entities, but can be used in the same way. Be careful not all this field types have default widget and formatter.
All base fields are exposed as @FieldType plugins. To keep base field types apart from configurable field type:
- FieldItems have a
no_ui= TRUE/FALSE flag, that indicates if they *can not* be used to add fields to fieldable entities by field_ui module, only via some code but *can* be used for base fields.
- Configurable field type need to implement FieldIteminterface (and extend from the corresponding base class), they also automatically get the corresponding FieldItemList list class.
- One base FieldItem could be updated to configurable field type with hook_field_info_alter(), and then the new Item class could serve as both base field and configurable field. See entity_reference_field_info_alter()
- All base field types (as long as this field type is not altered to configurable field type) are not available at field UI, while configurable field type's availability depends on the no_ui flag in field type's annotation.