I want to organize non-core (modules that are not bundled with core) modules in Drupal 7. This is my proposed structure:

  1. Contributed modules - downloaded modules that are untouched
  2. Custom modules - downloaded modules that are modified to suit the requirement
  3. local modules - self-developed modules

I GUESS, the best approach for this is to make three folders within sites/all/modules like below:

  1. sites/all/modules/contrib
  2. sites/all/modules/custom
  3. sites/all/modules/local

Now, there are two ways to install a module:

  1. Manually
  2. From the admin panel

While installing the new module manually, everything is fine. I can just go to the directory and place the module there.

But how to install a newly downloaded module in sites/all/modules/contrib from admin-panel?
Moreover, is there any better approach for organizing non-core modules?

  • I think you can not make sub folder on modules folder, that's why it will not detect the sub-folder modules. Everything should be in sites/all/modules
    – Bala
    Nov 21, 2013 at 7:29
  • @bala: I disagree. I have came across many tutorials which suggest directory structure somewhat similar to what i have proposed. But the problem is that they have not mentioned any details about my doubt. Nov 21, 2013 at 7:31
  • @Bala: check this Nov 21, 2013 at 7:32
  • Bhavik I don't know about this, thanks for sharing the link and I"m not down voted.
    – Bala
    Nov 21, 2013 at 7:35
  • 2
    downloaded modules that are modified to suit the requirement, not recommended -> don't do it! I follow simple structure of created two directories inside the modules folder : contrib and custom, and download the modules using drush. In this way the contributed modules automatically get placed under the contrib directory, and I do custom coding in the custom directory.
    – AjitS
    Nov 21, 2013 at 7:37

3 Answers 3


Keeping your modules folder clear is important part of development. This is my common structure:

  • contrib — modules from Drupal.org
  • custom — modules developed for this project
  • features — exported features for Features-driven development
  • unstable — sandbox, forked, unstable, patched modules

Here are some examples how to organize patches/forks:

But how to install a newly downloaded module in `sites/all/modules/contrib from admin-panel.

Use Drush please.

drush dl views rules # will download Views and Rules into sites/all/modules/contrib automatically if contrib folder exists.

You also can specify --destination where to download project.

  • I sometimes have a separate subdirectory sites/all/modules/git, which is either itself a symlink or which contains symlinks to external folders. This allows to have modules which have their own git history. It is particularly useful during contrib module development, where the site itself is not that important, but the modules are.
    – donquixote
    Jan 4, 2014 at 22:56

The structure you suggest will work.

However, you should, as a general rule, not modify contributed modules that you download. By forking a module, your local copy will be an island, and it will difficult for you to benefit from future bug fixes and other improvements added to the contributed module.

The usual way is to have two subdirectories below sites/all/modules/ - contrib for downloaded modules and custom for self-developed modules. Use drush instead of the admin panel to download and install in order to place downloaded modules in contrib.

However, sometimes you need to tweak a contributed module.

Instead of just forking a custom version, you should present your use case and requirements in the module's issue queue on Drupal.org, and upload a patch to extend the module's features to cover your use case. By doing this, you will contribute to the Drupal community, and benefit from reviews and suggestions about your proposed patch made by other users of the module.

It may, however, take some time before your patch is incorporated in the module's official code base. In the meantime, just keep a copy of the patch file, and use git to apply it to new versions of the module that are released by the module's maintainer. If you're unlucky, you may need to reroll the patch if the module is radically changes, but this is still a better alternative than maintaining a local fork by yourself.


There is the module_install module, that allows you to choose which subdirectory within /sites/all/modules to install a module to, when using the admin module installer:


Just create whichever subdirectories you want, install the module (manually put it in /sites/all/modules/contrib if you want to follow best practise!), and then enable it.

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.