I can't claim to be the world's Drupal
expert yet, but I'm learning some interesting tricks that are worth documenting and sharing.
First, my Drupal installations typically include a lot of contributed modules. They're distributed as .tar.gz files, which you upload to your server and unpack in the appropriate place. This can get tedious and error prone (e.g. I forget to unpack one).
I built a template directory with a complete Drupal install on a Linux box (you could do something similar with Windows if you had cygwin
or a similar set of Linux-like tools). I unpacked the Drupal version, then went into the modules directory and unpacked all the modules I typically use. That was easy to do with a script like this:
for f in module_directory/*.gz; do tar -xzf $f; done
Your mileage may vary with that script, depending on where you put the tar'd modules.
This allows a couple of nice things:
- One module I use, fckeditor, requires that you unpack the basic (non-Drupal) installation for FCKeditor in a subdirectory of the Drupal fckeditor module. With a little playing around, you can easily do this in the template directory once, and then you have the deployment set up correctly
- I need to set a higher PHP memory limit in Drupal's "settings.php" file. I can do it once in the template directory and deploy many sites reliably (read why here and here)
- You need to temporarily change the permission of the "settings.php" file for installation, and create the "sites/default/files" folder before navigating to the Drupal site for the first time. I create them both and make them writable in the template directories
Then, tar and gzip the resulting directory tree. There's one big
trick to this step. You need to make sure you get the .htaccess file, so I include it explicitly:
tar -czf ../drupal-6.10-template.tar.gz * .htaccess
There's a reason I don't just tar the template directory. That would give me a tar file that would create a directory and expand into it. On my hosting service, it's more convenient for me to expand into the existing "public_html" directory.
The other "trick" isn't so much a trick yet, as it is thoughts on running several Drupal sites from one installation. It seems to be a Drupal pattern to create "multisite" configurations where you have sub-domains running from the same Drupal source code (PHP files), but with different databases, and different configurations and themes.
This sounds good, and you would only have to update the files once for all your sites. However, I think it also causes some problems:
- The technique for Drupal multisites that I found gives you a circular symbolic link in the sites directory hierarchy. I believe this causes problems when I try to copy the site prior to upgrading it (I copy to have a backup)
- The recommended Drupal upgrade procedure requires that you take the site offline, disable all modules, and then re-enable all modules after you upgrade. That means all your sites are offline for the entire upgrade, rather than being able to do each site quickly
With the template approach, the pain of uploading the files is gone. The rest of the work you have to do for each site anyway, so it becomes almost the same amount of work to just run each site as a completely independent Drupal installation.
I'm going to try my template based upgrade and will post about the experience then.