1

I ran into an unexpected situation after installing the 7.x-2.1 of the Multilang - Embed multiple translations inside a unique node or block module. I was actually experimenting with that module to better understand the question about Why is the recommended release of my module not proposed in Drupal updates?

After I finished experimenting with that (version of that) module, I wanted to disable it again, via the typical admin/modules link. The link still worked (so no WSOD situation like you may get if you run into memory problems), but not even 1 module (enabled or disabled) was shown in my module list. So no way to "disable" that Multilang module from there.

How can I disable this module without using the admin/modules link (since there it doesn't show up)?

Improve this question

2 Answers 2

Reset to default
3

  1. I was lucky enough to have Drush available. So by simply using drush dis multilang, the module got disabled. And Eureca ... the link at admin/modules started to work again.

  2. Even though I have not had to use another approach, this would have been my plan-b: disable the Multilang module manually in the database, via an SQL command like so:

    UPDATE system SET status='0' WHERE name='multilang';

    or as a variation, using PhpMyAdmin (if that's available).

  3. If for whatever reason plan-b would not have worked either, you could consider deleting the entire module folder (for module Multilang) in the modules directory where that module got installed. That would, pretty sure, have "killed" the trouble module also. Though it would have left the module's row in the system table in some bad shape (to be repaired afterwards, probably with something like the "Registry Rebuild" module.

    However, as pointed out by Molot also (merci! aka thanks!), deleting files is problematic. Because it prevents you from ever running uninstall on a module. And Registry Rebuild will probably not fix that. So think twice before using this plan-c ...

Improve this answer
2
  • 1
    Deleting files is problematic, because it prevents you from ever running uninstall on module. Registry rebuild will not fix that, as far as I know. so generally 3 shouldn't be suggested without strong warning, and claim that another module may repair things is bold one.
    – Mołot
    Commented Jun 14, 2015 at 20:12
  • No problem. I only pointed that out because I screwed one of my sites that way. Nothing production, of course. For 2nd option - if one have BaM installed, he can save SQL command to file, and then use "restore" option. It will upload and execute file, any SQL file.
    – Mołot
    Commented Jun 15, 2015 at 7:42
1

When I run into a similar problem (Devel Themer is such a case) I just delete the bothersome module folder and run update.php. Then I re-upload the module folder where it was before and it shows as deactivated in the module list. You can then uninstall it from the data base if you're not going to use it.

Improve this answer
1
  • Hm, interesting alternative, especially if you don't have Drush available (or not familiar with using it). Thanks for sharing it!
    – Pierre.Vriens
    Commented Feb 24, 2016 at 8:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.