Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.We have several config entity types that have a 'locked' property:
- Field
- Language
- DateFormat
- Menu
For fields, all it means is that certain UI operations are prohibited, but the field can still be changed/deleted via API calls or a config deployment. We have an entire parallel concept and implementation of base fields to support the situation of code needing to rely on a field existing independently of config.
For the others, I'm not clear on what locked is intended to mean. However, I tested whether it's possible to delete a locked menu via a config deployment, and in fact, it is. But, doing so for the system.menu.admin.yml menu results in a WSOD because menu link rebuilding then fatals, because there are code-defined links (here I'm considering *.yml files in a module's root directory as part of the module's code, because only YAML files within the config directory are config) that reference that menu. I suspect similar code dependencies on locked date formats and languages also exist and would fatal if those "locked" entities got deleted via a config deployment, but haven't tested that.
Some questions resulting from this:
- Should we enforce "locked" at the deployment and entity CRUD API levels, thereby making it legitimate for code to depend on a locked entity existing? If so, that potentially opens the door to (though wouldn't require) removing the entire concept of base fields, and implement them as locked fields instead (see #2287727-15: Rename FieldConfig to FieldStorageConfig).
- Should we define "locked" as merely a UI concept, and not enforce it at the deployment or CRUD levels? In which case, we need to fix code like menu link rebuilding to still function if the code-referenced config entity doesn't exist.
- Should we make this decision on a per-entity-type basis, in which case, we need to decide for each of the ones in HEAD, and document the meaning on each corresponding entity class's declaration of the $locked property.
Comments
Comment #1
effulgentsia CreditAttribution: effulgentsia commentedComment #2
tim.plunkettAlso consider filter formats. The fallback format cannot be deleted or disabled.
Comment #3
catchProbably #1. It still needs to be possible to delete a locked configuration entity (at least during uninstall), but we could likely add an explicit unlock operation to allow that.
Comment #4
larowlanPretty sure forum would die miserably if locked container field was deleted
Comment #5
tstoecklerAlso note that even in the UI 'locked' has different semantics. For date formats it means "cannot be edited or deleted". For most other config entities it means "cannot be deleted". Notably NodeType is missing from the list in the issue summary. See also #2084567: Implement a EntityLockedInterface and service to allow locking entities where we stumbled upon that when trying to unify the different approaches with a single interface.
Comment #6
catchThe clarification is a task. If we have specific core bugs where deletion breaks code, those would be bugs with those modules.
Comment #10
andypostComment #11
andypostComment #23
Anybody