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.
- 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.)
- The site remains portable. Because the site is included all in one directory, it is easy to move around w/ ease.
- 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.
- 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.)
- 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).