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

Okay, I am not against this idea at all. I want to make that crystal clear (because, judging from my comments on the other issue one could draw the conclusion that I am totally opposed to this as a feature... I am not, I am just very anxious about the implications of it and therefore voted for removing it in it's original form). So... Therefore, please let me repeat that, even with the best concept for properly implementing this feature it still involves the risk of data loss, corrupt data/content, or even destroying your site. Especially if you don't know what you are doing. There is no way to ensure that your data/content is safe if you make use of this feature (whatever the implementation is going to look like). Removing the feature in its original form, however, gives us the freedom to not having to worry about this which unblocks various other, partly critical issues that are currently blocked, or have follow-ups, that deal with potential stale data or various other problems which we would not have without it.

Removing this responsibility from core is the main goal here. It's not about the feature, it's really just about the fact that we have something in core which we know has the potential to ruin your site - and we currently don't advertise it as such. We simply allow people to disable their modules willy-nilly. And because we do that, we can't have nice things(TM) because we have to live up to the responsibility we loaded upon us by supporting this feature in such a fashion. We have to remove it in it's current form. No doubt about that... But yes, we can bring it back (in this issue) if we can find a good solution which takes this responsibility off our/core's shoulders. 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.

Ok, enough of the rambling - Here are my thoughts about this very issue.

- 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.

Okay, that makes perfect sense. That allows us to visually expose how risky this task potentially is. It then basically comes down to a "do you really know what you are doing?" decision.

- Disallow running update.php while modules are disabled.

Right, but I think that's not even enough. We should try as hard as possible to prevent the creation of any type of content. This probably means going into maintenance mode. Maybe even enforce maintenance mode... But at the very least default to going into maintenance mode (maybe with a checkbox that can be unchecked on the confirmation form).

- 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.

If we enforce maintenance mode then this would obviously not be a valid use-case anymore. Or, to phrase it better: It would simply not work in that case. So, maybe enforcing the maintenance mode is not a good idea after all. But I quite like the idea of having a checkbox that defaults to "switch to maintenance mode" on the disabled modules page (unless we already are in maintenance mode of course).

Yes we should enforce (or at least default to) maintenance mode. I also like the idea of preventing CRUD operations in maintenance mode.

For performance, if the fantabulous tag generator feature is so expensive, then it should be possible to disable it without having to disable the module - i.e. disabling a block instance or unchecking a configuration checkbox somewhere. Same as you can stop people from posting comments without disabling comment module.

There's no feature that's non-essential to site operation that should require disabling a module to suppress.

I also like the idea of preventing CRUD operations in maintenance mode.

When in maintenance mode, there should be no user-added content anyways as the only person with that permission (administrator) should know not to do that anyways. Prevent CRUD operations entirely is not a trivial task. Also, how do you differentiate between CRUD operations that are desired (e.g. if you put the site into maintenance, install a new module, deploy some stuff, whatever) from those that you don't want (e.g. manually creating nodes). I think, once we start with something like that we are again overcomplicating this. IF we bring back this feature there should be NO implications for any code in core whatsoever if you ask me. Once we start with security measures beyond what has already been mentioned here (defaulting into maintenance mode, disallow update.php, disallow uninstall/install of other modules) we are basically back to that miserable place where we were before. All we really want to do is removing the module from the class loader and not loading it's .module file + what I already mentioned.

For performance, if the fantabulous tag generator feature is so expensive, then it should be possible to disable it without having to disable the module - i.e. disabling a block instance or unchecking a configuration checkbox somewhere. Same as you can stop people from posting comments without disabling comment module.

Agreed... I am not 100% sure about that use case either.

Actually, I would rather call this 'new' feature 'hibernate'. As, once in 'hibernate' mode we should not allow it to be uninstalled/installed either as mentioned before. It's different than the 'disabled' state we had before. The only similarity would be that we don't run the code provided by the module.

Disabling CRUD in maintenance mode would be a separate issue from this one anyway, agreed it'd complicate things.

I'm not sure about renaming. 'hibernate' suggests a lifecycle, this is more like freezing.

Yeah, that was just a wild idea... I just think it's weird to keep calling it 'disabled' when, previously, you had to first disable to uninstall and now we are basically going to have the exact opposite (when 'frozen' a module can't be uninstalled).

Disable CRUD

Maybe for content entities? At least the config system should be able to switch you back!

Disable CRUD

Maybe for content entities? At least the config system should be able to switch you back!

I am against adding any more effort to maintain data integrity than what I already described. It's simple: If you disable (freeze) a module you are required to know what you are doing. If you are clever and responsible you go into maintenance mode at which point the site can't be accessed by anyone but you. Anything beyond that is a) patronizing the administrator of that site (we have to assume he/she knows what they are doing) and b) making it way more complicated for us once more... and starting something that we previously opted out of when we agreed to remove the disabled modules functionality in its current form. This would be a step backwards.

Also, there is no difference between config/content entities. Both are equally affected by this issue of potential data integrity problems.

If we bring this back, it should be the bare minimum... No security measures or patronizing than this:

(defaulting into maintenance mode, disallow update.php, disallow uninstall/install of modules)

Forcing into maintenance mode would also entirely preclude the "error on live site but I can't look into it until tomorrow" use case, as if the site's in maintenance mode then it's offline for all of those people anyway.

Disabling CRUD in maintenance mode would mean you wouldn't be able to run migrations in maintenance mode.

Yes, disabling CRUD in maintenance mode seems rather pointless to me anyways... If you have access to the site while it's in maintenance mode that means you are an administrator and you should know what you are doing anyways... Preventing CRUD is both needlessly complicating this for us again and b) patronizes said administrator... We don't want that.

