BaseFieldOverride fails to take into account ContentEntityInterface::bundleFieldDefinitions() when invoking onFieldDefinitionUpdate()

Created on 14 August 2014, almost 10 years ago
Updated 2 November 2023, 8 months ago

Postponed on #2283977: Create a new ConfigEntity type for storing bundle-specific customizations of base fields β†’ , which is introducing the BaseFieldOverride class described in this issue.

Problem/Motivation

  • 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 #1498720: [meta] Make the entity storage system handle changes in the entity and field schema definitions β†’ . Perhaps we should consider removing it? Do storage handlers need to be notified of non-storage-related changes to field definitions?

Proposed resolution

Discuss the above and figure out what to do.

Remaining tasks

User interface changes

API changes

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
FieldΒ  β†’

Last updated 25 minutes ago

Created by

πŸ‡ΊπŸ‡ΈUnited States effulgentsia

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.69.0 2024