Voting starts in March for the Drupal Association Board election.
Postponed on, which is introducing the BaseFieldOverride class described in this issue.
- When a new 'base_field_override' config entity is created, BaseFieldOverride::preSave() calls the target entity type's storage handler's onFieldDefinitionUpdate() method, passing it the base field definition as the "previous" definition. And similarly, when the override config entity is deleted, BaseFieldOverride::postDelete() calls onFieldDefinitionUpdate, passing it the base field definition as the "new" definition.
- However, if it happens that a base_field_override config entity is being added to or deleted from a site that also implements an override via ContentEntityInterface::bundleFieldDefinitions(), then the above behavior is incorrect, since the previous definition prior to base_field_override insertion and the new definition after base_field_override deletion is the one returned by ContentEntityInterface::bundleFieldDefinitions(), rather than the base definition.
- The above might be an extreme edge case, because using ContentEntityInterface::bundleFieldDefinitions() rather than config to override base field definition is specifically intended for when you need you content entity type completely decoupled from config, in which case there shouldn't be code adding and removing base_field_override config entities for it.
- Also, it's not really clear what FieldableEntityStorageDefinitionInterface::onFieldDefinitionUpdate() is even for. The only implementation of it in HEAD is a completely empty function, even after . Perhaps we should consider removing it? Do storage handlers need to be notified of non-storage-related changes to field definitions?
Discuss the above and figure out what to do.