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 🙂
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.
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 Drupal.org 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 Drupal.org.
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.
'foo',
// This is okay because of hard-coded site configuration.
'bar',
);
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.'
);
}
}
}Conclusion
I’m sure there will be a few more hiccups along the way, but this should get you started.
Image by: Henri Bergius