Drupal Module Folder Organization

Organization is important for any Drupal site larger than the simplest of blogs. It is paramount for multi-site installations that are already bulky with numerous site folders, themes and subthemes. I have observed that if I don’t maintain a good organizational format within my multisite structure, I can very quickly become lost locating specific files and lose precious productive time. Drupal 7.x does a pretty good job of organizing its own data by creating separate theme and module folders for “all” sites but when it comes to multisite installs, a little early and continuing housekeeping goes a very long way.

Every site that I create in a Drupal multisite install includes the standard folders: files, modules and themes. These serve to organize my sites pretty good, however, as my sites grow and I become a more advanced “drupaler”, I find myself using more and more contributed modules, creating my own custom modules, and installing many modules to specific sites. Therefore, the primary focus for organization centers on a sites module folder.

Drupal keeps track of its core modules in a modules folder residing in its root folder. It also graciously keeps track of all of our additional modules in the /sites/all/modules folder, which may be just fine for a simple, single-site install. For a more complex single-site install or multi-site Drupal installations this folder can very quickly become a disorganized mess of contributed modules, custom modules and features. In order to prevent this disorganization, I follow a seemingly popular convention regarding module folders; all of my sites/all/modules folders contain at least these three subfolders:

• custom – for all of the custom modules that I write
• contrib – for all of the contributed modules that I download from Drupal.org
• features – for all of the features (for specific use cases) that I export with the features module

*Important*: In a multi-site installation the sites/all/modules folder and subfolders are used only for those modules installed in all of the sites. In this scenario, I also create the same custom, contrib and features folders in each individual site folder to contain modules specific to individual sites.

Additionally, I also include the following subfolders in my modules folders on an as needed basis:

• dev-tools – in case I may be taking a site from development to live – this makes it easy to remove these modules
• patches – in case I have patched any of my custom modules – it’s better to maintain these patches near the modules that I have patched rather than a local hard drive somewhere.

This organization convention may not be the best solution for every Drupal install, or other developers may have good or even better suggestions, but whatever convention you may choose to use, organization is always better and more productive than no organization at all.