Add link to disable non-required core modules for upgrading

I will do this one.

Good idea!

Steps to implement:

1. Display button/link to "Disable all non-core modules" (if variable util_modules_disabled is not set).
2. On click,
   • gather all those modules
   • store them in a variable util_modules_disabled
   • disable them in the admin/build/modules form and submit it
3. Display a button/link to "Re-enable all disabled non-core modules."
4. On click,
   • retrieve list of disabled modules from util_modules_disabled
   • enable them/submit the admin/build/modules form
   • Delete the util_modules_disabled variable.

I have implemented a quite similar feature into Drupal Administration Menu that allows to disable/re-enable all "developer" modules in one fell swoop. Doing this one should be quite easy, and I really would like to provide this feature to the grand crowd of admin_menu users.

Thus, moving over to admin_menu's queue. And because that would really help folks trying to upgrade from D5, I'm hereby downgrading this issue for 5.x.

Better title.

I think starting with 6.x all updates will run even if the modules are disabled - i.e. there may be no point to implementing this for 6.x.

Well, pwolanin actually tried to say: It does not matter if contrib modules are enabled or disabled during an upgrade to D6. All update functions in all install files will be executed during an upgrade.

However, that sounds really scary. Can anyone confirm this behavior? If this is really the case, this issue does not make sense at all.

Why not create a menu that disables all modules prior to upgrading since this has to be done anyway, the admin menu is perfect for this.

@darumaki: See comment #9.

oh I see, so when upgrading to 6 we didn't have to disable the modules ?

@darumaki: That is only true because by default all modules that do not have "core = 6.x" in their .info file are disabled by default when upgrading to Drupal 6.x. However, the advice still being distributed with each Drupal 6.x version is that all contrib modules should be disabled before upgrading, so presumably that advice is still important.

Therefore, this feature is still required, but is required for 6.x users not 5.x users upgrading... therefore moved back to Drupal 6.x.

At least in the meantime, I've created two modules for my own use that retool code from Quick Admin Modules to disable and enable all contrib modules... The Drupal 6.8 update was the straw that made me decide I wanted to have a quicker way to do this...

However, Drupal does not honour requests to turn off a module if it has dependents, even if those dependents are being simultaneously being switched off. QAModules has also had this same issue already I think, and this has been encountered in a patch elsewhere that I cannot find right now! Anyway, it would appear the module enable and disable page is checking for the active vs. disabled status of dependents in the database, rather than looking for whether dependent modules have also been switched off in the same "Save Configuration" update on the modules page—which I guess is fair enough given Drupal doesn't expect you to be able to submit a request to turn off a module if something else was depending on it.

So... I went looking in core to find exactly where this code was to have a look at exactly how it operates, but I don't seem to have found what I was looking for. module_disable($module_list) in /includes/module.inc is presumably what is being called, but where is it being called from, because unless I am missing something I'm not finding where the dependencies are being checked and thus why these additional modules are not being disabled... Probably it is staring me right in the face, but any leads?

http://api.drupal.org/api/function/module_disable/6/references

Thank you... (Ah yes, RT*M). I had even been to that page earlier yesterday—I must be more sleep deprived than I realise! :)

@Sun - I'm pretty sure that if you have a contrib module active in 5.x, its updates will be run in 6.x even if it's not active unless it puts an abort in its update functions.

In general I think such links are problematic - e.g. they open up a CSRF vulnerability.

@pwolanin: I think it's an interesting point that having a menu link to do this is a security risk; what do you think would be the best way to achieve the goal? Because at present there is in my view a major usability issue with the advice that all contributed modules should be switched off for each 6.x upgrade—if you have multiple modules with multiple layers of dependencies, this is fiddly, time consuming, and thus an irritating waste of time. There is no technical reason why it needs to be difficult to turn off all contributed modules for an upgrade, only that no way has yet been implemented to do so.

My guess is that many users don't bother to turn off their contributed modules for an upgrade within major versions (e.g. 6.7 to 6.8). So I'd be interested in comments on how common people think this is, and if I am right and apparently people are mostly having no problems, whether in fact the advice to turn off all contrib modules when doing such an upgrade is actually necessary.

I'm considering writing a helper module for ldap integration that helps users debug ldap configuration problems. I'd like to have a button that disabled all modules but the ldap modules. And another to turn them back on.

A function that took a set of non-required modules as arguments and disabled all but those, would be very useful for such a debugging a module. With a complementary restore function.

If modules_disable (http://api.drupal.org/api/function/module_disable/6) doesn't remove module's that are required by other modules, seems like it needs fixing. Another function that figured the correct order to disable the modules, then called module_disable one module at a time.

@johnbarclay that is a very interesting idea. I have just had CVS access approved to upload the module I have created to disable all contrib modules. Your idea would fit nicely with my planned roadmap for v2.0 and I will try and include that. Am away from my dev machine for the holidays but will follow this up soon...

(Posting updates in each of the places I had previously discussed issues related to this...)

pwolanin noted (#17) that to implement this as a menu item in Administration Menu opened the risk of a cross-site request forgery.

I therefore decided that a separate module that implemented this as a button to deselect the items on the module administration page (with the configuration then having to be saved by the user) was the most secure route. I have now implemented this in Contrib Toggle module:
http://drupal.org/project/contrib_toggle

Personally, I would like to see this functionality in core in the future—since it is the recommended upgrade advice for every upgrade.

Actually, this no longer makes sense. Drupal 7 will execute module updates in the proper order, using a directed acyclic graph (DAC).