Category Archives: drupal

Drupal: Lather, rinse, repeat – Cleaner development with installation profiles and Makefiles

I’m beginning to really like Drupal, a PHP-based content management system. Working with Drupal feels almost like working with Emacs because of the number of hooks that people have designed into the system. =) So here’s a Drupal tip for fellow newbies.

When you’re developing a site in Drupal, it’s a good idea to make sure that you can reproduce your setup on a different system. One way to do that is to periodically do a fresh install of Drupal with your modifications, and see if everything still works.

For example, on my system, I have an installation profile that enables and sets up Drupal the way I want. I also have a script that deletes and recreates the database, then restores the default settings.php. To refresh my system, all I have to do is type “make clean”, then open my Drupal site in the browser. After I specify the installation profile for my project and the database connection details, Drupal sets everything else up. Because I use installation profiles and source code control (svn on this project), I can commit my changes, update the copy on the test server, and easily reproduce my system there. Using installation profiles saves me the time that I would’ve spent setting up and configuring all the modules (and in the right order!), and this practice can help you too.

Here’s how to get started:

  1. Make a copy of sites/all/default/settings.php before you configure your system, or get the settings.php from a clean (never-installed) Drupal directory. I like putting this copy in sites/all/default/settings_default.php.
  2. Create an installation profile for your system. The easiest way is to use the install_profile_wizard module to generate a base installation profile, then modify it as needed. Put this profile somewhere in your profiles directory.
  3. Create a Makefile, shell script, or batch command that drops the database you’re using, recreates the database (granting any permissions necessary), and copies sites/all/default/settings_default.php to /sites/all/default/settings.php

Then, when you’re developing code, you can just call your Makefile/script/batch command to start from a (relatively clean) database.

Lather, rinse, repeat.

Drupal: Adding lines to settings.php in an installation profile

Installation profiles can make it easier for you to test and reproduce your configuration. But what if you need to do more than what Install Profile Wizard detects? For example, parts of the Domain Access module ask you to add lines to your sites/default/settings.php. Fortunately, PHP allows you to set up your install profile to write to files during installation.

Here’s the code I added to the end of the profilename_profile_final() function:

    // Add the following to the end of settings.php
    $file = fopen("sites/default/settings.php", "a");
    if ($file) {
      fputs($file, "\$cookie_domain = '';\n");
      fputs($file, "require_once './sites/all/modules/domain/domain_conf/';\n");
      fputs($file, "require_once './sites/all/modules/domain/domain_prefix/';\n");
    } else {
      drupal_set_message("Can't add domain-related lines to sites/default/settings.php");

Hope it helps!

Notes on backporting modules from Drupal 6 to Drupal 5

I needed a web statistics module for a Drupal-based project at work, and integrating an external web statistics module seemed to be the way to go in terms of performance and features. BAWstats integrates the popular AWstats web statistics analyzer into Drupal. The module was developed for Drupal 6, so I spent a few hours backporting it to Drupal 5. I don’t know if I can send a patch back (might have to do some paperwork), but anyway, here are some notes so that (a) I can remember how to do this in the future, and (b) it might save you some time.

Backporting from Drupal 6 to Drupal 5: Change the menu items

  • Move the menu path from the array key to the path attribute.
  • Rename

    page callback to callback and page arguments to callback arguments.

  • Remove the file and file path attributes. Move the included files to include_once lines for now, and look for instances of include that need to be changed to include_once. Read the included files to check for unintended execution.
  • Change tokenized menu items (%/%/%) to ones that dynamically build the menu path (arg(1) . ‘/’ . arg(2) . ‘/’ . arg(3)). Don’t forget – this shouldn’t be cached.
  • Change 'access arguments' => array( to 'access' => user_access( or something similar.

Those were most of the changes I needed to make in order to backport bawstats to Drupal 5. Seems to work so far… =) More notes when I run into other things!