Follow-on from #1444766: Determine method for automatically cleaning up configuration after a module is uninstalled. During use a module may create non-default configuration files; that is, files that are added to the live configuration directory, but are not provided as defaults within the module's config directory. For example, one may use image.module to create custom image styles with the GUI. Files will then be created for each image style, and will not currently be automatically removed when uninstalling the module.
There is a policy/meta issue here, namely, should it be the responsibility of core to clean up these files, or should individual modules be expected to implement hook_uninstall and clean up any non-default config files? If the former is true, we need to determine how to associate config files with their module so that they may be safely removed. The easiest method for doing this is probably to make a policy that all modules must namespace their config files by prefixing them with the name of the module.
Comment | File | Size | Author |
---|---|---|---|
#6 | config.next_.uninstall.6.patch | 8.58 KB | sun |
Comments
Comment #1
wjaspers CreditAttribution: wjaspers commentedWhy not leave the config file behind and prompt the user to restore or trash it if and when the module is attempted to be re-installed?
Comment #2
acrollet CreditAttribution: acrollet commentedIMO this would be a nice, user-friendly behavior to provide, but not necessarily site/system admin friendly. The live config dir should probably ideally only contain configurations that are in use. I could personally see adding a directory for disabled configuration files, but one is still left with the issue of how to determine which files belong to which module. At any rate, the decision is over my head.
Comment #3
acrollet CreditAttribution: acrollet commentedCross-referencing #1479492: [policy] Define standards for naming and granularity of config files, as it should help answer name-spacing questions.
Comment #4
sunMy answer to this is straightforward, as already stated in #1560060: [meta] Configuration system roadmap and architecture clean-up:
rm $module . '.*';
Comment #5
sunNote: #1496542-73: Convert site information to config system begins to introduce the formal namespacing already for the D7->D8 upgrade path.
Comment #6
sunExtract from #1626584: Combine configuration system changes to verify they are compatible
Comment #8
sunResolved as part of #1605324: Configuration system cleanup and rearchitecture