In Pro Drupal 7 Development: Third Edition, the authors suggest moving custom modules inside subfolders of /sites/all/modules/custom/, i.e.

  • /sites/all/modules/custom/mymodule1
  • /sites/all/modules/custom/mymodule2
  • /sites/all/modules/custom/mymodule3

Does this have any special meaning for Drupal core? For example, is this folder omitted when checking for new versions of modules? I haven't checked this so far so I'm just curious.

Before I read the book I put my custom modules like this:

  • /sites/all/modules/mymodule1
  • /sites/all/modules/mymodule2
  • /sites/all/modules/mymodule3

3 Answers 3


It shouldn't break anything, and it has no special meaning to core: as long as it's in a modules directory, it will be searched recursively (which is why larger projects often have submodules in a subdirectory).

However, it does allow site-builders to organize their modules more neatly than just lumping everything together. You'll often see modules/ directories structured in a way similar to this:

  • /path/to/modules/contrib: Modules downloaded from contrib
  • /path/to/modules/custom: Custom modules that you write for this site
  • /path/to/modules/devel: Modules not meant to be enabled on live
  • /path/to/modules/features: Modules created by Features

This organizational setup is often used when building installation profiles and distributions as well, so if you download a few you'll probably see more examples of this sort of organization put into practice.

  • On your existing site, if you just move, e.g. the modules in sites/all/modules/ to sites/all/modules/contrib/ then you may encounter errors, perhaps fatal (seen in the browser on your site and at the command line when using drush) as myself and other folks have seen--that they describe here: drupal.org/node/1423374 For me, none of the remedies worked and I still got the PHP fatal error complaining about a file within one of the modules, geofield, so I had to revert back to original path. Comments? Commented Aug 28, 2013 at 15:40
  • You may also find this answer helpful if you have errors due to the original paths needing modifying in the database: stackoverflow.com/a/13985139/227926 Commented Aug 28, 2013 at 21:52

In regards to errors after moving modules around in folders: Configuration > Development > Performance > Flush All Caches

If Errors persist: http://example.com/update.php then follow through steps.

Try the Administration Menu module.

  1. Download Administration Menu.
  2. from admin/modules enable Administration Menu along with Administration Menu Toolbar Style (at same time, disable core Toolbar module).
  3. Move your modules and/or module folders as you like
  4. Now, from Home (top left) dropdown, Flush All Caches > Class (or Theme) Registry

Lookup "Drupal Registry" or see the Drupal API description.

Alternately, the PHP is: <?php function registry_rebuild() { system_rebuild_module_data(); registry_update(); } ?>


Remember that when you can always use drupal_get_path() in your custom code if you need to use the path to your module. It will continue to work when you have multiple subdirectories inside sites/all/modules.

drupal_get_path('module', 'my_module_name');

On large sites, I split up modules into three folders, but you can use more:


If you are building your site with Profiler, you can also specify which folder the module code is placed in. For example, to add File Entity to your installation profile inside the contrib folder:

projects[file_entity][version] = "2.0-alpha3"
projects[file_entity][subdir] = "contrib"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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