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.Problem/Motivation
Currently, in general, we want to enforce dependencies. That is good but some configurations are way to complicated to remove because of a minor failed dependency. especially when there is a fallback for when dependencies are not met. This has come into play on #2468045: When deleting a content type field, users do not realize the related View also is deleted because when a view depends on a field and that field is removed, the view is removed. #2442757: Move the field storage deletion if the last field has been removed to the UI layer proposes to bring the field storage dependency management to the UI layer which is a good first step. If the site builder is not moving too fast, and notices they are about to remove a view, they can go update the view before removing the field.
But there is allot of configuration in a view (As with other types of configuration). Remove an entire view because a field removal when there is a fallback field (or other) handler is overkill. Contrib configuration will inevitably become complex as well. When a contrib module defines a fallback for unmet configuration dependencies, that dependency should be considered a soft dependency.
Configuration that depends on content is another example of configuration that might need to be considered a soft dependency.
Proposed resolution
Introduce a "Soft" dependency flag.
Provide warnings but not enforcement for configuration dependencies that are flagged as "Soft" when a dependency is about to be broken.
Remaining tasks
Discuss approach and apply.
User interface changes
Adds additional warning to the UI when a dependency is gong to be broken.
API changes
Adds a "Soft" flag to a dependency.
Data model changes
None.
Comments
Comment #2
er.manojsharma CreditAttribution: er.manojsharma at Publicis Sapient for Publicis Sapient commented@Jaesin did we finalize the approach to complete this task?
Comment #3
er.manojsharma CreditAttribution: er.manojsharma at Publicis Sapient for Publicis Sapient commentedComment #4
Jaesin CreditAttribution: Jaesin at Chapter Three commentedComment #5
swentel CreditAttribution: swentel commentedPath module has similar 'funny' problem: uninstall the path module and all entity form displays will be removed. Kind of annoying :)
However, I'm not in favor of a 'soft' dependency flag if it means that a configuration object would still have a reference to another object that doesn't exist anymore.
I'd rather see different approach which we already have in core which is used when we're deleting fields. Go to any manage fields screen, click on delete and you're informed which config entities are going to be updated (usually form and view displays). What happens is that in those config entities the reference to that field is going to be removed. Way more cleaner that a) deleting (for sure) or b) leave a reference, but then having to implement/show this in the UI and having to account for it as well during rendering/requests etc.
Comment #6
dawehnerYeah this kind of change though kinda needs to be solved on a case by case.
For everything which is just rendered it is indeed IMHO the right solution to just not show it anymore. For views filters, this might be different. You now potentially show much more
content than you previously configured to.
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedFWIW, i like swentel's idea in #5.
perhaps we can have a global policy which is one of:
1. 'never alter a dependent object, just fail'
2. 'delete the references only in the dependent object'
3. 'delete the dependent object'
dawehner suggested we could also apply that per-type.
Comment #8
catchIn general #1 we treat as 'don't allow uninstall/delete'.
I agree those three are the right approaches, and we should not have soft configuration dependencies as such since it's impossible for a module to manage it's own stuff when it's not there in terms of update hooks etc.
Some cases we'll want to just choose one (for example not allowing content entity delete, since we can't do bulk deletes safely in core yet), others we might want to allow a choice, this is where we currently have bugs in core and the patterns aren't really defined properly.
Re-titling and moving to a plan for now.