Quick Tip: Clean Up Your Drupal Modules Folder

Let's say you inherit a Drupal site and the modules folder looks like this:

Dirty modules folder

And being an organized dev, you'd rather it look like this:

A nice organized modules folder

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

  1. Back up your database
  2. Install Registry Rebuild if you don't have it already
  3. Move folders
  4. Run 'drush rr'
  5. Return to your regularly scheduled programming


Great tip, thanks! I did not know about Registry Rebuild!

Thank you! We were just trying to figure this out at our local meetup last night! Perfect timing!

Thanks for sharing. Got frustrated by this a few times before. Won't happen any more ;-)

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.

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)

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_…

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.

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.

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

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.

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

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Ready for transformation?