How do I manage the security of my Drupal 6 site?

In our last post we talked about how the Drupal Community is supporting Drupal 6 after its end-of-life and what that means for your Drupal 6 site.  In this post we’ll get a bit more technical and talk about what exactly you need to do to keep your website up to date.

Step #1: Getting an accurate report of your site’s modules and themes

Ever since the Drupal 6 sunset date, your website’s report of Available Updates at /admin/reports/updates has been telling you that everything is unsupported and should be uninstalled.  That’s not very helpful 🙂

Drupal 6 Update module report

So the first step is to get the myDropWizard module.  This is provided free (libre) to the Drupal Community by one of the Drupal LTS vendors. The main purpose of this module is to show whether a module is supported by the Drupal 6 Long-Term Support (LTS) vendors, so you’ll know if it’ll be getting security updates going forward.

Drupal 6 MyDropWizard report

Ahhh, that’s better.

Now you can continue to manage security updates for modules and themes just like you always have.  But there are some significant gotchas.

How problems are found and fixed

When vulnerabilities are found they will be posted as issues in the Drupal 6 LTS project.  Once the issue is  fixed, and if the module maintainer is still maintaining the D6 version, then the maintainer will simply release a new version, just like normal.  But if the maintainer is no longer maintaining it, then new releases are made on Github.  Drupal Core is no longer receiving any new commits on the 6.x branch,  so new releases will be made to the Pressflow project, also on Github.

How to obtain new versions

If new releases are scattered across and Github, the question becomes: How do we easily obtain new versions?  Assuming that you run security updates with Drush, then you can use the --update-backend=mydropwizard flag when calling any of Drush’s Project Management commands (pm-download, pm-refresh, pm-updatedstatus).  The MyDropWizard backend will automatically obtain the project from Github or

New Drush

But this brings a new problem: The --update-backend flag only works with Drush 7 or later.  On a server that’s running Drupal 6, chances are high that it’s using Drush 6, and chances are also high that it’s using an old version of PHP (like 5.3.3 that is bundled with Debian/Ubuntu).  The old version of PHP means that you can’t upgrade to the latest Drush 7 (7.2.0).  But there’s a fix on the way for that.

Switching to Pressflow?

Since new releases are no longer made to Drupal Core, and only to Pressflow, this creates a bit of a dilemma for sites that are not running Pressflow.  In those cases it’s probably more cost effective to manually apply patches rather than move to Pressflow.  There’s a couple ways to be notified of these commits:

Add-on modules

The final tricky area that we’ve found is with modules that extend Update Status module. There’s two in particular that we use often: Update Exclude Unsupported, and Update Status Advanced Settings — neither of these will work anymore.  Instead you’ll need to implement hook_mydropwizard_status_alter().

 * Implements hook_mydropwizard_status_alter().
function mymodule_security_mydropwizard_status_alter($projects) {

  // Projects determined to be okay for this particular site.
  $projects_deemed_okay = array(
    // This is okay because of the finglewabble.
    // This is okay because of hard-coded site configuration. 
  foreach ($projects_deemed_okay as $module) {
    if (isset($projects[$module])) {
      $projects[$module]['status'] = 'deemed-okay';
      $projects[$module]['extra'][] = array(
        'class' => 'deemed-okay',
        'label' => t('Deemed okay'),
        'data' => t('This project was analyzed and determined to be acceptable to run on your site.'


I’m sure there will be a few more hiccups along the way, but this should get you started.

Image by: Henri Bergius

8 Responses to “How do I manage the security of my Drupal 6 site?”

  1. Eelke on

    What makes you say that monitoring patches will be a better approach for sites on vanilla D6 than moving to Pressflow? I was under the impression that making the switch is not that involved in many cases.

    • Dave Hansen-Lange on

      I’ve done several migrations from vanilla D6 to Pressflow 6. On average they take about 4–6hrs. That’s probably more time than it will take to apply the occasional patch.

    • Dave Hansen-Lange on

      Yeah, that’s my experience for about 80% of the sites where I’ve made that transition.

      The trickier part is usually that an old D6 site is likely using SVN rather than Git (and sometimes with full Git checkouts stored in SVN), so the tricky part becomes making that transition in the repo.

  2. David Snopek on

    Also, regarding Drush 7.2.0 – until that bug is fixed, you can simply use Drush 7.1.0 which still works with PHP 5.3, which is what we’re using for any of our customers who are stuck on older versions of PHP.

  3. Norbert on

    MyDropWizard is definitely helping to keep me sane! I have upgraded to drush 7.3.0. When I use drush upc –update-backend=mydropwizard, it reports a bunch of modules as not supported Even though the installed and proposed versions are identical. drush updates them. Is there a way of blocking this without locking all the ‘not supported’ modules?

    • David Snopek on

      The ‘not supported’ status is actually one of the most valuable things that the myDropWizard module provides! It tells you that the D6LTS vendors don’t support those modules, and so even if there is a security issue, a patch and update won’t be released. (If you want to get all your modules supported, you’ll need to sign up for a D6LTS plan with one of the vendors).

      That said, drush’s behavior in this case is annoying! I looked through the command line arguments for ‘drush upc’ and at the API we have access to in the mydropwizard module, and I can’t see any “easy” way to change this behavior.

      You could open an issue with drush to check that the version numbers are the different before updating? Or you could open an issue with mydropwizard to make a “mydropwizard-supported” update backend that always reports that modules are supported (as a hack)?

    • Norbert on

      David, thanks for the detailed response and confirmation that I am not missing something obvious. I will explore your suggestions.