Background

Problem

  • Disabled modules cause data to be lost or get stale/unmaintained.
  • Data of disabled modules cannot be staged.
  • References from or to data in disabled modules are broken.

Goal

  • Remove the concept of disabled modules. Replace its notion with an access layer that affects the UI only.

Proposed solution

  1. All installed modules are always enabled.

  2. "Disabling" a module means to disable its user interface aspects only.

    This means:

    1. All code of disabled modules remains to be loaded.
    2. Services of disabled modules remain to be functional.
    3. Routes, plugins, info hooks, etc. remain to be available.
    4. Access to all data items that support any notion of access is denied for all users.
  3. hook_enable(), hook_disable(), hook_modules_enabled(), hook_modules_disabled() are removed, without replacement.

Related issues

Comments

bojanz’s picture

Yes, a million yes.
I tried to fight for it in #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed, tried to meet others halfway, nothing worked (perhaps it was the wrong moment).
Hoping for more luck this time.

webchick’s picture

This approach doesn't make sense to me.

Right now, if I am getting some random error on my website, I can temporarily disable a module to see if removing its code fixes the issue, without destroying all of my data associated with that module. That's actually one of the foremost reasons for having the disable feature in the first place.

In this proposal, I would not be able to do this. It would look like I had disabled the module's functionality, but the problematic code could still be loaded and I could still be getting the error. Insert hours upon hours of hair-pulling and screaming.

Xano’s picture

Just a brain fart (do with it whatever you want): add an info file flag that states whether the module can be disabled or not. If there is the risk of data corruption when disabling a module, its maintainer can set the flag to TRUE to prevent it from happening. It's not perfect, but at least it prevents corruption while not limiting possibilities too much.

xjm’s picture

Wasn't this issue already discussed for a very long time in #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed, with the conclusion being that it wasn't feasible and the result that the issue was re-scoped?

xjm’s picture

#4 said, two several things:

  • The idea of removing the disabled module state is very attractive to me. However:
  • I personally have in the past used the troubleshooting technique @webchick describes in #2, back in the day. Therefore:
  • We'd need to describe an alternative troubleshooting method for people, e.g., make a copy of your site on a test environment, and uninstall modules until the thing starts working again. Pro: fewer chances for corrupt data. Con: way more work, and less doable in an emergency. Also:
  • I don't think there should be a concept of disabling whole modules' UIs, at least not from the modules page, for the reasons @webchick describes. Individual modules might have features to disable parts of themselves.
xjm’s picture

greg.1.anderson’s picture

While I believe that at the end of the day I agree with #2 and #4, I would like to draw a line in the sand and say that at a minimum, you must not remove the enabled state of a module, even if you remove the disabled state. There should still be at a minimum, enabled and uninstalled.

In short:

$ drush dl module # module is now 'uninstalled'
$ drush en module # module is now 'enabled' / 'installed'
$ drush pm-uninstall module # module is now once again 'uninstalled'

I think this is perhaps what you meant, but in #0 you said that hook_enable() goes away, when in fact it should not. Even if you do away with the "disabled" state, you cannot do away with the "enable" step. Many projects bundle multiple modules into a single package, and not all of those modules need to be enabled just because you want to use one of them. Thus, if there is an "enable" step, then hook_enable() should stay.

sun’s picture

@webchick / @xjm:
I don't consider that to be a regular use-case. You're a developer, and the use-case you described is that you have a module whose functionality is broken. In that case, you want to remove the module from the system without having to care for it for now. You don't care about its data integrity and all the other issues.

As a developer, you will do that by executing:

$ sed --in-place "d/  broken_module:.+/;" sites/default/config/active/system.module.yml
$ drush cc all

The regular use-case of end-users for disabling a module is to disable its visible impact/effects on a site. Users don't actually care what happens under the hood. As long as they do not see the previously visible stuff anymore.

At the same time, users expect to be able to re-enable a module and continue to have a functional system, even if a module was disabled for a longer time.