Defaulting into maintenance mode sounds like the right thing to do... If you opt out of that you have to be aware of the implications and basically confirm that you know what you are doing and that it's going to be fine. We can't, in code, guarantee that a module is 100% safe to be disabled. Even if it's just the Google Analytics module. We don't know what other modules interact with it in whatever weird way. There is always potential for some other module doing some weird stuff - And we can't predict any of that. This is something we CAN'T solve. So we are NEVER going to be in a place where we can be absolutely sure and guarantee that the site is not going to break if you disable a given module. And, if we want to have a feature like that in core, we at least have to make this 100% clear and also reduce the potential of it destroying your site as good as we can... Removing disable/enable hooks, disallowing update.php, disallowing module install/uninstall and defaulting to maintenance mode sounds like a good start.

That's going to require the same API / validation step that #2090115: Don't install a module when its default configuration has unmet dependencies and #2080823: Create API to discover config entities' soft dependencies and use this to present a confirm form on module uninstall are going to need, cross-linking.

Updated issue summary

A quick feedback from an attempt to create a Drupal 8 site for a personal blog: I installed an early version of backup and migrate. As it turns out, it is not yet adapted to the local task conversion, which gives error messages all over the place and the module is not usable. Not the fault of the module author, the drop is still moving quickly atm.

But how to disable this module now? On the modules page, the checkbox to disable it is greyed out. In the database: not possible at the moment.

This might be an edge case, but you certainly will come across broken modules in the future as well.

@eigentor try the uninstall tab.

@catch thanks, that worked. Indeed, I could uninstall it via the uninstall tab.

I don't believe that anything presented here or in the parent thread is strong enough to justify the huge amount of effort that will be required to re-implement "temporary disable" functionality and maintain it indefinitely.

I suggest we postpone this issue, and demote it from "critical" status, until it has some semblance of actionability - we have enough truly critical issues in the queue to not have this sapping Core Maintainer time. Some simple questions that I think should be able to be answered before the issue is considered "active" again:

- What is a use-case that could justify, let's say, 1000 hours be poured into this from maintainers and end-users?
- Does this issue require "frozen under site lockdown" functionality or "ghost module during business as usual" functionality to be considered RTBC?
- Evidence that the use-cases presented can't be addressed better with less drastic functional changes that directly address each use-case
- An explanation as to how a patch could theoretically be constructed to meet all the requirements laid out in this thread without introducing new problems that don't currently exist in HEAD

- 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)

I propose that to make a truly informed decision about whether "temporary disable" is going to be safe for your Drupal site and data, you need to be a senior developer with years of specialised experience and really intimate knowledge of the site you're working on.

In my experience, these people aren't in the habit of tracking down errors on prod using the "panic, disable, then attempt to track down source of error in a now-unstable site" methodology in D7 or D6, so they're unlikely to start crying out for the ability to do that in D8. As suggested in the parent thread, this is about as smart as deleting files from your file system to "debug".

If we need better debugging tools in core there are better debugging tools we can be providing developers in Core than a "panic button". Drupal core doesn't provide a whole lot of debugging tools out of the box but there's good stuff just sitting there in contrib - I'm unsure why we would want to prioritise implementing and promoting such worst-practice functionality like "temporary module disable" for debugging over something more sophisticated and better-practice like moving devel functionality into core.

- 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)

A performance intensive module written by someone that doesn't realise it's performance intensive and hasn't provide some kind of internal killswitch/throttle/disable is unlikely to be written by someone with the skill to make it somehow meet all the requirements for safety during core "temporary disable" (a much harder task than providing a killswitch that simply wraps this performance intensive functionality).

If we decide we truly need this in Core, why not provide a framework way for a module to register internal functionality that can be throttled/disabled by core rather than taking an "all or nothing" approach - hook_module_implements_throttle()? or add a check developers can use with if() statements - is_module_throttled($module)?

