Drupal installation guidlines -- Drupal best practices

As a follow up to my posting about the my Drupal script library, I thought I'd write a bit about the installation techniques I've been using for Drupal installs.

As described in the script README file (and practiced by the drupalDeploy.sh script), I create and maintain a particular installation system w/ all my Drupal site installations.

First: One installation per site.

Maintaining one installation provides several wins and very few disadvantages.


  1. Updates are particular to that site.  Even though with Drupal 5, modules can be put under the 'sites' directory (and they should! see below), updating the Drupal core on one site in a shared installation will require an update process on all other sites in that installation.  This means more sites to check, more potential issues to work thru, etc.  With all sites occupying their own Drupal installation, updates can be done on a per site basis.  (And with the drupalDeploy.sh script and a Drush-based install, this is a quick operation.)
  2. The site remains portable.  Because the site is included all in one directory, it is easy to move around w/ ease.
  3. Provides lots of structure for easy scripting.  My scripts leverage the fact that there is one installation per site and they save me a lot of time.


  1. Disk space.  Yes, one install per site takes more disk space.  But, considering that a Drupal (5.0 latest) install is 4.4M, it's not that big a deal.  (Update: with git, this has increased to 18M as git stores all the history in the .git directory.  But the argument still stands.)
  2. Mass updates.  Some might say that being able to update all sites w/ one file update is a win.  I disagree -- updating the files and running update.php is the easy part (it can be scripted).  Checking your site to ensure nothing is broken is what takes the time.  Why rope yourself into HAVING to do this for more than one site at a time if you don't have to?

Second: Use a CVS Git Drush based install

Makes installations easy. A Drush-based install does not have the ability to find updates that SCM-based installations do; but the ease of deployment makes up for it.

Third: Put modules/themes/files dirs under the sites/<sitename> dir

As I describe in the README file, I put a site's modules, themes, and files directories under the installation's 'sites' directory.  This makes the site much easier to back up and ultimately more portable.  A Drupal site's state is defined by the database contents, any installed modules and themes, and the contents of the file upload directory.  Putting all of these (except the database of course) makes things more straight-forward.

Furthermore, my scripts provide for the generation of backup files placed in a 'backups' directory under the installation's 'sites' directory.  This allows backups to just process this single directory tree (and removing the need to backup the multiple copies of Drupal).


Free Tag:


After wrestling with maintaining a multisite install for several months (mostly procrastinating upgrades), I definitely concur with your strategy. I can think of very few reasons to share Drupal core and even contributed modules across different sites. Maybe on my development server (where I don't care if databases get corrupt since I can restore them without users hammering it) it can save me some time and disk space. What were Drupal developers thinking when they offered the multisite option? Is there something I'm missing? nonzero (http://drupal.org/user/494198)

I can think of a few edge cases that a multisite installation might be a good idea -- they mostly revolve around cases where mods to the Drupal core files are shared among all sites; but in general, I do think that it's a ungood idea.

I'll give the Drupal devs a break tho -- we have the benefit of hindsite here.  At the time I'm sure it seemed like a good idea.  It sure seemed like a good idea when I was setting up my first group of sites.  It was only afterwards that I began to notice what a pain it was.

Note: I have edited this comment to take into account that Drupal is now hosted under Git (no longer under CVS).  You can see my full post on this subject for more information.

The Drupal Script Library has again been re-written -- this time to use Drush to download Drupal and contributed modules.  See my full post on this for more.