The current concept of disabled modules fails to deliver, on all fronts. We have an epic track record of insane critical bugs caused by disabled modules for several years, impacting all aspects of the application. We're running into de-facto unresolvable problems with the new architectural facilities of plugins as well as configuration staging in Drupal 8 caused by disabled modules (see in particular the two background issues linked in the summary).

It is obvious, we have to radically change the concept of disabled modules, in order to make any sense of it. The only alternative from my perspective would be to drop the facility altogether — which is a perfectly viable answer, too, but (slightly) different from the concrete proposal here.

greg.1.anderson’s picture

#8: Even as a developer, and even as a developer who likes sed, I don't think that sed + drush cc is the workflow I'd like to use when chasing down problems. Maybe what we should be discussing here is hiding the concept of disabled modules from the Drupal admin GUI, and leave the concept of disabled modules in Drupal, and the drush dis command intact.

Maybe we still get insane critical bugs if we let developers 'drush dis module, but the same may also be true if we force them to use 'sed' to experiment on their site.

webchick’s picture

No, I'm using Drupal as an end user in this context. This is troubleshooting step #2. Troubleshooting step #1 is clearing the cache. Troubleshooting step #3 is echo 'banana'; ;) Then I'm in a developer context. Also, you also can't assume everyone out there (developer or not) knows how to use sed and even knows what Drush is. Please be serious. :)

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.

I don't know how to deal with absolute statements like "The current concept of disabled modules fails to deliver, on all fronts." No, they don't, or people wouldn't be doing it all over the forums, and recommending it to each other as a way to solve their problems.

I'm not sure why this issue was spun off, because #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed already covered all of these arguments, including the proposal to just disable the UI when disabling a module, but the difference is that unlike this issue, the other issue has a nice list of real, actual problems that have sprouted up from this functionality.

xmacinfo’s picture

We still need a way to disable a module from the UI. End users often try a module and then another before staying with one of them.

For example, trying out 4 carousel modules would create a lot of problem if all 4 are left enabled.

Also, drush does not ship with core. And most users don’t have access to it or would not install it.

David_Rothstein’s picture

Status: Active » Closed (duplicate)

As a couple other people mentioned above, this exact proposal was already discussed in #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed, iterated upon a bit, and the latest patch posted there (http://drupal.org/node/1199946#comment-5789394) even begins to implement a rough version of it (though again, with some changes based on the ensuing discussion)....

So, closing as a duplicate.

sun’s picture

@David_Rothstein:
Well, not exactly.

For one, killing the concept of disabled modules entirely is just one of many possible options over there, and the issue is generally stuck in the mindset of retaining the existing concept, but oh, not entirely, just with some more meta data slapped onto the system here and there, making the overall system and problem space even more complex than it already is, which in turn will not improve the situation at all. Additionally, the resolution proposal is centered around the system architecture of D7 and below... who really cares for hooks in a world of services, classes, and plugins in D8 and beyond?

Second, the concrete proposal here is to 1) completely remove the current notion, and 2) introduce a new global access system for access-aware services and data items afterwards, because if anything, that's what "disabled" should mean from a user perspective. It's somewhat comparable to the "hidden" status mentioned over there, but wasn't defined as crystal clear access layer as here.

Third, the carefully crafted title and summary of this issue makes the intentions as well as the full consequences of the concrete proposal very clear. Removing the entire current concept is not one of many may-be options, it is the core of the proposed solution.

I'm happy to merge the two issues, but we have to unblock the current situation of fear and uncertainty with a bold and concrete solution proposal that manages expectations and allows everyone to think about and address its direct consequences. That was the sole intention here. The problem space of disabled modules piles up in more and more major core issues, which allows me to unilaterally state that we have a critical problem in the base system architecture that has to be eliminated, or it's guaranteed that various subsystems and features will not be able to support a rather fundamental concept of the base system otherwise.

sun’s picture

Status: Closed (duplicate) » Active

Un-duping until there's some more clarity regarding #14. Happy to dupe again, but let's be clear.