- "Shut up for a minute" purposes: Migrate module, for example, temporarily disables modules such as comment_notify during migrations. (#307)

This is not a good use-case for introducing module disabling (huge overkill). It is a good use-case for a global (or per-module) "shut up for a minute mode", where all output from watchdog(), drupal_set_message(), drupal_mail() and hook_requirements() that are below a certain severity threshold are suppressed temporarily. The fact that Migrate module does this highlights that Migrate module has to rely on nasty hacks to achieve something legitimate, not that this approach is legitimised because Migrate did it that one time.

Even ignoring what I just said, the issue summary needs updating to reflect subsequent discussion since the OP.

In:

"let's disable this temporarily"

... it all boils down to what is the "this".

The module level is just the wrong place, as a module can ship with a bunch of various stuff (data model providers, UI elements, controllers, etc.), and some of them just cannot be disabled.

Disabling features temporarily is just a pipe dream as long as Drupal doesn't get a clean API for reusable elements, and continues to happily mix low-level services, UI elements, data triggers, etc. into a big, undefined "module" unit. This is obviously not going to happen in Drupal 8.

> The fact that Migrate module does this highlights that Migrate module has to rely on nasty hacks to achieve something legitimate,

Just a point of information: this bit about Migrate isn't to do with nasty hacks.

If Migrate creates comments from a data source, and uses the proper API comment_save(), then modules that implement hook_comment_insert() to send emails will send emails.

If Migrate creates comments from a data source, and uses the proper API comment_save(), then modules that implement hook_comment_insert() to send emails will send emails.

yes, I understand this, see the immediately proceeding sentence:

This is not a good use-case for introducing module disabling (huge overkill). It is a good use-case for a global (or per-module) "shut up for a minute mode", where all output from watchdog(), drupal_set_message(), drupal_mail() and hook_requirements() that are below a certain severity threshold are suppressed temporarily.

I mentioned drupal_mail() specifically in this list, which would cover comment email notifications, but if this "quiet mode" functionality were to be seriously considered for implementation I'm sure other types of output would need to be discussed too. The point is that if we think "quiet mode" is a good idea, lets implement that rather than "disabled modules".

What Angie said ++.

I never said the issue summary was unclear, I said it should be updated to reflect more of the points and opinions raised in the subsequent discussion.

There are 3 concrete, legitimate use cases listed there that are not currently served by HEAD

Presenting use-cases doesn't automatically mean that *any* solution that satisfies the use-cases is justified - you need to also show that a proposed solution is *better* than all the alternative solutions for those use-cases.

There is no evidence that the 3 use-cases presented cannot be better addressed by code with less unwanted side-effects. In fact, there is evidence in #17 to the contrary as I provided example solutions to solve each of the 3 use-cases without needing to resort to traditional disabling of modules at all.

I do not claim that the use-cases are illegitimate in the sense that they are not "real problems" that Drupal users face.

I do claim that the use-cases are illegitimate in the sense that they can all be solved better by alternative solutions, and therefore cannot be used as justification for the Feature specifically requested here.

as well as a few concrete suggestions on how to move forward.

What we have in the issue summary are a few constraints that a solution would possibly need to meet. A "way forward" actually needs to explain how we could satisfy these constraints if someone were to try and write a patch for it.

- 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.

This is not actually a solution, it's just a vague idea about how the theoretical final solution could be presented in the UI.

- Disallow running update.php while modules are disabled.

There are plenty of examples in the parent issue demonstrating that update.php is not even the main data integrity problem. I don't think anyone here would consider this a complete solution, so the issue summary shouldn't present it as one - this has been discussed in #1, #3, #8, #11

- 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

Both of these directly contradict @webchick's statement in #12 - "Please note though that in order to solve the use cases in the OP, the site needs to remain live, with CRUD operations intact, while modules are disabled."

I opened #2186751: Core should provide a framework for modules to prevent performance intensive functionality when certain criteria are met so that the performance throttling use-case can be dealt with separately.

I opened #2186755: Provide a global and/or per-module "quiet mode" where messages/notifications from modules are suppressed so the "quiet mode" for modules can be dealt with separately.

Thanks @thedavidmeister.

I think it makes sense to discuss and address the different use-cases independently from each other. In fact, the entire original debate on #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed was littered with complaints from different people that had different use-cases for disabled modules, which made it very hard to evaluate whether the (non-scoped/undefined) feature has to be retained or can be removed.

Given that the actual intention for disabling a module varies so much, an attempt to re-establish a blatant catch-all facility to "disable a module" sounds indeed only prone to errors. By addressing each use-case with a dedicated feature, the validity of each feature can be cleanly evaluated on its own.

That said, I noticed that you filed those issues against D9. Given that we removed disabled modules for D8, I think we should at least attempt to address some of the use-cases for D8 already. I don't think that each of them will consume that much time as you claimed — the only aspect that will need architectural planning is the (shared) question of where and how these overrides may be configured/defined.

I feal very stressed by this issue. In past years I had so many modules that crashed my sites, including dev sites that I do not like to restore from a backup, too.

I still see no build in standard way in core that allows me to export my module data/settings and reimport it back once I reinstall it. It looks like I should stay in rain and this only suxxxxxxxxxxxxx. This disable feature should have never been removed!

I'm 100% sure that the wrong decission taken to remove the disable feature will hurt us 1000 times back post release. I do not think that we'd like to see 1000 issues just because people have destroyed sites and cannot disable the simpliest modules to recover. *argh*!

#27 - I've updated the two issues that I opened for d8.

#28 - I'm not entirely sure how to respond to such a dogmatic comment after so much careful discussion and reasoning has been applied by other people across this and the parent thread...

I feal very stressed by this issue.

I think we all are.

In past years I had so many modules that crashed my sites,

Me too, I suppose the difference between me and you is how we approach reparations on a crashed site.

including dev sites that I do not like to restore from a backup, too.

I don't understand this bit. What is the problem with a crashed dev environment? that's sort of what a dev environment is for.

I still see no build in standard way in core that allows me to export my module data/settings and reimport it back once I reinstall it

We've discussed "data" a lot in the parent thread. We've shown that there are multiple simple scenarios that make arbitrary data export, then removal of the module, then re-addition of the module and "restoring" that arbitrary data an unstable process.

For "settings", I believe the CMI is working hard to address this - http://drupal8cmi.org/

The real *blocking* problem, that has been re-iterated over and over and over again in the parent thread and here is this:

It is impossible to do what you are asking and guarantee the integrity of your site.

If YOU (@hass) disagree with this, the onus is on YOU (@hass) to provide a proof of concept patch or clear brief on a framework that solves the problem. Otherwise, YOU (@hass) are being offensively selfish by demanding something but refusing to work towards it yourself, this is NOT how open source works.

It looks like I should stay in rain and this only suxxxxxxxxxxxxx.

OR take some responsibility for your own work and implement basic precautions against this scenario. Follow a development workflow that includes dev/stage/prod environments (I linked to hosting providers that implement this for you in the parent thread). Use a version control system with a workflow like "git flow" that allows for critical hotfixes. Make a database backup before you deploy any new releases to production. Setup logs so that you can easily review any errors on your production site both during and after a crisis. Open up a text editor and see if you can patch the error you see yourself.

There's so much you can do to protect yourself against disaster scenarios that doesn't require deus ex machina style intervention from Core.

This disable feature should have never been removed!

Says you. This claim belongs in the parent thread.

I'm 100% sure that the wrong decission taken to remove the disable feature will hurt us 1000 times back post release.

Perhaps we will be hurt by this decision, but we were also being hurt in 1000s of little and big ways by not making this decision. We're being hurt either way.

The difference is that with the way things were before, there was nothing we could do to reduce the hurt. The way things are now, we can start identifying and methodically working through all the issues we have individually and work to reduce the hurt over time.

This medicine is bitter, and maybe Core will be less functional in the short term, but many Core contributors and the Core maintainers believe we'll become stronger in the long term by working through this with a positive attitude.

I do not think that we'd like to see 1000 issues just because people have destroyed sites and cannot disable the simpliest modules to recover. *argh*!

I disagree. For a start, "1000 issues" is really extreme hyperbole. There are not 1000 *fundamental* use-cases for disabling modules. This thread has managed to identify three fundamental use-cases after four months. If you know of more, please let us know.

If you mean that contrib will have 1000 issues filed to actually report and resolve the fatal errors in modules that existed anyway and would have otherwise gone unreported then, as a module maintainer myself, I see this as a fantastic step towards improving the quality of contrib code overall.

I would also like to get this back in but am still absolutely unsure how this could ever work. I did not look at the code yet but due to the similarity of the process I am pretty sure we could use some of the newly introduced Migrate concepts to accomplish the data massaging needed upon reactivation of a module.

As I explained in #19, it is not possible to do this properly at the module level, because modules mixes together low-level concepts (data storage, services) with high-level concepts (blocks, routers, rules, etc.).

In all the use cases that I see here, what you want by "disabling a module" is to disable those high-level concepts: you want to temporarily disable the (configurable) elements that are provided by this module.

This means that we are not talking about disabling "Entity Reference", but more the "Blog" module (ie. more a Features in the Drupal 7 vocabulary then a module).

Most of the commenters here so far seem very antagonistic, despite some disavowals, to the concept of allowing modules to be disabled as part of Drupal's core (or even contributed) functionality, demanding sustained arguments for each & every use case for the functionality.

I'm totally fine for this to live in contrib.

This was postponed until we have "more info" which translates to a proof of concept patch or a clear explanation as to how this could be implemented.

Regardless of whatever Dries said in the past, if nobody in the world has a concrete plan there is nothing more to do here.

Impossible, or hard?

Literally impossible, at least with the current definitions of "disabled" and "module".

What @Damien said in #19 and #32 is the long and short of it.

1. Module A has some data with a serial ID of 1
2. Module B references the data 1 of Module A
3. Module B is disabled
4. Module A is disabled and uninstalled - Module B's data is now stale
5. Module A is re-installed
5. Module A creates *new* data with serial ID of 1 - Module B's data is now stale and irreparable.
6. Module B is re-enabled and has absolutely no way of knowing/validating that the 1 its stale data references is the "wrong" 1. An isset/empty check is far from sufficient here.
7. Unfortunately, Module B's data associated with its reference to 1 is not compatible with the Module A's data associated with the ID 1 - Fatal errors are highly likely at this point.

@thedavidmeister:
You're presenting a strawman in #33:

1. Module A has some data with a serial ID of 1
2. Module B references the data 1 of Module A
3. Module B is disabled
4. Module A is disabled and uninstalled - Module B's data is now stale
5. Module A is re-installed
5. Module A creates *new* data with serial ID of 1 - Module B's data is now stale and irreparable.
6. Module B is re-enabled and has absolutely no way of knowing/validating that the 1 its stale data references is the "wrong" 1. An isset/empty check is far from sufficient here.
7. Unfortunately, Module B's data associated with its reference to 1 is not compatible with the Module A's data associated with the ID 1 - Fatal errors are highly likely at this point.

D7 does not allow you to uninstall Module A without first uninstalling Module B. It explicitly says:

To uninstall Module A, the following module must be uninstalled first: Module B

Nevertheless, I agree that data corruption can occur if the site content is changed while essential modules are disabled. This means that we've failed to add clear warnings and to educate users about the possible consequences of disabling modules on production sites.

However, removing the feature means that we lose the ability to experiment and test for possible conflicts between modules, even if we know what we're doing, while a site is off-line, or on a local copy of a site. Contrib development/maintenance as well as support is severely hampered. This is a severe regression of Core, and until a replacement is available in Contrib, it's a gaping wound.

#34 - I'm well aware of what a "strawman" is... I disagree that what is being presented is one. I'm not even meaning to present that as a complete argument here, although I can see how what I said would be interpreted that way. All I'm trying to say is that in the parent thread, we got deep into this, IMO there's no point rehashing arguments here that have already been brought up in the parent thread and discussed at length, unless we accept that these things have been discussed at length and present some new information that wasn't raised in the parent thread.

If you read through the full parent thread, you'll see that if you take that example a few conceptual steps further and throw a third module into the mix, it's pretty easy to end up with a scenario with circular dependencies that lead to either huge amounts of maintenance and extra complexity introducing a "data dependency" framework into core (with dubious advantages for developers and clear downsides), or the current solution that is safer, requires no mass education of developers to work and is easier for core maintainers to work with.

I do not see how disabling helps you test for module conflicts any better than uninstalling (in a world where no modules can be disabled in production anyway). Can you please elaborate on a scenario where this could be the case and we can either add it to the issue summary here or open a new ticket to address that use-case?

I agree with the assessment in #36. There are individual issues addressing both use-cases in the issue summary directly, please label those issues as major bugs and not this one - unless there is a clear use-case that is not addressed directly better by other issues already opened.

The reason this issue was flagged as "needs issue summary update" is because the summary contains statements that duplicate the scope of other issues and makes huge assumptions by asserting that re-introducing functionality that was intentionally removed previously is the best (or even only) way to resolve the stated use-cases.

Until there are viable replacements for the use cases in the issue summary, this is a regression.

In reality though, would we ever achieve truly viable replacements for the use cases in the issue summary if we re-introduced the "sweep it under the rug" solution? I can easily imagine those viable replacements all getting blocked on "don't see the need for this, just disable the module" type responses from people who are not aware of the history and "bigger picture" of the issue here.

Thedavidmeister please stop abusing the issue metadata, I see too much back-and-forth in the last comments. Both catch and webchick who are committers to Drupal 8 have given their feedback, that is all the "maintainer needs more info" that you will need for this status to stay in place. If you desire to change it again, you can always discuss further.

If you desire to change it again, you can always discuss further.

Apologies, that's what I thought I was doing in #37, but I don't see any reason to play status tug-of-war here.

What webchick said was:

Until there are viable replacements for the use cases in the issue summary, this is a regression.

But in both #2186751: Core should provide a framework for modules to prevent performance intensive functionality when certain criteria are met and #2186755: Provide a global and/or per-module "quiet mode" where messages/notifications from modules are suppressed there is no commentary from @webchick about why either of those issues are not considered viable alternatives to the traditional "disable module" approach for two of the three use-cases in the issue summary.

That was part of the "more information" that I was hoping for, as I thought it was a key part of this discussion, to try and make a clear distinction between disabling functionality (which @catch seems to support) and disabling modules (that @webchick definitely supports) and to get a better understanding of why one might be preferable over the other.

As I understand it, Drupal 8 is attempting to do a lot of things right, or not do them at all.

The functionlity we as developers use on a daily basis - disabling a module temporarily by setting its status to 0 in the database - is essentially hacky.

Still after bookmarking this thread I am reminded very often how important that functionality or something that has the same effect is. I use it _very_ often. Maybe I am a bad dev, but that is another issue.

Now I guess there is
a) a culture clash of people saying "I don't care if is hacky, just bring back that functionality" with the general principles that were adopted in the D8 release cycle, to not do such stuff
b) technically it appears to be a lot harder to do this in D8, or am I reading this wrong.

