Updated: Comment #0


A follow-up to #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed

In some edge cases you may need to refer to config or data even after a module in uninstalled.

Or, if you are a developer, you could migrate that config or data back in if you later re-install the module or install a related one that can use the same data. In comment #227 https://drupal.org/node/1199946#comment-7538503 it was suggested that core have a general backup/restore functionality. I don't know that we want to build that for core, but this could feed into a contrib solution for "unarchiving".

In addition, at least the option to archive config and/or data might take some of the fear out of having only the uninstall option.

Proposed resolution

When uninstalling a set of modules, provide default off option to archive configuration or tables. The tables can be discovered via hook_schema (e.g. archive by renaming them perhaps including the module's schema version instead of dropping them).

Remaining tasks


User interface changes

Added option for uninstall process. Needs perhaps help text and documentation.

API changes


#1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed


pwolanin’s picture

Issue summary: View changes

Updated issue summary.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.