Disabled modules are broken beyond repair

#1052692: New import API for major version upgrades (was migrate module) is option 1 of those two choices.

"It would be very tempting to change the states we support to these:

Uninstalled
Installed"

I don't see how we can do that... the ability to disable a module temporarily is important when troubleshooting. Uninstalling is destructive.

Right, my position on that issue is that we currently pretend that you can install Drupal, then when it comes time to update it to the next major release, just run update.php and come out the other side. This is only true if you have an extremely basic site, otherwise we are lying to ourselves and everyone else by trying to maintain that fallacy. You can trace the history of that issue at least back to #194310: Check / run updates of disabled modules and #80526: Core modules need their updates in their own files.

Extremely simple sites will have extremely simple migrations, and this would also enforce that people don't run upgrades on their actual live database ever (which lots of people do with simple sites, then end up with unrecoverable breakage when they hit a bug - even the upgrade instructions recommend 'backing up' instead of actually running the upgrade on a copy). It will not be simple to implement the migrate issue but it may be a pre-requisite for this one to be resolved properly.

However it is the same overall issue for disabling and re-enabling modules without updates even - if you have a module that doesn't do much, and especially doesn't interact wi th other modules much, then it's fine to disable it or enable it as you like, but if it's even moderately complex or dealing with dynamic things like fields, anything that affects actual content, then it quickly becomes a nightmare where we are piling hacks upon hacks to support it being in that state.

If the module is simple, then disabling is not really going to be much more destructive than uninstalling - you might lose some configuration options you set up - but config should be exportable in Drupal 8 so even that is not going to be such a big deal.

If it has it's own non-configuration data, or other modules and data are in the system that depend on the module, then if you just disable it with current D6/7/8 your site is in some kind of inconsistent state already. Currently we run somewhere between allowing people to shoot themselves in the foot, implementing ugly workarounds, and one-offs that prevent modules being disabled when 'other stuff in the system' depends on them (as opposed to a listed dependency in a .info file for another module). That goes back to #232327: Deleting node type leaves orphan nodes and older issues as well.

"If the module is simple, then disabling is not really going to be much more destructive than uninstalling - you might lose some configuration options you set up - but config should be exportable in Drupal 8 so even that is not going to be such a big deal."

No, this isn't accurate. Take Aggregator module, for example. That table has 400+ rows of data in it in Drupal.org's database. Disable it, and nothing's likely to happen since nothing else depends on it (unless Aggregator items get made entities in D8, I suppose), but uninstall it and bye-bye Drupal Planet.

I kind of liked the system we introduced in one of those issues where basically if there are any X left (where X is some kind of shared data type other modules depend on; in this case field data iirc), don't allow uninstallation unless they're manually removed first. That's a pattern that's pretty easy to enforce throughout core and contrib, if we can get agreement on it.

For debugging:

Add functionality similar to http://drupal.org/project/environment_modules to devel (or even a special admin page in core).

Basically we'd remove the disabled vs. uninstall distinction in the modules screen, but allow people to actually disable module hooks from being run and/or code loaded at all from somewhere else. That somewhere else could make it clear this should only be used as a temporary measure and that modules should not be left in that state for long on a production site.

For update.php:

- have module_implements() thrown an exception if it's called during update.php - this would enforce use of the _update_1234_foo_bar() functions for updates. Either that or just have it return an empty array on there.

Another example where this is completely broken #1204820: Entity providing modules must call field_attach_delete_bundle() in hook_uninstall() - entity module provides various stuff centrally for other modules that can specify it as a dependency. However if you disable all those modules and also disable entity module, then entity_modules_uninstalled() won't get run when you disable the dependent modules.

Tagging with framework, since this is primarily about resolving interdependencies.

Subscribe. Tricky problem.

This problem can be fixed by imposing a few rules:

1) Modules can't implement more than one of hook_field_storage_info(), hook_field_info() or hook_entity_info() (and their _alter counterparts). This means refactoring storage and fields as separate modules, and modules using these fields must declare them as dependencies.

2) Any module which can create content (entity, field, node) must clean up content after itself. 'Cleaning up after itself' means at least marking its content as deletable without having to call a module-based hook, and at best doing the actual deed.

3) Modules should be able to block their own disabling and uninstallation: hook_can_disable(), hook_can_uninstall(). These hooks would live in the install file, and be called while creating the disable/uninstall module forms, not during the act. These hooks would return messages explaining to the user what needs to happen before the module can be disabled or uninstalled (or TRUE, because it can be disabled/uninstalled). A 'why can't I uninstall this?' link would be added to the form, similar to what Coder does with the 'code review' link, and following this link would show the explanation.

Thoughts? :-)

