In that issue, several people made a passionate plea to keep this functionality for (at least) the following legitimate use cases:
- Debugging purposes: An error's appearing on the production site from foo module, so turn off foo module until it can be tracked down. (#278)
- Performance purposes: Your site's about to be mentioned on Oprah, so turn off the fantabulous tag generator feature until after the traffic dies down. (#121)
- "Shut up for a minute" purposes: Migrate module, for example, temporarily disables modules such as comment_notify during migrations. (#307)
These people were, to a large extent, overruled by people who (correctly) point out that disabling modules and then making changes to the database schemas can cause data integrity problems including up to leaving the site in an unrecoverable state. Therefore, there's a 90%+ chance of that patch getting committed.
However, the idea of disabling modules on a temporary basis still has a lot of merit. This issue is to figure out how we can do that.
Two suggestions that I think have merit here are:
- Restore the disable modules UI, but do it under the "Development" menu item (rather than right on the main modules page) so it's a bit more hidden and obvious that it's for temporary purposes only.
- Disallow running update.php while modules are disabled.
- Either force, or default to, maintenance mode when the module is disabled.
- Consider disabling CRUD operations on content/config entities when the site is in maintenance mode