If I read the other two issues @davidmeister is referring to, right, they are not meeting the use case.
The use case is some module is causing trouble (WSOD or similary disastrous) and you try to be able to at least log in or see something by disabling a module temporarily.

You do so to silence it. Just suppressing error messages might not be enough because the site can be completely broken because of one bad-behaving module.

@eigentor - If I wrote a script that prepended every line in your offending module other than the opening <?php with //disabled , that would have a similar effect to opening up the db and setting the status to 0, is that really what you're asking for?

That wouldn't work, because another module could do module_exists() prior to calling some of the disabled module's functions.

I wasn't really suggesting that it would work, I was more trying to highlight that it might not be such a good idea even if it did "work"...

What actually happens internally if you set the status to 0 in the db without hitting the Drupal API?

If I read the other two issues @davidmeister is referring to, right, they are not meeting the use case.
The use case is some module is causing trouble (WSOD or similary disastrous) and you try to be able to at least log in or see something by disabling a module temporarily.

You're absolutely right, the other two issues do not address this. You're obviously welcome to open a third issue, but I did not do this myself out of laziness and general disinterest, apologies for that >.<

While I personally am super skeptical about the strength of the "debugging" use-case (to the point of single-handedly justifying including module disabling in Core rather than just moving it to Contrib like we did with https://drupal.org/project/php) over many other safer and easier debugging/recovery techniques readily available in 2014 (that don't even necessarily have anything to do with Drupal), I totally respect that people other than me want to discuss that and hash the idea out further.

*BUT* I do think that someone who wants to come up with a Core-sanctioned WSOD "oh shit button" style debugging tool should go ahead and open a dedicated issue for that, or totally rework everything being proposed here to drop the other two use-cases and just focus on doing debugging well, because it's clearly already been discussed and accepted that it's impossible to simultaneously make "the best debugging tool possible" and "the best performance tweaking tool possible" with a single internal mechanism/API.

#37, thedavidmeister:

I do not see how disabling helps you test for module conflicts any better than uninstalling (in a world where no modules can be disabled in production anyway).

It seems we live in different worlds. I maintain about a dozen contribs, and all of them can be safely disabled in production.

The obvious advantage of disabling over uninstalling is that all of the module's configuration information and data remain intact, and it can simply be re-enabled to continue working as before.

Can you please elaborate on a scenario where this could be the case and we can either add it to the issue summary here or open a new ticket to address that use-case?

Of course. Telling the user to temporarily disable my module is THE #1 SUPPORT TOOL that I have to handle support issues where users claim that my module is causing ill effects on their site. They will resist uninstalling, for good reason, and it will be just about impossible to sort out those issues in D8.

If you read through the full parent thread, you'll see that if you take that example a few conceptual steps further and throw a third module into the mix, it's pretty easy to end up with a scenario with circular dependencies

No, it's not. Just as your strawman is not working, the scenarios that you conjure up are not as common as you claimed in #33 and #37 and everywhere else.

I know and accept the fact that there are situations and certain modules where disabling causes trouble. The modules that have this problem do include some that are in wide-spread use, but their number is small compared to the total number of modules. Maybe your world is full of them, but mine is not.

Removing the disabling functionality has "solved" the problem for the challenged modules, at the expense of all the others that are now much harder to maintain and support. In hindsight, rather than following a very vocal group and throwing out precious functionality, we should have refined the disabling to allow the maintainers to flag their modules as "can be temporarily disabled" (e.g. as long as no content is added to the site) or even "can be permanently disabled", if appropriate.

Yes, the disabling was removed intentionally, but for the large majority of contribs disabling was perfectly valid and safe, and this makes it a regression. And no, implementing the disabling in contrib is not a valid solution, because it won't receive the same attention, trust, and wide-spread adoption, as if it were in core.

I can understand that in your "world where no modules can be disabled in production anyway" disabling can live in contrib, but in my world, not having disabling readily available makes my life as maintainer miserable. This hurts Drupal — not because of me, but because of thousands of people in the same situation who spend their spare time to give support in the issues queues.

Well, if this is doable in contrib, maybe that is a sulution?
As everybody who employs the "status 0" solution normally is

a) a dev who knows what he is doing
b) fully aware that he is kinda hacking drupal