I was just thinking the other day (#1268974-22: For disabled node types with 'base' != 'node_content', _node_types_build() does not return data about the type.) about how to migrate toward cleaner uninstallation without breaking all sorts of existing modules. I'd love to see different uninstall policies that one could implement (e.g. hook_full_uninstall(), hook_metadata_uninstall(), etc.) with hook_uninstall() marked for deprecation. I liked the idea because the UI could be extended for finer administrative control and for certain sites I might like to filter out modules that don't implement hook_full_uninstall(), for instance.

Subscribing

We allow modules to be disabled, but we do not allow update.php to run in this state.

So in order to upgrade from D7 to D8, or even from 8.1 to 8.2, it will be necessary to first remove all non-core modules and purge all associated data from the database.

This is a lovely idea which I am sure will quickly gain widespread community support.

You mocked that approach in #3

Sorry; I did correct myself. When upgrading from d6 to d7, I wound up manually importing the data anyway. As I said in #3 and you appeared to confirm in #15, that's probably the way to go. Newbies and managers who are considering Drupal will be disappointed to hear that they will have to start virtually from scratch at every major version upgrade, but it's probably better to admit failure in the beginning than to apologize for it later.

Minor version upgrades do not require that you disable all contrib modules.

Okay, noted; thanks.

I think you have some good ideas but your sarcasm is very hard to work with.

I suspect that you didn't find any humor in my dangerously user-friendly comment, either. But seriously, if I took the time to format and submit such a patch, would I be wasting my time? Or do such checks belong in Coder rather than system_status()?

At any rate, we need to provide some kind of feedback when people break our implicit don't do that rules.

The compromise is between #0 which says 'No more disabled modules' and webchick's 'We need to briefly disable code for debug purposes and keep data around in the meanwhile'.

Yes, there are a lot of related issues here. I won't change the title of this issue because I smile every time I see it. But perhaps we could narrow the scope to 'disallow update.php when any module is disabled'. Thats a nice win, and pretty easily accomplished. IMO that does not have to wait until #1052692: New import API for major version upgrades (was migrate module) which probably won't land until we are much closer to release.

As for your last request - anyone is welcome to write any patch they wish. system_requirements() checks do seem like a (small) piece of the solution. Now that i downscoped this issue, this isn't the best place IMO.

I've opened #1330472: clean up entity-related data on module uninstall.

Short version: The only solution I came up with requires us to enforce *no* other modules are disabled when an entity-providing module is uninstalled.

If a module has never been installed on a site there is no problem. The issue here is about (dropping support for) enabling a module, disabling it, then leaving it in that state for any period if time and expecting everything to magically work which is what core attempts now. Just having a module in the file system doesn't count as installed.

If the module is in the filesystem but not enabled or installed, it will show up as an unchecked listing on the modules page.

If the module is in the filesystem, was enabled at some point, is now disabled, but was not uninstalled, it will show up in the Uninstall tab of the modules page.

Note the awkwardness of that last sentence, and behold the UX problem for disabled modules. :-)

Disabling the module isn't that dangerous any more, since it will warn you that you can't uninstall it before its content is gone.

Modules should probably look more like themes, which can be enabled/disabled and default/not default.

Ugh, there is no way in heck we could possibly explain to 99% of Drupal's users what to do with checkboxes about "do and do not run X hook." :(

We could even have the ability to mark certain hooks as not possible to disable (hook_entity_info(), hook_field_info()).
So that way even if the user clicks "disable", that leaves a few hooks alive, so less chance of breakage.

Not sure if any of this makes sense, just trying to offer a way to slay the dragon.

We came up with a couple easy first steps with decent UX in IRC:

1. Do not let update.php be run when there are disabled modules. Inform the user that the modules should be either enabled or uninstalled before proceeding, with links.
2. Add a warning to the status report when there are disabled modules, with a list, a caveat that leaving modules disabled may result in bad things, and links to enable or uninstall.

I have a slightly different perspective on this issue. I don't think the problem is with the concept of disabled modules itself, but rather with the specific way we've chosen to define them in Drupal. So before we throw out the concept entirely (or add warnings to the UI about the peculiar consequences of our current definition), maybe we should rethink the definition?

In Drupal right now a "disabled module" means two totally different things:

1. The module's functionality disappears from the user interface.
2. The module's functionality disappears from the API (the code isn't loaded, its hook implementations aren't invoked, etc).

The only problems I'm aware of are with #2, not #1. So, strawman proposal: Is it possible to get rid of #2 only? In other words, when a module is "disabled", maybe its code should still be there running in the background and managing whatever data it still needs to manage. But it would be responsible for staying out of the UI.

