Contrib.social

Re-implement module disabling in a temporary/debugging capacity that is environment aware and explicit about risks to data integrity

Open on Drupal.org →
Created on 4 September 2013, almost 12 years ago
Updated 8 June 2025, about 1 month ago

Problem/Motivation

In #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed → many people were quite vocally against the removal of "disabled modules" in Drupal.

The original definition of "disabled modules" is:

- The module code exists on the file system
- The module was installed and enabled at some point in time
- Any data/configuration associated with the module is still in the database/system
- The module cannot run any hooks, none of its code will be automatically included and run by Drupal
- The module can be re-enabled without first removing any data/configuration from previous times that the module was enabled

This is very similar in concept to opening up the .module file and commenting out the whole thing without reading it (although it has been pointed out that you can't literally do that due to other modules using module_exists()).

There are 3 main reasons that people used this functionality originally, and because (situationally) they could be quite important, it has been stated that we must address each:

- 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) - This issue
- 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) - Issue #2186751: Core should provide a framework for modules to prevent performance intensive functionality when certain criteria are met →
- "Shut up for a minute" purposes: Migrate module, for example, temporarily disables modules such as comment_notify during migrations. (#307) - ✨ Provide a global and/or per-module "quiet mode" where messages/notifications from modules are suppressed Postponed: needs info

Since there were good reasons to remove the original disabled functionality, it has also been stated in #1 that we want to meet the following requirements so as to avoid DX regressions:

There should be no implications for core/contrib, no trade-offs whatsoever if we bring this back. Core and contrib developers should never have to worry about maintaining data integrity for their modules when disabled / re-enabled / whatever. In fact, the module should be completely unaware of it's state. Either it's code is loaded, or it's not. This also means that there should not be any enable/disable hooks.

Proposed resolution

The original proposed resolution here has multiple facets:

- 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

It was pointed out in multiple comments that these conditions are still either inadequate, extremely difficult to implement/maintain or would directly invalidate 2 of the stated use-cases (what's the point of turning off a module for performance reasons if it forces the site into maintenance mode?) - Comments #1, #2, #3, #8, #9, #10, #11, #12, #13, #17, #19, #21, #24, #27, #32, #33, #34. For that reason we are NOT dealing with use-cases other than debugging and fielding support requests in this issue and other issues have been opened to handle the other use-cases.

Another resolution, from the parent thread but not so much mentioned here, is a much more complex framework for "soft" and "hard" dependencies, as well as multi-directional dependencies and new hooks that could be used to ease data management as modules are enabled/disabled and also to conditionally lock modules in enabled/disabled states depending on how other modules interact with their data and what states those modules are in. It was identified that this would be "a lot of work" both now and in the future. So far nobody has put their hand up to tackle this approach seriously with a proof of concept patch.

Another resolution, from #45 is that we allow modules to state their own compatibility-with-disable flag that allows the module to be disabled either permanently (the module has no persistent data that could be damaged), temporarily (the module can be disabled provided the site is in "read only" mode), or not at all (the module has some data that could be damaged and it's difficult/impossible to ensure that "read only" mode - whatever that ends up meaning - is safe enough). This flag would need to be alterable, so as to allow modules working with other module's data to signify that the "safeness" level has changed.

Another resolution is for Core to provide an API/UI that modules can implement/leverage to allow users/developers to disable components of the module's functionality rather than the whole module while providing a consistent UX/DX. This approach takes a lead from popular contrib modules like Views, Rules, Context, Panels, etc...

Remaining tasks

Propose a way to disable modules that meets the use case of debugging a broken module and/or fielding support requests for a module and does not (re)introduce unreasonable complexities, learning curves and/or limitations for Drupal developers.

User interface changes

Likely some changes to the module management pages.

API changes

Likely many changes to low-level code.

Original report by @webchick →

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

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

🌱 Plan
Status

Active

Version

11.0 🔥

Component

extension system

Created by

🇨🇦Canada webchick Vancouver 🇨🇦

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

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

  • Comment about 1 month ago →
    🇺🇸United States nicxvan

    I think this belongs in extension, but I'm not sure we do really want to bring this back.

  • Comment about 1 month ago →
    🇨🇦Canada xmacinfo Canada

    Instead of disabling temporarily a module, like in Drupal 7, in Drupal 11 or 12 we should expand the uninstall functionality to offer exporting to one or more YML files the configuration(s) owned by that module.

    The exported configuration would not be used to perform a complete restore, as in most cases, the exported configs would not cover everything related to that module. For example, disabling a field formatter module, following this, should be able to export its own config but not the field formatter settings of a field, if the “export the module config” checkbox enabled.

    A site owner would then be able to reinstall the module and use config import to load one or more config files to recover the module own configs. Here, again taking the example of a field formatter, the recovering of the module’s config would not recover the settings of each field formatter.

  • First commit to issue fork.
  • Comment 17 days ago →
    🇺🇸United States nicxvan

    @xmacinfo that might be a great issue! Can you create a new issue with that idea of one doesn't exist so we can track that?

    I'm going to postpone this for a couple of reasons.

    The contrib module created https://www.drupal.org/project/disable_modules → wish tells you to use https://www.drupal.org/project/config_split → .

    It's been 12 years since disabling had been removed.

    The two biggest concerns I see about adding this back:

    Debugging, but you can simulate most of that disabling is by just commenting out or deleting hooks temporarily locally and clearing cache.

    Performance, again you can add wrappers to hooks to disable them if you need to. It's not trivial, but if you want your site to be stable a more inebriated approach here is much better than what disable used to provide.

  • Comment 17 days ago →
    🇺🇸United States nicxvan
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024