This has not be sanctioned directly by core, as long as it is somehow possible.
There is not a systems table in D8, so it has to be something else.

All kinds of dependencies are sure not met, and disabling a module in the fashion we are used to might of course cause even greater disaster by getting into dependency hell.

*but*
The times I used it it appeared to be a non-desctructive and easily reversable practice, which is what you want when you do it.

But given Point a) and b) this is should not be the worry.
It may be compared to changing the password in D7 without knowing it. Until I knew it was doable with drush, I was pretty much at a loss.

If there is a way we can achieve what we want without someone having to voluntarily implement it, fine. Just show me the dirty little switch.

@salvis - yup, I agree that many many module authors have the same need when troubleshooting. However, I think it can be mostly mitigated if there was an easy way to uninstall with config backup, and then an easy way to re-enable with config restore. We many of the pieces already. We mostly need to figure out the UX improvements, and then code. I do think this could be in Contrib if Core manages to not get around to it.

Modules that have data (as opposed to config) didn't properly work when disabled in either so they can be omitted from this conversation.

Well, if this is doable in contrib, maybe that is a sulution?
As everybody who employs the "status 0" solution normally is

a) a dev who knows what he is doing
b) fully aware that he is kinda hacking drupal

If I cannot tell even the most inexperienced user (especially those!!!) to temporarily disable my module to convince themselves that they're barking up the wrong tree, then my support load will at least double, and that second 100% will feel more like another 500% because it's unpleasant, useless, and completely unnecessary.