The naive way to do that would just be to continue invoking all hooks, but the module itself uses statements like "if module_exists('me')" to avoid running the UI-related code that shouldn't be run. That's not great DX, though, and to be robust we probably need the module invoking the hook to make the decision sometimes also. So we'd have to think a lot more about the consequences of this, and whether it would require a cleaner separation between hooks that affect the UI and hooks that don't, etc. But I think it's worth thinking about.

One obvious consequence would be performance. Under this plan, disabling a module wouldn't improve the performance of your site anywhere near as much as it does now, since most of the code would still be running. But I think that's fine. The best practice could be "to improve performance, uninstall all modules you aren't using." That's already the best practice now anyway to some extent (since uninstalling removes cruft from the variables table that gets loaded on every page, etc). It would just become more of a best practice going forward.

#42 doesn't make sense to me really. What happens if you "hide" a node access module? Its interface goes away, but it continues to affect access control? Am I misunderstanding? How would you "hide" access control without turning it off?

So yeah, the way I described it originally (turning off the user interface vs. turning off the API) may have been a bit simplistic. It's not quite along those dividing lines really.

I'd like to suggest a new (half-serious) name for this concept: "hibernation"

When a module is put into hibernation, it only does the minimum things necessary to stay alive, so that when it wakes up later it will be happy and functional. (By contrast, what we have now is more like "zombie modules". When we disable a module, we kill it almost entirely, but then expect it will be fine when we bring it back to life later... Instead, it just feasts on our brains.)

So, does this concept of "hibernated" modules makes sense? I think it could really work, but I'm a little worried about whether the DX tradeoff is worth it. No matter how it's implemented, it will necessarily add more things for module developers to think about. And if they don't do it right, we'll have lots of "I turned this module off but parts of it are still on" bug reports.

I'm really not convinced by this 'partially disabled' notion. It won't help with things like debugging, since parts of the module still run.

Having encountered a problem with Commerce and fields from disabled modules yesterday, I was thinking about this problem as I wonder whether we can't take an idea from Views: the 'broken' handler. When I build a View and add a plugin or a handler that's from a contrib module, and later disable that module, the view still broadly works, but the specific handler is marked as being broken. I can remove it, or re-enable the module and in both cases it's ok.

The main problems with disabled modules are that there are things in the database that need code to work, and the code is now absent. These are mainly: entity types, node types, field types, field widgets, and field formatters. Could we provide a 'broken' type or handler for each of these to step in when the expected code is missing?

I'm thinking these would do things like:

- for node types, show the node in strikethrough on the node admin page, and prevent it being edited
- for field components, show the field as 'disabled' on entity display and forms

> Traditionally, Drupal handles buggy code by failing spectacularly rather than gracefully

A 'broken' handler doesn't mean buggy code. It means a fallback component that does pretty much nothing apart from tell the user that the actually required component is missing.

So could we disallow deleting of entities that are in that state?

I don't think we're expecting a site with disabled modules to be fully operational, just not keeling over and usable for debugging and upgrades.

There was an interesting suggestion in #16 that no one followed up on:

3) Modules should be able to block their own disabling and uninstallation: hook_can_disable(), hook_can_uninstall(). These hooks would live in the install file, and be called while creating the disable/uninstall module forms, not during the act. These hooks would return messages explaining to the user what needs to happen before the module can be disabled or uninstalled (or TRUE, because it can be disabled/uninstalled). A 'why can't I uninstall this?' link would be added to the form, similar to what Coder does with the 'code review' link, and following this link would show the explanation.

This is something that would be extremely useful. It doesn't solve the whole problem but at least it provides a way for a module to communicate that it shouldn't be disabled. And that takes care of another consideration -- some modules CAN safely be disabled. So modules that should not be disabled invoke hook_can_disable() to refuse to allow that to happen, other modules do not and users can still disable them.

Also I like the creativity have having a module still available while disabled but just hidden from the user in some way, but I can think of hundreds of ways the code would have to be tweaked to make sure it behaves correctly both in the enabled and disabled state, and I have no confidence I would even know how to ensure it works correctly both ways, even with a good faith effort to do so. If we think things are broken now, I can't even imagine how much more broken it would be when module maintainers try to write code that should work both ways, but doesn't.

> Preventing deletion of stuff that include disabled field types is just not trackable - includes preventing node deletion, node type deletion...

It seems that the main problem is that the arrival of FieldAPI has changed the way dependent and required modules interact with one another: it's turned it upside down in a way.

In D6 days, module B would depend on module A, and use hook_form_alter to change its form. Module A is completely ignorant of what module B is doing, and if B goes away A can keep on working as normal. There is even then a slight problem of data not being handled (eg disable taxonomy module, then delete a node with tags) but it's just database cruft and nothing you'd notice.

