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 drupalGitDeploy.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 drupalGitDeploy.sh script and a Git 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. (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 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 drupalGitDeploy.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 .git directory, 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
Updated this post for Git usage
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.
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.