Allow uninstalling modules with dependents by offering to recursively uninstall their dependents as well.

I agree that this issue needs to be addressed and that the solution is to use Javascript to enable or disable checkboxes according to whether dependant modules are enabled/disabled

This is also similar to a feature request I was going to make now so I will post it here instead as it can probably be implemented while solving this one.

When updating modules the process usually involves disabling all non-core modules. When there are several dependencies between modules this will involve several rounds of disabling modules. The last time I did this it required 4 rounds of disabling modules which took a total time of approx. 3–4 minutes to complete. This is much too long, particularly as we want to encourage people to update modules/core regularly and as soon as possible, and it is unnecessary...

I suggest making the update process much easier by placing a button at the top of the module page with the button text saying, "Disable all contributed modules". When clicked, all but the presently enabled core modules will be disabled. This addition would greatly increase the speed of the update process and usability.

--

Edit: decided to post my latter suggestion as a new issue #490274: One-click button to disable all contributed modules so it doesn't get overlooked.

@authentictech: I'm going to guess you don't do many multi-sites.

Wow. Were you intending to sound so snotty? (If not, it's not always so easy to tell in forums). You don't need to make such guesses. It's quite natural, whatever sites a person works with, to assume that someone is working on a single installation site unless they have otherwise stated.

I have as many as 12 sites on a single code base ... disabling all contribs just is not a viable option for me

Now you've clarified your situation, I can see my suggestion was addressing with a slightly different problem. Please everyone ignore my earlier post which is being dealt with in a different queue. Thank you.

moving to Drupal 8 queue

#107038: Javascript to select module dependencies

i have no clue. just noting a similar issue :)

Here is a patch that allows users to disable any module (except the required core modules). If the module has dependants then the confirmation form suggests to disable them as well. Needs some testing.

Fixed plural message for disabling multiple modules.

Now with a test case :-)

...less vague issue title (if you guys don't mind) and subscribing too.

I'll go through the issue and update it's issue summary according to Issue summary standards. Someone with more knowledge please update the "API changes" and other sections too as required. Thanx.

PS: ...talking about API changes, if there are none I mean, could D7 possibly benefit from this too?

...done. Please update it as you see fit.

...compliance to issue summary template ;)

Great, I see no API changes here. Updated the issue summary.

Thanx for taking the time to reply and update the summary Klaus! No API change is great news, because we have more chances to get this backported to D7 ;)

Patch does not apply anymore. Here is a new patch with an additional test case for the disable ordering.

updated ui changes & api changes

...updated link to latest patch in issue summary to point to #21 ;)

Can someone suggest a couple of contrib projects with multiple dependencies and multiple levels of dependencies too (IOW modules that depend on others that in turn depend on more)? Thanx.

Major issues:

1. Dependent modules have to be disabled first. Because they rely on the functionality provided by modules they require.
2. Drupal's hook system is based on the mere existence of functions. Hence, when disabling multiple, interdependent modules at the same time, arbitrary and unintended hook implementations are invoked.
3. It would be utterly wrong to automatically disable dependencies. At maximum, there could only be a belated intermediate/confirmation form (after disabling the dependent module(s)) that asks the user whether she also wants to disable the required modules (and of course, only suggesting modules that are not required by other enabled modules).

See also:
#1029606: Regression: Not loading the .module file causes a fatal error when uninstalling some modules (as does loading it)
#151452: Uninstalling modules does not follow dependencies and can lead to WSOD
#592800: Dependent modules are still installed when required modules return errors in hook_requirements('install')

The JavaScript suggestion in this issue seems to be a duplicate of #107038: Javascript to select module dependencies

1. Yes, they are disabled first with this patch.
2. Uhm ... not sure what you mean. Yes, we should take care of the ordering when disabling modules. Can you give me an example where this approach could fail?
3. This patch is not about disabling dependencies automatically. It is about disabling dependents. Updated the issue title, sorry for that ambiguity.

Alright, thanks, now I understand. Not backportable, so removing tags.

Overall, this idea makes sense to me. However:

You can try to implement this, but this will require excessive tests. I'm not sure whether all edge-cases are covered by existing modules in core, so it's possible that we have to add some hidden testing modules that depend on each other, and which additionally implement some advanced hooks; e.g., hook_disable(), hook_modules_disabled(), hook_system_info_alter(), containing direct calls to functions in the required/parent modules, and ideally also a registered and auto-loaded class including override (extended class in a dependent module).

FYI: Everyone is aware that the process of disabling and uninstalling modules is time-consuming and cumbersome, but as of now, it's the only way to ensure that modules are processed in the correct order, and more importantly, that hook implementations are processed in the correct order and no implementations are invoked that shouldn't be invoked. In other words: Cumbersome is better than fatal errors and WSODs.

Who said that we'll accept and implement an idea that is *proven* to give fatals and WSODs? The goal is to correct the current cumbersomeness + have a solid solution. I am pretty confident we'll figure a way eventually. Fear of *possible* errors and WSODs shouldn't be a reason to stop working on improving things. The same goes for fear of excessive work and thus sticking with the old ways instead.

So, yes, lets have as many tests as required to have QA but lets fix this.

PS: I was under the impression that only API changes held back backporting. Does the same thing stand for any important UI changes too?

@sun: the patch already has test cases that cover the general dependency chain. Modules are ordered correctly when they are disabled.

Why do I have to write excessive tests to get this approved? Yes, I can imagine that there could be edge cases that might lead to unintended behavior. But that applies to any new feature that enters Drupal core.

Let's get to the details:

• hook_disable(): This is called when the module itself is disabled. It is not called if another module is disabled. Why should I test for that?
• hook_modules_disabled(): Might be interesting whether this hook is still called in a previously disabled module.
• hook_system_info_alter(): same here, but that would apply to any hook then. Could you give an example why we should exactly test for this one?
• registered and auto-loaded class: why? The module was disabled and no code in it what so ever should be executed, so why should we test for that?

So I can see only one interesting additional test case on hook_modules_disabled(), but that's it. Marking as "needs work" until we have that test.

New test case added that checks hook_modules_disabled() on disabled modules. Added yet another test module for that (disable_test). Everything works as expected.

@sun: is that enough or can you come up with another case that would fail?

Testbot seems to be broken, re-test later.

Tagging as novice for the task of rerolling the Drupal 8.x patch on account of #22336: Move all core Drupal files under a /core folder to improve usability and upgrades.

If you need help rerolling this patch, you can come to core office hours or ask in #drupal-gitsupport on IRC.

Reroll.

That's a legitimate fail, so it looks like the patch needs work yet.

Doesn't apply against HEAD, so here's a reroll.

Edge case: Say you have Comment module enabled, Forum disabled. Now untick Comment, tick Forum. Current message: "You must disable the Forum module to disable Comment."
That message looks fine, actually. So just to make it sure: Should the message be like that? Will Forum module disabling hooks be fired, although it was never enabled?

Meh ... wrong diff.

There will be no disabling of modules in D8 - only uninstalling: #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed

...

updated link to latest patch ;)

Can this still go in given we're now in Beta? I was just doing some testing and hit the uninstall page - and found this help text

"The following reason prevents Block from being uninstalled: Required by: Custom Block"

That doesn't seem very user friendly to me, and could probably be phrased better...
perhaps "Custom Block requires this module to be installed. It can not be uninstalled."
or "This module can not be uninstalled because it is required by Custom Block. "

Then I found this issue - which would require different language again.