Updated: Comment #75
Vision: Unify base and configurable fields and their handling.
For historical reasons, base field types (e.g. StringItem, IntegerItem, EntityReferenceItem) are directly exposed as Typed Data (with ID's like string_field, integer_field, entity_reference_field).
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.
To be able to instantiate all field types using the field type plugin manager, base fields need to be exposed as @FieldType plugins too. To keep them apart, they have a configurable = TRUE/FALSE flag, that indicates if they *can* be used to create configurable fields, but they can also be used as base fields. Classes that want to support configurable fields need to implement ConfigFieldIteminterface (and extend from the corresponding base class), they also automatically get the corresponding ConfigFieldItemList list class.
This is the what this patch does, All *Item.php classes are moved from \Drupal\Core\Entity\Plugin\DataType to ..Plugin\field\field_type.
That results in a number of smaller and bigger problems:
- We get naming conflicts because. Notably the email and entity_reference field types currently have a simple version that's in Core and have modules that provide widgets/formatters and so on. The patch solves that problem in two different ways:
-- entity_reference.module alters the field type definition and replaces it using it's own implementation. This means that enabling entity_reference.module results in a different runtime class being used for base fields like $node->uid.
-- Same for EmailItem/email.module.
- We need to prevent non-configurable fields from showing up in the field UI. This patch adds a new method, getConfigurableDefinitions(), to the field type plugin manager to make those easily accessible.
- Base field names change from *_field to field_item:*. To avoid having to change ~10 baseFieldDefinition() implementation, this patches introduces a simply mapping for those names. This is temporary until lands, which will replace those magic naming patterns with speaking methods like $definition->getFieldType(). The mapping layer means that we don't have to change those methods twice.
- The fact that the configurable entity reference implementation is used resulted in some interesting test fails because they considered references to uid as a new entity and tried to auto-save it. This has been prevented by overriding isNew() for users and return FALSE for uid 0, which is a correct fix anyway.
- CommentItem changes: > It has field properties defined as entity_reference_field. This is completely bogus, a field item can't have field types as properties. It only works because we never instantiate it thanks to the lazy-loading logic in field items.
- Last, validation constraint messages are currently not dynamic, so configurable field type classes create a dynamic constraint that allows them to add a validation message during runtime. The result is that we suddently have two validation fails when an e-mail is too long in a test. This will be unified in https://drupal.org/node/2012690. It's not a new behavior, it would have already happened for configurable fields, now it also happens for base fields.
See follow-up issues references above.
We also need to continue with the approach discussed in Prague, to use the field type plugin manager for instantiating field item classes and decouble field item classes from TypedDataInterface. This is a blocker for additional work on that.
User interface changes
As outlined above, the plugin ID's change.
Original report by @fago
defines a new field_type plugin, once it's in we can convert entity field types over to make use of it. However for that, we need to make field.module respect the "configurable" flag such that it does not deal with non-configurable fields.
PASSED: [[SimpleTest]]: [MySQL] 58,984 pass(es).
PASSED: [[SimpleTest]]: [MySQL] 58,637 pass(es).
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch convert_entity_field_type-73.patch. Unable to apply patch. See the log in the details link for more information.