D7 fields turns this on its head by making module A go and ask for its dependents with field_attach_form().

Given we've already made that change, I don't see why we can't also require modules that use FieldAPI to first ask field_attach_is_my_form_ok() and block operations such as deletion if it gets back a FALSE.

If we only want disabled/hibernated for debugging purposes only, I don't see what's wrong with #10, if the 'essential hook' is the one that's hosing your site then you want disabling the module to switch everything off - the main thing is having it as a completely separate state to installed/uninstalled which bojanz's post nicely summarized.

I don't understand why core does anything with disabled modules at all? To me, "disabled" means "completely ignore this bit of code but don't remove the data because I might still need it". If you disable a module that holds data and has interactions with other modules and continue to run the site that way for a while and the data gets out of synch, that seems more like user error than anything. I can see providing a warning on disable that you may have problems when you re-enable but, beyond that, why should core care? We can't keep users from doing stupid things in every case. If we try, they just get more creatively stupid. :)

So my proposal is:

• Active - Module is turned on and running normally.
• Disabled - Module is completely ignored by Drupal as though it didn't exist. If you continue running in this state to the point that your data is hosed, it's your own dang fault. This state should be used primarily for debugging or turning off modules that aren't always needed and are safe to have disabled for long periods of time.
• Uninstalled - Drupal removes all data belonging to the module and then ignores it.

This doesn't address the "disable on major upgrade" bit but I think the Migrate option is a better route for that, anyway.

Michelle

So to sum it up, it would be "put all of the module's data into a hibernation in a cave that nobody else goes into".

There's no reason we can't call this 'disabled' in the UI, as suggested in #57.

> and likely could use much, if not all, of the same code

Yup, but this is something that's broken on D7 too. Or is it too late to do anything to help D7 at all?

> Core shouldn't need to worry about that (except for core modules).

Be nice to provide an API though. Something akin to cache_set/cache_get buckets but without any cron clean-up obviously.

I read over in the redesign modules page that there was "building consensus" for removing the disabled state of modules. I would like to state categorically that this is a terrible, awful, no good, very bad idea that I will fight with my very last breath. For an end user's sake, there *has* to be a state called "disabled." What actually happens when that state is achieved is up to core developers, of course, but you cannot possibly explain to an end user "enabled, uninstalled, or uninstalled, with caveats."

@webchick
The point of that comment and remark was to get UX people involved while there's still no final plan or even a first patch, because UX is a big factor in how this is implemented.
Still, I fail to see how installed / uninstalled are such an unnatural concept. The fact that there's a middle step for uninstalling is never something I found clear.

We've just had a huge IRC discussion (catch, Bojhan, Michelle, merlinofchaos)
Bojhan has the opinion that the flow should be disabled -> uninstalled, even if the "disabled' step is not needed or might not mean anything.
It is still up for discussion whether that should be one step (disable & uninstall) or two. It's a matter of how the modules page is (re)designed.

However, we still agree that only enabled modules can be uninstalled. So catch had the idea of silently re-enabling the module just prior to uninstall.
The icky part here is hook_enable / hook_disable (and hook_modules_enabled / hook_modules_disabled). Those hooks will fire like crazy.
catch and I agreed that it might not be a bad idea to just kill them. They are only misused in contrib anyway.

So, plan of acton could be:
1) Make disabling non-destructive, the idea I mentioned previously
2) Remove hook_enable / hook_disable (and hook_modules_enabled / hook_modules_disabled)
3) Kill the active / storage_active Field statuses. Since hook_field_info() runs for disabled modules, the field type always exists. Same for storage
4) Make uninstall enable the module before continuing.
I would also like batch api / queue api powered field deletion when the field type module is being uninstalled.

What I dream of is being able to go to the Modules page, check 10 checkboxes, and click uninstall. I get a progress bar, the deed gets done, I rest.
No more reloading the modules page 20 times, running cron, seeing what depends on what.
Bojhan can modify that plan to satisfy the UX gods, but the point still stands.

There would be side effects to that plan: disabling the PHP module would still keep the filter it provides, making it kinda useless.

[EDIT: Added the plan of action]

We need all disabled modules to be active to be able to properly uninstall. We cannot fake "disabled", because this would lead even more WTFs (why does it still break my site??). ouch.

Still, silently re-enabling them for uninstall seems to be the only way out.

> It is that hook_field_delete() must be reachable when the field data is purged - which can take an arbitrary amount of time.

We have a queue system in core already. Why not use that?

Situation: module A is deleting entities, which affect a field marked as inactive and belonging to disabled module B.
Stick an operation in the queue that says 'Hey module B, when you wake up out of hibernation (if ever), you need to perform this task'.

We cannot fake "disabled", because this would lead even more WTFs (why does it still break my site??). ouch.

