Implement automated and granular CMI snapshots to back up files when a module is uninstalled

Created on 23 June 2015, almost 10 years ago

Updated 28 May 2025, 2 days ago

Problem/Motivation

TL;DR: we cannot assume that everybody's going to leverage version control to handle CMI file changes. But what we know for sure is that every D8 user will at some point need to 'disable' (uninstall) a module without losing the associated configuration.

Per #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed → modules can no longer be disabled. 📌 [PP-3] Figure out what to do with the install/uninstall modules page Postponed is going to handle the UX for site builders to better understand how to deal with the missing 'disable' state. We're however left in a state in which site builders will not necessarily know how to not lose their configuration data if/when they need to uninstall a module for any given reason (e.g. custom module is breaking the site)

In core we can:

Leverage the single export feature => Very easy to understand for site builders (/admin/config/development/configuration/single/export) but what happens when you have, say, 5+ config files to manually back up? What if you miss one and can't import successfully next (e.g. field storage dependency)? Even more tricky, what if only part of the configuration is being imported and breaks the site's functionality but nobody immediately sees it? There *is* an alternative if you leverage the Features module, but it's targeted at advanced users.
Leverage the full export feature => works as above except we basically snapshot the full conf and download a tar.gz archive locally that we can later import on the site. Would prevent issues with the simple export/import but it's not super flexible. E.g. in a distributed team (say, UK and Australia) what happens when John (Australia) implements 10s of changes for several configuration files via the GUI, then manually backs up the conf locally to uninstall a bunch of modules, then Bob (UK) takes over the development for the day and needs the original backup that only John has? John is not around for the rest of the day and the team is stuck or needs to find alternatives (restoring from backup? recreating the configuration? etc.) but there's no way to have the latest and greatest archive that John has.

We could also leverage a contrib module (maybe improve disabled_modules → ?) to automatically back up config files when a module is disabled => would work as the below proposal, but would also mean you'd have to have the module available in the codebase/installed before being able to rely on any of those frequent activities.

Proposed resolution

Implement automated and granular CMI snapshots to back up files when a module is uninstalled => in essence, this could be as simple as dumping the specific config files to /tmp when a module is uninstalled. Or, we could ideally make this a customizable path for customers to set where to back up CMI files (e.g. under files/*). In other words, the workflow would be such as each time you'd uninstall a module, its config file(s) would be backed up automatically behind the scenes in a given location, for future potential re-use. Could be with the form: cmi_backup/mymodule/configfile.yml / cmi_backup/mymodule/configfile1.yml / cmi_backup/myothermodule/otherconfigfile.yml, etc.

Remaining tasks

Write patch. Optionally, perform UX review if there are user interface changes involved.

User interface changes

TBD.

API changes

None.

Data model changes

None.

✨ Feature request

Status

Postponed: needs info

Version

11.0 🔥

Component

configuration system

Created by

🇫🇷France anavarre 🇪🇺

Live updates comments and jobs are added and updated live.

Configuration system

stale-issue-cleanup
To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 2 days ago →
🇺🇸United States smustgrave
Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024