When working on large projects it’s important to attempt to maintain a form of organization to your site assets: Images, Media, CSS, Templates, Certificates, Libraries — and even PHP code. In Drupal we can define components of code into Modules. All modules may interact with Drupal during its runtime. But, some modules come shipped with Drupal out-of-box and are refereed to as core modules, other modules are provided by the Drupal community (otherwise known as Contributed Modules) and lastly you can create your own project-specific modules typically refereed to as custom modules. A given Drupal website is typically made up of a combination of all these types of modules. Here I’ll outline my current best practice approach to maintaining your project drupal’s modules folder.
Where Can A /modules Folder Exist?
A modules folder may exist within an Install Profile, the folder /sites/default, the folder /sites/all/modules or any subsite directory of the format /sites/SUBSITE/modules. The only caveat to these “rules” in Drupal 7 is that a site installed by a Profile has visibility to the modules in it’s Profile directory and it’s site directory; and the sites/all/modules directory is visible across all subsites for a Drupal installation.
I will refer to any one of these possible locations for a modules folder later in this article as the PROJECT ROOT. This is because whether it’s an install profile, subsite or the default drupal site — a complete drupal website will be using these modules.
Preferred Modules Folder Structure
Regardless of where you’re creating a modules folder my current preferred layout is as follows:
[PROJECT ROOT /modules] |- contrb |- custom |- dev-tools |- patches |- migration
Within your project’s /modules directory I lay out the following folder structure for any project:
- Contrib: The contrib folder is to be a repository for contributed community modules. As your Drupal experience grows you’ll likely accrue a typical working-set of modules you’ll find most websites require to function well, and which you’ll become familiar with to utilize solving various types of problems.
- Custom: The custom folder is a repository of custom modules created solely for your project. If time allows you may find a custom module can be evolved after the completion of a project and released to the public as a contributed module.
- Dev-Tools: This folder is for development tools used solely on your development server, and not in production. Modules in this folder should be turned Off in production. Examples of modules I put into this folder are Devel and Maillog.
- Patches: This is a folder used to store any contributed module that I had to patch in order to fix a time-critical bug currently not resolved, or known, on Drupal.org. Modules in this folder may move back to contrib after they’ve been given an official release. (sometimes I call this folder Modified, but patches is very clear)
- Migration: Lately my workflows involve migrating data from Drupal6 websites or legacy PHP applications into Drupal. I find placing my Migration Classes and modules into 1 folder allow a nice level of organization and separation for these short lived modules on a website. Typically these modules are used to prepare the site to go-live, once in production most of these modules can be completely removed from the project.
So currently this is my preferred modules folder layout. It’s flexible, organized and succinct for use throughout a project’s lifecycle.
Looking for quality web hosting? Look no further than Arvixe Web Hosting!