Well, it's either remove the disabled state (something which webchick said she is explicitly against) or soften the problem by making the state less "disabled" :) It's a compromise I'm willing to make.

The issue is not whether hook_field_info() will run for disabled modules. It is that hook_field_delete() must be reachable when the field data is purged - which can take an arbitrary amount of time.

True. As I said in #66:

I would also like batch api / queue api powered field deletion when the field type module is being uninstalled.

This would solve it nicely.

Well, we already said that we want to make uninstall work on enabled modules. That's the basic point of this issue.
So purging happens at the beginning of uninstall, the hook is still present.

Just came across another fun bug that reminded me of this issue: #1451072: Deleting a comment author while the Comment module is disabled leads to an EntityMalformedException error after it's reenabled

Okay, time to get this moving again.

Talked this over with merlinofchaos (and later chx as well) at DrupalCon, and we narrowed down the fix a bit, concentrating on the important point.
This is a strictly code change, with no UI changes.

The crux of the matter is what David said in #42, quoting:

In Drupal right now a "disabled module" means two totally different things:

The module's functionality disappears from the user interface.
The module's functionality disappears from the API (the code isn't loaded, its hook implementations aren't invoked, etc).
The only problems I'm aware of are with #2, not #1. So, strawman proposal: Is it possible to get rid of #2 only? In other words, when a module is "disabled", maybe its code should still be there running in the background and managing whatever data it still needs to manage. But it would be responsible for staying out of the UI.

The key concept here is Data integrity. Right now, if you disable a module, all hell breaks loose because data integrity isn't maintained, field types and entity types disappear, etc.

The proposed fix is this:
1) All installed modules get loaded / included at bootstrap, not just enabled ones.
2) Modules declare hooks that are essential to maintaining data integrity, by using hook_hook_info(). These hooks are hook_field_info(), hook_entity_info(), hook_entity_load(), etc. Basically, anything relating to CRUD and providing "building blocks".
3) When invoking a hook (module_hook() / module_implements()), hooks are invoked in enabled modules. Also if the hook is declared as "essential", it is invoked in disabled modules as well.
So, when a module is disabled, its hook_form_alter, hook_menu, hook_views_data and other "UI level" hooks don't fire, it disappears from the UI.
However, if it implements some of the essential hooks, then those hooks still run.

I have a half-broken patch prepared (as always, the installer is the one creating a problem. Sad, sad code).
Gonna hack on it some more tonight, then post it.
The issue we need to tackle first is: #1503224: Cleanup module_list(). Those cleanups are necessary if we want to do this correctly.
A followup issue is #1503314: Remove the concept of active / inactive (field types, storage) from Field API (since it would no longer be necessary to maintain the active status, all fields and storage engines would be active).

Removing the usability tag since there are no UX changes here (although I'd love to see us separate enabled / disabled and installed / uninstalled as concepts in the UI, eventually).

The last submitted patch, 1199946-fix-disabled-modules.patch, failed testing.

The proposed fix is this:
1) All installed modules get loaded / included at bootstrap, not just enabled ones.
...

As it is now, when I have an installed (as in placed & extracted in the file structure - not necessarily enabled) module that is known to cause issues, I simply leave it disabled in the server. Even if I can't get to the modules page to disable it, I've learned to do it straight from the db and the system table (to get around WSODs for example). I don't have to worry as to which part of the module was broken - be it the UI or API code it now simply doesn't load at all. The reason I leave it disabled is because I want to be notified of any future version updates and try to see if the problem I was having is still there simply by upgrading and (re)enabling the module.

What does this proposed change here mean for user like me that are in this habit of keeping their problematic modules disabled, but still under /sites/all/modules? Do I have to completely remove them (as in also delete them from the file system) in order to be sure that it's not them causing any other issues?

There's also the category of modules that serve for a single purpose (migration, import, troubleshooting etc) and that it is recommended to disable them when not needed. Until now, we used to simply disable them but still keep them around just in case we need them again. Will we now have to also make sure we deleting the actual files from the server too?

@yched
Yes, I'm aware of that discussion. Doesn't affect this issue much. I'm personally for using annotations. Extending that to hooks would allow explicit registration and metadata above the hook itself, which would be awesome.

@klonos, joachim
The major implication is that the module file is always included, and present in the memory of each request. So you can no longer gain a performance boost by just disabling a module. Generally, it would behave the same as before, most hooks don't run, so most problems would disappear by disabling the module. There's always a slight chance that the bug is actually in one of the essential hooks (entity_info, or whatever), so there is a possibility that disabling wouldn't solve it, won't deny it. Still, it's really small.

