Last updated March 22, 2016. Created on October 15, 2007.
Edited by jeromewiley, ashish_nirmohi, JvE, 2020media. Log in to edit this page.

The best practice is to keep all of your contributed modules and themes in the sites/all/modules or sites/all/themes directory, as appropriate. If you are upgrading from a previous version or have already installed them in the main modules or themes directories and you wish to move them, it is possible but you just need to make sure Drupal knows you moved them.

  1. Go to Administer > Site Building > Modules (or Themes) and disable the modules/themes you wish to move.
  2. Move the modules/themes to the new directory you wish them to live in.
  3. Now go back and enable the modules again. Drupal will locate them in the new directory and update the system table as needed.

Typically you'll see a PHP "Fatal error: Call to undefined function myfunction()" error when Drupal doesn't know where your module is. If this is the case you may need to force the System Table to be rebuilt.

Forcing a System Table rebuild

The system table gets rebuilt when you visit: admin/build/modules. So if your module has moved and you've forgotten to disable it above then just visit the modules page and you should be fine.

However from Drupal 6 onward visiting the modules page may still leave some errors. Some contributed modules will not come back online because of paths stored in their settings and may cause various database errors. In these cases, try uninstalling the module completely. Or just leave it where it was before you moved it. It's also possible to modify the database directly to change the path if necessary.

Always remember to make a complete backup first.

Drupal 7 with Drush

If you are on Drupal 7 and you want to move modules, you do not have to go through the hassle of disabling them all. There is a Drush utility that can help you, it is called registry rebuild. Registry Rebuild flushes the registry, and thus rewrites the paths to the modules in the database.

If you do not have access to Drush on your server or do not use Drush, you can also run it just with PHP, as described on the project page. Drush usage is preferred, though.

Using Drush to rebuild the registry

Move your module folders wherever you want. Then run drush rr and drush cc all and maybe drush rr once more, and you are done.

This affects only the System Table so some modules may store paths in other places and still will not work after moving, as described above. However, these modules should be exceptions from the rule and the Registry Rebuild process will work in most cases.

APC or other opcode caches

If you use a PHP opcode caching tool like APC it is possible you need to clear their caches or restart them after following the above procedures.

Looking for support? Visit the forums, or join #drupal-support in IRC.


takinola’s picture

Do remember to use lowercase in naming the path for your contributed modules. Drupal (on some web servers) will only recognize "sites/all/modules" and not "sites/all/Modules". I blew a couple hours figuring that one out

fkildoo’s picture

I moved a bunch of modules (in batches) from core to sites/all/modules using this method, and now my site is super slow. About a 28 second load time just to view a page. All the modules seem to be working as they were before and I'm not getting any errors. Working on trying to figure this out.

Watergate’s picture

FYI: I have moved some contributed modules to a new directory and all I needed to do was running the update.php page, so no disabling/enabling...

etron770’s picture

As there are security updates for some modules I tried to move the common (not the special distribution) modules from profiles/... to sites/all/modules and started drush cc and drus rr.

So far so good the site is working fine except the update functions:

drush pm-update --no-core
admin/reports/updates is reporting: No code updates available.

There is at least one security update f.e for Views 7.x-3.5

etron770’s picture

I deleted the views directory and installed views manually and now drush is testing the views module for new updates, the other modules are also checked

Checked available update data for Token.         [ok]
Checked available update data for Variable.     [ok]
Checked available update data for Views.         [ok]

Update information last refreshed: Tue, 03/26/2013 - 11:20

Update status information on all installed and enabled Drupal projects:
 Name           Installed version  Proposed version  Status
 Drupal         7.21               7.21              Up to date
 Views (views)  7.x-3.6            7.x-3.6           Up to date

but not updated or reported in "Update status information ..."

Another workaround is to decrease the version number in the. info file
f.e the installed version is 2.2 the newest version is 2.3 set the version to 2.1
then run drush pm-update and after that module is in the version control

but its a workaround an a lot to do if there are a lot of modules installed...

lesleyb’s picture


My first time using drush but I successfully moved all the modules of the live and dev versions of a site to all/modules
I'm using Debian so your mileage may vary but these are the steps I took

1. Put the dev site into maintenance mode.
2. move the modules from devsite/modules to all/modules
3. cd to the dev site directory in /etc/drupal/7/sites/
4. run these commands from the command line :
drush -r /usr/share/drupal7 cc all
drush -r /usr/share/drupal7 rr
drush -r /usr/share/drupal7 cc all
drush -r /usr/share/drupal7 cc module-list
5. Take the dev site out of maintenance mode and check for any errors. (None found).
6. Repeat for the live site.

VVVi’s picture

If you move a CTools module to other folder and after running "drush rr" you got an error like this "Fatal error: require_once(): Failed opening required '/home/user/project/sites/all/modules/ctools/plugins/export_ui/'", than before executing "drush rr" to run "drush cc all". The same error can appear when you move the Views module to new location.

memcinto’s picture

Unfortunately drush cc all also fatals out on the require_once error (for rules, instead of ctools).

alexharries’s picture

Thank you, VVVi - that tip saved me a big headache :)