tstoeckler’s picture

Regarding the "I don't want to load this code"-use-case: If the use-case is actually that simple (i.e. simply not loading foo.module's code for the time being, or in other words @sun's code example in #8, is actually exactly what you want, except you don't want to open up a command prompt for whichever reason (that part I totally get!!!)) it seems it would be simple for devel.module to provide that facility. Either directly on the Modules page or somewhere else, I could check/uncheck a box and submit a form and devel.module removes the specified module(s) from the system.modules config (of course after having warned me that I'm doing something at least slightly evil). While having a module force-disabled it would not parcipitate in hooks, etc. so the whole "maintaining data integrity" goes by the wayside, but that seems lies in the nature of this use-case (the whole reason the current state is such a mess, that maintaining data integrity is impossible if you don't load the responsible code). If you then go and rename a content type or whatever, without re-(at-least-somewhat)-enabling the module, well, tough luck.

YesCT’s picture

#1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed postponed while we consider this and brainstorm here. when the dust has settled, we can make it active again.

andypost’s picture

I'd like to point a another problem with disabled modules - users mostly forget to uninstall modules to remove related data.
There's a some issues exposing a problems with performance when modules just deleted without uninstall

David_Rothstein’s picture

I'm happy to merge the two issues, but we have to unblock the current situation of fear and uncertainty with a bold and concrete solution proposal that manages expectations and allows everyone to think about and address its direct consequences.

Hm, my suggestion would be to update or rewrite the issue summary of the other issue, then. There are a few solutions on the table, but a list of the pros and cons and a recommendation might help focus it.

I get what you're going for with a separate issue, but so far it seems like the points which people have brought up here are mostly duplicating points (and the overall direction of the discussion) that already happened over there...

bojanz’s picture

Right now, if I am getting some random error on my website, I can temporarily disable a module to see if removing its code fixes the issue, without destroying all of my data associated with that module. That's actually one of the foremost reasons for having the disable feature in the first place.

Which in D7 doesn't actually work (as in: causes additional problems) if that module provides an entity type or a field type or...
And now in D8 we'll broaden that to "or a plugin, or config, or..."
I've spent a lot of time educating users in Commerce land to never to disable modules after seeing them shoot themselves in the foot over and over with that technique.

Jose Reyero’s picture

All this doesn't make sense to me either, mainly for the reason explained by @webchick in #2 but also because I think having disabled modules is a really useful feature by itself. For whatever reason, and I can think of a lot of them, you may want to actually disable some site feature for a period of time while still keeping the data for the future.

(And no, a module is not just its UI, modules do stuff)

If enabling / disabling causes data integrity issues, it should be the module itself handling that on hook_enable, hook_disable so maybe what you want to say is "Ensure modules keep data integrity when enabling / disabling them", which is why this is a duplicate of #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed

What I think is we've reached at this point because the dependency/plugin system is completely fucked up, without the system being able to figure out plugin dependencies or whether a module is disabled before using plugins provided by it. That's plugins + annotations + CMI's manifest, and that is what we should be fixing instead of this.

You want to be able to use a module's plugin without the module being enabled? Cool, then what you need is one more state, like 'module present' or being able to specify dependencies on plugins and not on modules.

Really, before we take this nonsense further, please make the experiment of just uninstalling all the disabled modules on your running Drupal sites and never having a disabled module again for a while, then we can talk.

And still, this is a duplicate.

fago’s picture

I've spent a lot of time educating users in Commerce land to never to disable modules after seeing them shoot themselves in the foot over and over with that technique.

Yes, let's face it: Disabling modules is broken beyond repair. I don't see it helpful for troubleshooting to offer a feature that might break your site's data integrity. That's not helpful, so let's remove it.

catch’s picture

Status: Active » Closed (duplicate)

We should mark this #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed, that issue was originally about killing disabled modules entirely (I opened it), then just got beaten down into oblivion. Forking the issue only means rehashing everything all over again as is already happening here.