That said, I've been looking into solving that as well.
Here's an alternative patch. It introduces a "hibernation" state ({system}.status == 2). When a module is being disabled, we check if it implements one of the essential hooks, and if it does, we put it into hibernation, which works as I described above (module file included, only essential hooks run). If it doesn't implement any essential hooks, it gets completely disabled and isn't included, same as before.
Compared to my previous patch, this one actually works in my testing.

So, I now need reviews (about everything from docs to key naming, approach taken, etc).
1) Which approach should I continue? Hibernation seems like a less invasive change. Wondering about the terminology, and whether it is good enough.
2) If I continue with hibernation, there's a matter of:

I also need help on getting #1503224: Cleanup module_list() to pass tests.

Oops, crosspost.

Interesting, need to think about that some-modules-can-be-disabled-and-some-can-only-be-hibernated approach!

...sorry for being the reason to bury this for so long. So many x-posts :/

#773828: Upgrade of disabled modules fails seems like a sub-issue or follow-up to this, so I've demoted it.

Now that #1503224: Cleanup module_list() was fixed and in, I think the next thing... is for someone to layout some detailed next steps to provide some direction.

postponing this while we give that a go.

Answering webchick from the other issue:

Look at it this way; we wouldn't be finding all of these issues with disabled modules if normal people didn't have a desire to disable modules, and do it often, whatever their reasons.

There's two reasons why modules can end up disabled and cause problems, which have nothing to do with how much people love the feature or not:

1. Upgrade instructions explicitly tell people to disable modules, they don't have a choice or they're "doing it wrong", see previous comment for the kinds of fun that causes.

2. The uninstall tab is relatively obscure and hard to find (and not even an option for modules that don't define hook_uninstall() which I bet many field/plugin-defining modules don't since they're not maintaining their own schema), so plenty of sites end up with a bunch of 'disabled' modules that have long since been removed from the code base.

If you want disabled modules, then you expressively opt out of staging. Which means both content and configuration.

The two facilities are fundamentally incompatible. In pretty much the same way they're incompatible with updates.

Truth is, by disabling a module, you're enabling plethora of code consisting of dirty hacks that are currently scattered across the entire system, which normally does not run. The majority of that code involves brutal stop-gap fixes, because the system cannot reasonably know how to resolve conflicts when there's data for functionality that does not exist.

In an as abstract and modular system as Drupal is today, disabling a module factually means to uninstall it step by step under the hood, since all data that isn't exclusively owned by the module needs to go through APIs of other modules, and those modules have to make hard decisions in order to keep the system running.

Unless you record and replay every single change that happens to your site, it is impossible to replay the exact history that would be required to maintain data integrity of disabled modules. The more data changes, the more unrecoverably broken is the data of disabled modules. That's why disabled modules represent data loss. If you don't lose it immediately, then you lose it over time.

The problem with all of this is that we're putting this logically and architecturally broken facility in front of innocent regular users. Worse, we even try to "support" it — even though there's factually nothing that can be supported.

As mentioned in #1883658-8: Remove the concept of disabled modules, there's nothing wrong with Devel (or even a devel-alike module in core) allowing you to remove a module from the system without uninstalling it. A matter of minutes to implement. But it needs to be crystal clear that you're effectively hacking the system and that there's absolutely no guarantee that the configuration and data of the removed module will remain to exist or be functional.

The problem is that essentially this hack is the built-in, default user interface for modules in core today and worse, we're even forcing users to use the facility, and worst, we make it look like as if it was a safe and sane thing to do.

The problem is that even the transitional disable » uninstall state in itself breaks APIs across the board, and consequently, data integrity in other, enabled modules.

Disabled modules worked well in a time when every module was an atomic, isolated isle, mostly doing its own thing, with its own data, and its own functionality. Today, the world of Drupal modules is too abstract, too modular, and too integrated, in order for that concept to work.

It's five minutes to midnight to get rid of it.

Is that even the case though? Last time I looked at WP (admittedly some time ago), various widgets required hard-coding function calls into the template. You can't disable that without hacking the code out of your template again.

Also like sun says (and apparently me in July 2011 in this very issue) we can still provide the facility for this, just hidden away in devel with a warning instead of baked into the entire system.

> Unless you record and replay every single change that happens to your site

I still like the sound of this. We already record actions for future playback with the core job queue. This would just need to be able to handle invoking a given module and hook.

@plach I think your choices would be: ask the person to make a backup, and then A) uninstall the contrib modules or B) ask them to install devel and use it to disable modules. I'm guessing we would put up a good doc page on how and why to do that.

Ok, this would work for me.

This have been a pain for so long and I hoped we could fix this in D8. I see no other way of fixing this then ripping the functionality out of core. Let's get out of this mess.

