Last updated March 7, 2013. Created on September 16, 2007.
Edited by 2020media, Sheldon Rampton, LeeHunter, sepeck. Log in to edit this page.

Directory Precedence

Contributed modules and themes can also be placed in the directories /sites/sitename/modules/ and /sites/sitename/themes/. Often, the sitename will be 'default'.

Contributions placed there will only be available to the named site, whereas those under /all/* are available globally. For a single site setup, this probably won't make much difference to you, but if you ever start modifying downloaded code for your own use, it's a good idea to isolate your changes from the clean versions.

It's possible to have two versions of any module (even core ones) available on the site. Your installation will choose from the most specific one available (first /sites/sitename/modules, then /sites/all/modules, then /modules). You can take advantage of this to test patches without damaging your existing files.

Also, you can place modules anywhere within subfolders underneath any of these /modules/ folders. They will be searched recursively when you visit your admin/build/modules page. You can use this to further organise your available items.

Multi-site Considerations

The steps for installing in a multi-site configuration are much the same. The difference is where the modules and themes directory is located. If you use the /sites/all directory, then any module or theme installed under it will be available to all sites using the same code base.

If you wish to limit the access to a module or theme to a specific site, then create a modules and/or themes directory under that sites folder.


Anything in a site specific directory will not be accessible to other sites sharing the code base.

Installation profiles

Modules and themes located inside the /sites directory take precedence over modules and themes located inside an installation profile. Suppose, for example, that you have an installation profile named "myprofile" which contains the Views module, and other versions of the Views module located elsewhere, as follows:

  • /sites/all/modules contains Views 7.x-3.0
  • /sites/ contains Views 7.x-3.x-dev
  • /profiles/myprofile/modules contains Views 7.x-3.x-rc2

In this scenario, the website at would be running Views 7.x-3.x-dev. Other websites running on this codebase would be running Views 7.x-3.0, even if those websites were set up initially using the "myprofile" installation profile.

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


Robin Millette’s picture

What about install profile modules found in profiles/PROFILENAME/modules/ ? Are those seen first, or overridden by sites/SITENAME/module?

patcon’s picture

Came here wondering the same thing Robin :)

Will post back if I find a conclusive answer.

patcon’s picture!
Alrighty, so the API page would seem to imply that the order to search includes (for D6 and D7):

  1. profiles/PROFILENAME
  2. sites/all
  3. sites/ (or wherever the settings.php file is located)


uberEllis’s picture

Does that mean a newer version of a module in sites/all/modules/ will override an older version module present in profiles/PROFILENAME/modules/?

I know that sites/ will always override other versions on the platform.

patcon’s picture

Yep, I believe so :)

sonicthoughts’s picture

would be great if this were definitively documented somewhere ....