Asking users to install a "dangerous" Disable contrib, which will have been thoroughly denounced and black-listed by the very vocal people who got us into this mess, will not be feasible.

Modules that have data (as opposed to config) didn't properly work when disabled in either so they can be omitted from this conversation.

Please forgive me for disagreeing. If we take the site off-line and avoid creating content, then just about all modules can safely be disabled and re-enabled. The same would apply, if core had a read-only state that would disable content creation.

Even without such a state, keeping the data may work just fine. I'll take two of my modules as examples:

1. Subscriptions: Can certainly be disabled and re-enabled in production. Obviously, no notifications are sent out while it's disabled, but when you re-enable it, it resumes working as you left off (if the data is still there!).

2. Forum Access: You probably don't want to disable it on a live site if you have content that needs to be protected, but if you take the site off-line or if you experiment with a local copy of the site, then disabling and re-enabling is as simple as rebuilding permissions (if its data is still there!), even if content has been created in the meantime, and that certainly beats having to re-enter finely tuned access permissions.

A "strawman argument" is to argue against a statement that is conceptually similar to but different from the original statement. I don't really see how what I've said falls into that category, not sure why this keeps being brought up? what is the original argument, and what is the similar but different argument that I have conjured up to argue against? AFAIK, everything we're discussing is about how we can guarantee data integrity and meet 3 clearly stated use-cases in the issue summary, no more, no less.

