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.

Files: 
CommentFileSizeAuthor
#6 config.next_.uninstall.6.patch8.58 KBsun
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch config.next_.uninstall.6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Why 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?

Why 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?

IMO 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.

Cross-referencing #1479492: [policy] Define standards for naming and granularity of config files, as it should help answer name-spacing questions.

Title:Determine method for automatically cleaning up non-default configuration files after a module is uninstalledClean up all (non-default) configuration (files) when a module is uninstalled
Category:feature» task

My answer to this is straightforward, as already stated in #1560060: [meta] Configuration system roadmap and architecture clean-up:

  1. Turn the configuration object name prefix into a formal namespace.
  2. Only the namespace owner is supposed to write to or delete the configuration objects within the namespace.
  3. On uninstall, rm $module . '.*';

Note: #1496542-73: Convert site information to config system begins to introduce the formal namespacing already for the D7->D8 upgrade path.

Status:Active» Needs review
StatusFileSize
new8.58 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch config.next_.uninstall.6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Status:Needs review» Needs work

The last submitted patch, config.next_.uninstall.6.patch, failed testing.

Status:Needs work» Fixed

Automatically closed -- issue fixed for 2 weeks with no activity.