Updated: Comment #10
Whileconcerns the issue of default configuration, this issue is about configuration dependencies when a module is uninstalled. ( covers installation.)
During lengthy IRC and discussion at Prague with catch, beejeebus, alexpott, mtift, and others, we came to a general consensus that we should create an API that would allow Module A to declare that it has config entities that depend on Module B. When Module B is being uninstalled this API will be used to inform the user that uninstallation will result in their removal.
Discussion points raised in Prague:
For dual-ownership config entities, what should happen on uninstall? Three options:
- Allow user to back out or delete all your things
- Disallow uninstall with soft dependencies
- Just do nothing and let the site break
If we allow deleting all the things we need:
- A confirmation screen listing everything that will be deleted
- We should have a UI to batch deletions for (e.g.) field deletions
- We should have an API to declare soft dependencies; it should not be in field_system_info()
- Bundles are not formalized, so field API can't implement this dependency management. Can the entity type provider, e.g. node? There can be any number of bundle providers dependent on one entity type provider.
- Also would need to create a robust batching API.
We also need to consider if deleting the forum node type also implies those field instances are being deleted? And do we need to tell the user? (we should provide a summary, e.g. this will delete the node type and N nodes)
Store dependencies in the configuration entity files in a new dependencies key. For example,
Introduce a ConfigDependencyManager that is able to read configuration files and construct a graph to determine dependencies between configuration entities or determine which entities are dependent on a specific extension (module or theme).
What dependencies do config entities have
|Config entity type||Dependencies|
|block||The module that provides the plugin. The theme.|
|breakpoint||if the source is theme or module it depends on that. Currently handled by the module - all this code can be removed (yay!).|
|breakpoint_group||the breakpoint entities, if the source is theme or module that too. Currently handled by the module - all this code can be removed (yay!).|
|editor||The filter format it is attached to. The module that supplies the editor plugin. Follow up to convert Editor entity to EntityWithPluginBagInterface and therefore the editor dependency will exist automatically due to ConfigEntityBase::preSave()|
|entity_form_display||the form mode entity, the config entity if one provides the bundle, the fields, the widget providers|
|form_mode||module that provides the target entity type|
|entity_view_display||the view mode entity, the config entity if one provides the bundle, the fields, the formatter providers|
|view_mode||module that provides the target entity type|
|field_config||module that provides the field type|
|field_instance_config||field_config entity, the entity that provides the bundle (eg. node type)|
|filter_format||the modules that supply the filter plugins in use|
|image_style||the modules that supply the image effect plugins in use|
|node_type||This has a settings key that modules had into but uninstall is handled. Should be converted to the dependency system if these are converted to plugins|
|picture_mapping||The breakpoint group|
|rdf_mapping||the bundle entity|
|search_page||the module that provides the plugin|
|action||the modules that supply the action plugins in use|
|tour||The module the tour is assigned to. The Tip plugin providers. Follow up to convert Tour entity to EntityWithPluginBagInterface and therefore the Tip plugin provider dependency will exist automatically due to ConfigEntityBase::preSave()|
|view||modules that provide the plugins if not optional, field_instances_config entities?|
- Design soft dependency API
- Write patch
User interface changes
- Entities that will be removed by uninstalling a module are list on the confirm form.
- Theme's are never uninstalled so there is nothing to do here. will change this.
A new API to allow one module to indicate it has soft dependencies through config entities it "owns" (i.e. where it provides the config entity type) on another modules.
|#87||ConfigDependency.png||66.59 KB||Gábor Hojtsy|
|PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 65,162 pass(es). |
[ View ]
|FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 65,132 pass(es), 0 fail(s), and 2 exception(s). |
[ View ]