Last updated June 13, 2013. Created by add1sun on October 15, 2007.
Edited by JvE, 2020media, JmsCrk, eigentor. 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 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 Drupal.org forums, or join #drupal-support in IRC.

Comments

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

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.

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

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
or
admin/reports/updates is reporting: No code updates available.

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

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