14

I put my modules in sites/all/modules. Is there a way to configure Drupal to find more modules in other locations as well?


Edited

I use Virtual Hosts often but not in the way you described. The format I'm familiar with looks like this, and it helps me put the entire work project somewhere else not inside www.

<VirtualHost *:80>
    ServerName testdrupal.com
    DocumentRoot "C:/proj/testdrupal"
    ServerAlias testdrupal.com

   <Directory "C:/proj/testdrupal/">
       Options Indexes MultiViews FollowSymLinks
       AllowOverride All
       Order allow,deny
       Allow from all
   </Directory>
</VirtualHost>

I think what you're describing is something different, right? I'm trying to leave the drupal folder inside www as usual, but move only the sites/all/modules to another location, but I still can't figure out how the VHost entry will look like in this case. Let's say I want to move it to C:/proj/testdrupal. I hope I didn't completely misunderstand you.

14

Before answering, it's helpful to have a little background about how Drupal finds modules. Drupal uses a list of suggestions from the Drupal root to figure out where to find modules. In order of priority:

  1. sites/$SITENAME/modules
  2. sites/all/modules
  3. profiles/$INSTALLPROFILE/modules
  4. modules

If Drupal doesn't find a module in (1), it checks (2). If it's not there, it checks (3), and so on.

For (1), if you're just using a basic, single-site install of Drupal, $SITENAME is default. Otherwise:

  • In Drupal 6, $SITENAME is the host name of the site. If your site is located at example.com, $SITENAME would be example.com.
  • In Drupal 7, $SITENAME is defined in sites/sites.php. If you look at example.sites.php, you can see how to define it. It's also important to note that any module listed there will only be usable for that specific sites, not all sites.

In (2), any module found there will be usable on any site in the Drupal installation. It will also be left untouched when you upgrade the core installation. This is, of course, the recommended place to put modules and likely all documentation you've read have told you to put your modules here.

(3) is used for installation profiles that require a specific module. Installation profiles are essentially a way to define a custom initial state for a Drupal site. For example, Drupal comes with two installation profiles built in: Standard, which includes most-used features, and Minimal, which only includes the bare minimum needed for a Drupal site to function.

(4) is used by Drupal core. While you can technically add modules here and they will be available for all sites, you shouldn't. Seriously. The modules folder is touched when Drupal core is updated, and will cause problems down the line if you're sticking modules you need for your site to function there.


Now that the background is out of the way, you can use file system tricks to have your modules housed outside of where Drupal looks.

For example, you could set up a symbolic link from sites/all/modules to another directory outside of the Drupal installation:

  • In Unix/Linux/BSD-based systems: ln -s /path/to/modules/folder /path/to/drupal/sites/all/modules
  • On Windows Vista/Server 2008/7 and higher: mklink C:\path\to\drupal\sites\all\modules C:\path\to\custom\modules\folder

As far as I'm aware, there's not much you can do in earlier versions of Windows that don't have mklink.

  • Thanks a lot, this really explains it, but I'm still having trouble getting it to work. Can you look at the Edit section in my post. It's more than can fit here. Thanks. – sameold Jun 4 '11 at 0:20
  • @sameold I've fixed and clarified the part about symbolic links. On Windows, symbolic links are kinda sketchy, but I believe the command I provided should work. – user7 Jun 4 '11 at 1:08
3

In Drupal 7, the directories where Drupal looks for modules are the following:

  • modules
  • profiles/$profile/modules
  • $config/modules

$profile is the value returned from drupal_get_profile(); $config is the value returned from conf_path().
The function that searches for system object files (modules, themes, etc) is drupal_system_listing().

The same directories are looked for, in Drupal 6. The only difference is that $profile is a global variable; when the global variable is not set, the function gets the value of the "install_profile" persistent variable, which has the default value of "default."

2

You can place them either in sites/all/modules, then they will be available to all sites (if you have a multi-site configuration), in sites/default/modules for the default site or sites/site.com/modules if you have that. For the latter directories, this means that they will only be available to that specific site.

Additionally, you can organize them as you want below those folders, meaning, you can create whatever sub-folders in there. A typical thing to do is creating a contrib folder and then place modules downloaded from d.o there while keeping self-written modules for that site in a custom folder.

1

Not sure what you mean, but we use a somewhat common convention of seperatating in-house modules from 3rd party modules.

'Home-made' custom modules would be in:

sites/all/modules/custom

3rd party modules would be in:

sites/all/modules/vendor

If having subdirectories does not match your needs, I believe you could easily symlink your /obscure/path/to/module directory into your drupal's module directory.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.