- Turning of the module will remove settings and data and clean up any run states.
- Uninstall remove the modules file from local system. This might fail if webserver is missing access.

And the answer is no. Let there be some Einsteins to think different, think big, and beyond imagination. :) As long as we meanwhile unblock progress for others and keep the system's architecture clean.

At the risk of duplicate content, I'm syndicating this once more for architectural review. Apparently, some people missed that the other issue was marked as duplicate.

d.o--

Here's another one #1887904: update_retrieve_dependencies() only considers enabled modules, related to an old favourite #194310: Check / run updates of disabled modules.

@hass, no-one's talking about removing the ability to uninstall modules, only the ability to leave them disabled without either unintalling or re-enabling (in fact we're not even talking about removing that necessarily, just making it much less prominent, slapping a warning on it that it's for temporary troubleshooting only, and not continuing to have runtime code attempt to support modules being in that state).

Oh sorry. I missed that we are waiting for feedback from @Dries.

I just now skimmed this entire thread, and what stands out to me is that the only identified use case for disabling a module while retaining its data and configuration (so that when the module is re-enabled, you don't need to redo all that data entry) is for temporary troubleshooting. And that for anything other than temporary troubleshooting, fully uninstalling the module is what the site administrator actually desires (or should desire), but doesn't always do, because it's an extra bunch of clicks with the current UI.

If we believe this to be true, then I think the issue summary's option A is clearly the best choice.

But I'm concerned that real site administrators are under-represented in this issue thread, and that we haven't considered real world use cases for when hibernating (#46) a module is strongly wanted. Without knowing what and how common those use cases are, it's hard (for me) to evaluate whether option B is better. Perhaps Dries magically has a feel for this, but in case not, how can we gather this information?

Another data point: In some exciting client work this week, we had a site-killing "function not found" error that we were able to cure by disabling and re-enabling one of our custom modules. There may have been another way to do it, but disable/enable is one way out of an ugly circular dependency situation.

Only allowing disabling of modules in maintenance mode sounds like an interesting possibility, since that's already the "stand back, I'm breaking things!" mode.

There are a lot of use cases for a site administrator to disable a module (and not just temporarily). Also, most modules actually can be safely disabled and turned on again at an arbitrary later time. The bug being discussed in this issue is not a widespread problem that many modules face; it's only a serious bug because when it does happen, the consequences can be catastrophic.

Given that, removing the functionality altogether seems like an unfortunate solution, even as an "intermediary" step.

If we don't want to fix this directly (and I don't really understand the specific criticisms of option B that a couple people mentioned above, but I do think option B is complex and possibly not worth the effort) then it seems we should look at how to work around it. Making the UI for uninstalling modules more prominent and the UI for disabling modules less prominent definitely sounds like a good idea to me, but simply slapping a warning on all modules that you shouldn't disable them except temporarily is crying wolf (and likely a warning that people will ignore exactly when they shouldn't).

Earlier I think someone suggested just making it a flag in the .info file or whatever, to allow a module to declare that it is not safe to disable. This does put some burden on module developer, but not really a whole lot, and it can be addressed with documentation. I don't think most modules would need this flag anyway.

So what I would think might work is:

1. When you uncheck a checkbox on the modules page and submit it, you get a confirmation form.
2. The default behavior would be to uninstall the module (hence the need for the confirmation; we have that now). However, there would be an option on the form to disable the module instead.
3. If the module is flagged as not possible to disable, core would prevent you from selecting that option. But it would be implemented in such a way that a module like Devel could alter the form and expose it again with a warning about only doing it temporarily.

Hopefully this is an achievable (if not perfect) solution, with some usability wins in that it makes it easier for administrators to uninstall a module rather than simply disable it (which in most cases is probably what they wanted anyway).

2. The uninstall tab is relatively obscure and hard to find (and not even an option for modules that don't define hook_uninstall() which I bet many field/plugin-defining modules don't since they're not maintaining their own schema), so plenty of sites end up with a bunch of 'disabled' modules that have long since been removed from the code base.

Actually as of Drupal 7, that's no longer true anymore; as of #151452: Uninstalling modules does not follow dependencies and can lead to WSOD any module can be uninstalled via the user interface. But it is definitely hard to find the tab and a pain to do, so most people in my experience don't bother doing it.

I already started writing a module that will export entities to serialized files, then re-import them into a fresh site. I'll be using this for a demo of replicating an entire drupal site, content and all, into a freshly installed Drupal instance. So yeah, there's a lot of potential there honestly.

In previous versions the actual executed view on the livepage didn't failed but just made these specific things hidden but sure you should really take care about that. Let's assume you have some access checking, so the user could see content which never was supposed to be seen.

Rules in 7.x has the same problem to solve. What I did there was maintaining a list of modules the configuration depends on and one of the module gets disabled, a) the "plugin" gets skipped when dealing with rule and b) the rule is marked as broken in the interface + skipped from evaluations + a warning message is shown. When the module is re-enabled, the rule is re-enabled and the admin notified with a message.