I did not claim my scenarios (or other people's scenarios) were common, in fact, I (and other people) agreed at the time (and still agree) that they are rare. I also said (and this became one of the key points in earlier discussions) that no matter how rare the situation is, Core cannot in good faith say we guarantee data integrity 100% of the time while we have outstanding known data integrity issues (which you @salvis agree exist) outlined as clear as day in a high profile, critical issue thread.

Now, my point is and has consistently been, for just about all of my participation here, that a module can implement disabling its own functionality (@see panels, views, context, rules, etc...) surgically and more safely than core can, including selectively disabling components of functionality (this could be a core UI/API, to ensure a consistent experience), while still ensuring data integrity 100% of the time. Nobody has yet stated this approach is unacceptable or an undesirable way forward.

Is it not enough for these support requests that you can ask your users to disable whatever individual component/function of the module they claim is causing grief, do we need the core sledgehammer as well?

I don't buy the argument about people denouncing a "disable" contrib module and it therefore becoming unfeasible somehow due to that, or the suggestion that code written in core is automatically better than code written in contrib. The situation and the stakes involved in core and contrib are very different - there's not really any such thing as "casual" core functionality that can work X% of the time and break seemingly randomly the other Y% of the time, but that kind of thing is somewhat common and largely OK in contrib. By the same token, there is often great new stuff in contrib that ends up being absorbed back into core in later releases.

I do take a little bit of offence to the suggestion that the outcome of the parent thread was solely due to a vocal group of people pushing against the "obviously right" answer when there were calls time and time again from everyone involved for *anyone* to provide a proof of concept patch that could help resolve the situation in a better way. The "safe to disable" flag idea was actually suggested, discussed, but ultimately not implemented for various reasons so you'll have to make it clearer why this approach is indeed better in hindsight than it was in foresight to get that adopted.

Asking users to install a "dangerous" Disable contrib, which will have been thoroughly denounced and black-listed by the very vocal people who got us into this mess, will not be feasible.

So we are back at that discussion, yes? Don't you find your words a little bit harsh and injudicious? A whole bunch of the most talented developers in this community tried to solve this very issue for *years* and, after thoroughly evaluating the different options and taking everything into consideration carefully, came to the conclusion that we cannot maintain "disabling modules" in core in the way it was previously implemented. It certainly wasn't an easy decision. Nor was it taken lightly. The most important thing for Drupal Core is security, stability and maintainability. All these things can only be reached with some sort of predictability of the components and features that it ships with. If there is a component or feature that can't live up to these expectations and people don't see a way to fix it - It has to be removed. This is what happened here.

I am not going to repeat the reasoning behind the decision again as they have been re-re-re-repeated in this issue as well as the related issues. If you think that you can come up with a solution that solves this problem satisfactorily, feel free to enlighten us as we simply have no clue how it could be done. Coming in here and claiming that "these random, vocal people who got us into the mess" screwed it up so badly without offering a solution to the problem is not going to get us anywhere. Sure, you can be disappointed that it's gone, we all are (me too, btw.) - coming in here and shouting at us is not cool though.

1. Can we get back on topic here, please? The meta/language level back and forth is not productive. Recent comments did contain a few creative ideas; that thinking should continue.

2. Re-implementing the concept in an architectural design that is appropriate and works will take a good amount of time (including necessary discussions). I asked core maintainers to discuss and come up with an official stance on this issue with regard to the D8 release. Until that decision is communicated here, the creative discussion should continue.

> Is it not enough for these support requests that you can ask your users to disable whatever individual component/function of the module they claim is causing grief, do we need the core sledgehammer as well?

In the examples given above, that would lead to the whole of foo.module's PHP code being wrapped in an if ($module_set_to_active) ...

In the examples given above, that would lead to the whole of foo.module's PHP code being wrapped in an if ($module_set_to_active) ...

In the subscription example, if each subscription could be disabled individually, that would suffice. You could simply tell the user to disable all subscriptions.

In the forum access example, I assume you would wrap the code doing the access checking logic rather than the whole module.

Can we get back on topic here, please?

Well, yeah, I can get behind that... Since we're still talking about this "read only" state for modules (which breaks 2/3 use-cases), I propose (again) that we better define what the topic is so as to make it easier to stay on it.

I propose (again) that we either change this issue to only be about disabling modules for debugging purposes and let the other, already open, issues handle the other two use cases (that are not satisfied by a state in maintenance/read only mode) OR we stop chasing our tails here until someone proposes a solution that satisfies all three use-cases.

Which puts us #27 where we should have three separate issues with no overlapping scope that can be discussed in a less frustrating way, or back to either #33 where we need more information about how to proceed.

I'll update the issue summary now to show how #27 looks. That means this issue is now ONLY about handling debug/support request mode for a module(s).

Thank you, sun!

I think the problem comes from trying to find one single solution that works for all modules. The fact that there exist modules that must not be disabled (the extreme case) has lead us to remove disabling completely (the extreme solution). From the purely technical viewpoint this can be justified, but in practice the consequences are severe and hard to accept.

Every module is different and has somewhat different needs, but the maintainers should know how their modules work, under what conditions their modules can be disabled and what the consequences are if those conditions are not met.

From the summary:

In fact, the module should be completely unaware of its state. Either its code is loaded, or it's not. This also means that there should not be any enable/disable hooks.

This is a desirable requirement, and a large class of modules can meet it. But Forum Access and just about all other node access modules cannot, because enabling/disabling them requires rebuilding the {node_access} table. That's why we have node_access_needs_rebuild(). One size does not fit all!

We've gone from "you can disable any module" (which may cause data corruption in specific cases) to "your only option is to uninstall" (which will cause complete loss of the module's configuration and data). We've completely excluded the maintainer's judgment and the user's judgment, and now we're in a very uncomfortable position. — Make a system foolproof, and only a fool will want to use it...

In my ideal world, modules would be able to tell the user what the consequences of disabling them are
-- on a production site and
-- on an isolated test site
and core would provide (optional!) tools to help meet the conditions under which modules can be safely disabled, e.g.
-- maintenance mode
-- read-only mode
-- anonymous mode

Whether any given module can provide additional tools (a dormant mode or whatever) is up to the module, but core should provide a framework that sets the standard.

It's about empowering the users instead of restricting them (and forcing them to hack the database instead).

Regarding the issue title change, I don't think that's correct because even if this issue is just about debugging isn't the whole point that it's about situations where someone needs to debug directly on their production site? If you already have a development environment and can reproduce whatever issue you're debugging there, disabling vs. uninstalling isn't that important (although still somewhat convenient to not have to wreck your development database with an uninstall).

I'm still too burned out from the original issue to comment on the rest :) But I do want to point out that there are use cases for disabling a module forever (without the intention of ever turning it back on) that I don't think have been mentioned yet. This is useful when you don't need the module but still want easy access to its data. For example, it makes sense to disable the Drupal 7 Migrate module when you're done migrating content and the site is launched. But the data in the {migrate_map_*} tables represents a direct map of legacy site content IDs to Drupal entity IDs that can be useful for many purposes (custom code may need to access it, etc). If you uninstall the module the data goes away.

In my ideal world, modules would be able to tell the user what the consequences of disabling them are
-- on a production site and
-- on an isolated test site
and core would provide (optional!) tools to help meet the conditions under which modules can be safely disabled, e.g.
-- maintenance mode
-- read-only mode
-- anonymous mode

I'm not against this idea but (I haven't checked this in D8) does Core even have a native concept of "production" and "not production" environments? In the past I've needed to install contrib/write custom code to achieve this.

I guess what I'd argue is that this "safe-ness" would be much easier to reliably ascertain ahead of time at the "component" level, rather than the module level where it could actually be quite difficult to get right. Developers would be forced to overstate the severity of disabling a module due to one small part of the overall functionality, expose their users to unnecessary risk or roll their own "disable" functionality and re-invent the wheel every time here.

I could easily see how this suggestion fits in with a framework to allow disabling components of modules. I could also see how we could have a "disable framework" with a set of predefined severity levels that allows for disabling components of modules where one of the "components" is the entire module.

This would need to be alterable so other modules using the data can flag if they've made it "less safe" in the database.

