Quick Tip: Clean Up Your Drupal Modules Folder
Let's say you inherit a Drupal site and the modules folder looks like this:
And being an organized dev, you'd rather it look like this:
So you create a 'contrib', 'custom' and maybe a 'features' folder for good measure and move everything around.
Then your site blows up and starts giving you errors all over the place.
What happened?
You pulled a shell game on your site, moving modules around and not telling it where to look.
If you click the first Google link you find, you might end up thinking you need to disable all your modules before you move them, but who has that kind of time? The easy solution is to install Registry Rebuild, (just clearing your cache probably won't do it).
- Back up your database
- Install Registry Rebuild if you don't have it already
- Move folders
- Run 'drush rr'
- Return to your regularly scheduled programming
Comments
Yes, but ... Unfortunately the convenient core module Update Manager still won't handle modules in subdirectories like this. I asked about it on drupal.stackexchange.com: someone said to use only Drush instead. I also found an open Drupal issue on the topic. There's a sandbox module that can help: Better Updater.
Fri, 08/31/2012 - 01:48
Thanks a lot on the tip. I was used to clearing or modifying the registry with SQL queries, but this is much better =)
Fri, 08/31/2012 - 17:25
Joaquin, I'd like to compliment you on your excellent choice in first names.
Fri, 08/31/2012 - 17:59
hahahaha, likewise tocayo ;-)
Fri, 08/31/2012 - 07:19
Great tip, thanks! I did not know about Registry Rebuild!
Fri, 08/31/2012 - 10:48
Thank you! We were just trying to figure this out at our local meetup last night! Perfect timing!
Fri, 08/31/2012 - 13:48
Thanks for sharing. Got frustrated by this a few times before. Won't happen any more ;-)
Fri, 08/31/2012 - 15:24
Thanks for this, I must say I have run into this issue after inheriting a project or two.
Worst case scenario, I needed to move modules out of the drupal modules folder into the sites/all/modules folder.
Sun, 09/02/2012 - 04:23
Any time that I've moved modules around and have the system table lose them I've just had to run "$ drush updb" and it has "found" them again. No need to install yet another module to get the job done.
This does the same thing as running update.php, so if you have any outstanding update scripts from modules that you've upgraded recently they will be run too (you can run updb even without any modules needing updates and it will still fix your system table). If you *do* have outstanding updates you might want to make a quick database dump before continuing ($drush sql-dump --gzip --result-file=foo.sql.gz)
Mon, 09/03/2012 - 14:50
Hmmmmm, could be. Because just clearing the caches doesn't work. I'll try this next time.
Tue, 09/04/2012 - 05:40
Just clearing the caches definitely doesn't work, that doesn't do much more than truncating the cache_MODULE tables afaik.
When update.php is run, it calls module_rebuild_cache() which cleans up the system table.
I'm looking at D6 right now but it looks like all you need to do to fix your system table is call module_rebuild_cache() anywhere that php is run as that rewrites the system table for module info - http://api.drupal.org/api/drupal/includes%21module.inc/function/module_…
Wed, 09/05/2012 - 14:47
Glad so many of you found this useful! @thedavidmeister RR isn't a module. I've had times when updb didn't work for me but rr did...but always good to have more tools in the toolbox.
We also find it useful for deployments to clean things up at the end of a script without going through the y/n dialogue.
Mon, 09/10/2012 - 13:29
Before installing, or running Registry Rebuild based on a blog post, I would love to know why it works. What is being done behind the scenes that simply updating the Modules page by clicking 'Save Configuration' does not do? If I move modules, click 'Save Configuration' on the Modules list page, I can use phpmyadmin to view the 'system' table, sort by module name, and verify that the table has been updated with the current paths of the moved modules. So what is Registry Rebuild actually doing? Knowledge is power as they say.
Tue, 09/11/2012 - 07:12
Well, you don't have to rely on the blog post... I just had a quick scan through registry_rebuild.drush.inc and it looks like it is not a whole lot more than a wrapper around the core registry_rebuild() function in drupal 7 and module_rebuild_cache() in drupal 6. The whole thing is only about 200 lines long and most of it is dedicated to including relevant bootstrap files and reporting "what happened".
It seems to have deliberately been written in a way that you can run it from drush even if your site has been so damaged by moving around modules and whatnot that you get fatal errors when running "$ drush updb" which calls exactly the same functions as part of the update process but apparently requires a somewhat "higher" level of bootstrap to work.
What Registry Rebuild is "doing" is taking the functional part of the update.php process (that includes many other things like clearing caches, and obviously running update scripts) that solves this particular problem and just emulates that.
Since RR is only invoking some things directly that Drupal core does as part of it's normal maintenance routines so it is theoretically pretty harmless (as they say on the project page) but if your site is close enough to being fubar to require this kind of direct surgery then a database backup is definitely a good idea before you do *anything* :)
Tue, 09/11/2012 - 15:49
The beautiful thing about open source is that it's, well, open. You can always read the source code to find out how and why things work. Looks like @thedavidmeister gives a nice explanation.
Thu, 09/20/2012 - 02:37
Hey, when it rains it pours right? I just had an experience where the database was so screwed by modules moving around that I couldn't run updb through drush. Unfortunately Registry Rebuild didn't help either!
The culprit was a ctools plugin definition in my cache table that was trying to include a file that just wasn't where it thought it would be. I couldn't clear the cache through drush because I was getting fatal errors.
The solution for me was to manually truncate all cache_XXX tables and the cache table and then run updb.
Thu, 09/20/2012 - 16:48
@thedavidmeister,
Hey thanks for chiming in! Always good to have info about those edge cases. I bet you just saved someone a lot of hair pulling. ;)
Sat, 12/15/2012 - 06:37
Although if you have 100s of modules enabled in an drupal website, the visits to the modules folder is very less. The modules are well organized in administration pages. However it may help when you are developing an website. Still I think it just brings more complexity than make it simple
Thu, 08/30/2012 - 23:48