User login
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 drupalCVSDeploy.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.
Advantages:
- 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 drupalCVSDeploy.sh script and a CVS 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.
Disadvantages:
- 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.
- Mass updates. Some might say that being able to update all sites w/ one file update is a win. I disagree -- updating the files is the easy part (it can be scripted). Running update.php and checking your site is what takes the time. Why rope yourself into HAVING to do this for more than one site if you don't have to?
Second: Use a CVS based install
Makes installations easy. Makes it easy to see what you did should you ever (accidentally or on purpose) modify a core or contrib file. The drupalCVSDeploy.sh script makes it trivial to maintain a site installed this way. Why wouldn't you do it? The .htaccess file that is installed w/ Drupal disallows access to the CVS directories, so you can go ahead and use it for a external / production site.
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).
Comments
What were they thinking?
Probably seemed good at the time.
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.