Imo, being more conservative with checks here is a good thing. In fact, I even ran into the situation on a client site where views cache got broken and so a view was executed without an (possibly important) filter! We should better fail pro-actively.

Still, I'm not sure how this relates to the "disabled modules" feature and so to this issue. For this problem it does not matter whether the module is just disabled or uninstalled?

sun: I don't think that removing the "disabled but not purged" state will do anything to make it easier to "purge" data. If you remove a views argument plugin module, you still need to either

1) Magically edit every view to remove the reference to that plugin, possibly causing it to break in exciting and possibly data-exposure-security-issue-causing ways.
2) Gracefully handle in Views the possibility of "OMG where did that plugin go?"

And read "Field", "Rule", "text format", or various other systems above as needed. Just saying "We don't support disable but not purge" doesn't make "purge" any easier.

Thats a pretty major improvement. I had not thought of the benefits that uninstall will see. Lets proceed.

I think #123 is fairly uncontroversial, and I would perhaps add to it:

4. Do not allow modules to be uninstalled or update.php to be run while any modules are disabled (#21).

5. Further discuss whether to allow some modules to flag themselves as "safe to disable" (#124), and what such a flag should allow.

@David: what do you think? With these 5 steps, do we still leave open the possibility to have your concerns addressed?

Doesn't need to be on Dries' plate currently.

@David: for which of these kinds of data/modules do you consider disabling to be catastrophic vs. not?

No hard and fast rule, just any module which depends on responding to another module's events and can't (or isn't willing to) deal with the possibility that it failed to respond to some, cannot be safely disabled. Basically, you just have to look at your code and say "what would happen if these hooks don't get invoked for a few months"? Comment module, for example, probably shouldn't ever be disabled (at least currently) not because it defines an entity type, but rather because the entity type it defines is heavily tied to nodes and the code isn't really written to deal with the possibility that the comment and node records are out of sync.

Core modules tend to be complicated and to depend on each other a lot and so I would expect them to be more likely than average to have these problems.

For modules like Field, Views, etc. (which store data provided by other modules and don't want those other modules to ever be disabled either), this could be achieved with documentation, or perhaps hook_system_info_alter() to edit the flag and prevent all of them from being disabled at once.

@David: what do you think? With these 5 steps, do we still leave open the possibility to have your concerns addressed?

Somewhat, though I don't understand the idea of having two separate UIs... this would involve adding yet another independent page to the admin interface which also lists modules similar to how admin/modules already does? That's why I suggested just doing it as a checkbox on the confirmation form (seemed a lot simpler).

I know little about Drupal 8 and just skimmed through this topic, but maybe some of my suggestions will be of use (hopefully I'm not just repeating what has already been brought up).

It seems like there are 2 main concerns here:
1) Disabled modules are broken beyond repair.
2) Disabling modules is a useful feature and should not be completely removed especially since no. 1 does not apply to every module.

This leads me to think that every module should deal with the problem themselves while core provides the necessary means to do so. The way I see it handled roughly is that disabling and uninstalling are split apart: you can do either separately from the other. Every module that can handle being disabled (either no chances of any issues arising or they can be fixed when the module gets re-enabled via hook_enable for example) can be disabled. Modules that would break one way or another could tell Drupal that they cannot be disabled at all (only uninstalled). Maybe there could also be a possibility for module X to tell that modules Y and Z must be disabled or uninstalled before this module can be disabled.

Modules could also block certain tasks from being performed when disabled if necessary (forcing users to either uninstall or enable them before proceeding). Since code of disabled modules shouldn't be run there could be a possibility to mark this in the .info file. Another approach could be to to introduce additional hooks and/or a "modulename.disabled" file for code that will be executed in disabled state. This file should be exclusive for the disabled state when no other module files are included so that a module can perform the minimum tasks that are needed for it to not break. Being exclusive it might be possible to duplicate necessary hook implementations there to just handle disabled state.

Might be too early or the wrong place for this, but in case it's not and the suggestion or something similar goes through it might be nice to have the module page reorganized as well:
*) 3 separate tabs: first for enabled, second for disabled and third for not installed modules.
*) every tab has only the relevant buttons (disable/uninstall, enable/uninstall, enable) with empty checkboxes by default that allow the user to select the modules the action should be performed on.
*) confirmation page for the action would show the necessary messages (for example "module X will not be disabled, because [some message the module itself provides]" or "disabling module Z requires modules Y and Z to be disabled as well - do you wish to continue").