In that case, a module could say "Hey, I'm not safe to disable entirely because I run important hooks to maintain my data, but you can disable any components of what I do with that data that isn't strictly necessary to avoid corruption" and another module could say "Go ahead and disable me entirely, the only data I maintain is some boolean flags and a few strings anyway, and I don't touch them outside a single form submit handler". Both modules use the same core API, but with very different consequences.

Obviously, contrib modules currently implement their own ways to disable functionality, from a simple boolean variable_get() to more complex concepts like "plugins" and similar - I'm suggesting we standardise what already exists in contrib to cover the following:

- Environment aware
- Modules must be explicit about the effects of disabling a component on data
- Modules can expose themselves as a disable-able component, thus emulating the classic disable behaviour
- Other modules can increase the disabling severity levels of an existing module's components if they need to
- Sites would have "CRUD states" that help facilitate increasingly risky disabling behaviour for debugging purposes
- Modules can lean on core to toggle components of functionality in order to provide compromises for the end-user/developer in the case that disabling the whole module is an unacceptable risk

I'm still too burned out from the original issue to comment on the rest :) But I do want to point out that there are use cases for disabling a module forever (without the intention of ever turning it back on) that I don't think have been mentioned yet. This is useful when you don't need the module but still want easy access to its data. For example, it makes sense to disable the Drupal 7 Migrate module when you're done migrating content and the site is launched. But the data in the {migrate_map_*} tables represents a direct map of legacy site content IDs to Drupal entity IDs that can be useful for many purposes (custom code may need to access it, etc). If you uninstall the module the data goes away.

This is a good use-case. We should add this to the issue summary.

Updating the issue title to hopefully reflect #58

> does Core even have a native concept of "production" and "not production" environments

#1537198: Add a Production/Development Toggle To Core.

#61 - oooh shiny, that looks interesting. I'll cross reference this issue over there.

does Core even have a native concept of "production" and "not production" environments

I didn't mean to imply that, but rather that modules should always give the full story for both environments. Even if Core will know where it's running, it would still be helpful to know what to expect when moving to the other environment.

isn't the whole point that it's about situations where someone needs to debug directly on their production site?

Yes, but not to the point of excluding development environments, which should be easier to handle anyway.

Thank you for your constructive work on this, thedavidmeister — I'm sorry if I've annoyed you.

We are always talking about configuration here, but always miss sql data. There is a setting export feature in core, but no sql export. Aside from this we need a consistent export of all sql data and the ability to re-import both (consistent!!!) - not only configuration. I'm sure this is also impossible. Do not tell us our unexpierienced users they need to develop this on their own, please. That is a job of core, not contrib.

Otherwise the disable feature may be easier to implement.

@hass - the scope here is already pretty big. Are you suggesting something like https://drupal.org/project/backup_migrate in core?

I don't know backup_migrate and I already have only troubles with migrate module that does not work as it need to work. I'm only saying that removing "disable" function was a plain wrong no-brainer decision and the remover has only thought about configuration and missed the data of a module that is not configuration. If I need to support someone with an issue in my contrib modules I may need data + config + version of my module. If he uninstall my module the data in SQL + config is lost and cannot recovered. This makes every repro impossible.

The implementation of the configuration export (what is already in core) does not help anything and I have not tested it myself yet. I only say the configuration export lacks the SQL data and makes it therefore impossible to import the configuration data of my module. An uninstall will always cause data loss if there is anything more than configuration and this is not acceptable.

Throwing another module at the missing parts sound not like a valid solution to me compared to a Disable button like we had this in past in core. I also fully agree with salvis and had this already said in the disable removal case.

@hass, not sure what you're trying to say? that you're volunteering to write a POC patch that covers the rough brief/idea outlined in #57 and #59? That would be awesome. I can't write it because I apparently don't have a brain.

The backup/migrate module has nothing to do with the migrate module. It's rude to shut down an idea that you haven't even tried. From what you've described to us, that module does exactly what you want.

No, I want the disable modules feature back in core - nothing else. I know that my modules can be disabled without any issues, too.

@hass - do you think posting rants periodically helps this issue move faster or slower?

@thedavidmeister: Do you really think complaining about a possible inconsistency problem that will and cannot happen for sure in 98% of all modules (and could be implemented as a module.info.yml setting, like 'disable': true - default false help getting the Disable feature faster or slower back?

@hass - I absolutely believe that working towards producing a clear statement of the full scope of the problem moves the community towards a high quality solution and is not wasted time.

I asked core maintainers to discuss and come up with an official stance on this issue with regard to the D8 release. Until that decision is communicated here, the creative discussion should continue.

It's been 5 months. Is there an official stance or are we still at a stalemate? I won't bother picking a side except to say that I think this is a feature request and we should postpone it if an agreement cannot be reached.

Moving to plan - which is what this issue really is about - figure out how to offer that kind of functionality back or an equivalent, without breaking config dependencies and everything else that protects against data loss.

80 followers, 3 years with no activity and no plan, time for another comment! Do we have consensus for what should be in the plan? It's still a major functionality flaw in Drupal 8 from my limited perspective. I'm with #53 where this option should exist for informed developers who want to investigate bugs on disposable databases. Is there an MVP for this feature which is implementable without planning for every eventuality for how it may be abused by people who don't know what they are doing?

Has this really been assigned to the 'too hard' basket? I tried to following the ins and outs and realise that clearly there are many reasons this hasn't been addressed. As a non-developer who might have in the past often 'disabled' a module to try and confirm if enabling it some time back had caused other parts/functions on a site no longer working, i am still trying to confirm if there is a reasonably simple 'copy config + grab data + uninstall' solution so that re-installing the module after 'suspending' it is possible.

Would love to know as well. Debugging issues is so much easier when you're able to temporarily disable all of your modules and doing process of elimination to find out the culprit.

It would be get clarity on if this is blocked on a policy basis, or if it's only an implementation/resource issue?