Drupal Website Maintenance: Scenarios and Best Practices

Submitted by Doug Addison on .
Drupal Superhero

Earlier this year, Drupal developers patched seven vulnerabilities in versions 7 and 8 of the content management system platform (read more on ZDNet). If you’re a user of Drupal, and especially if you’re responsible for administering Drupal, this may have caused some big concerns for you about your website’s security. If you are overseeing regular website maintenance, then you may want to create a list of what to check to protect your site. To support this, I’ve compiled a list of some common conditions you might see in the administrative interface of your Drupal website CMS that require a response.

Drupal module security update message

1. Drupal Module Update

When an update is available for an installed Drupal module, you want to quickly address it, especially if it patches a security issue. Keep in mind that Drupal uses color-coded system for messages:

blue=informational, green=good, yellow=might need attention, red=warning or urgent update. The red message you see above says that there are urgent security updates to contributed modules.

Drupal security update message

2. A Drupal Core Update is Available

As we’ve seen twice already this year, Drupal core has occasionally been shown to have vulnerabilities that hackers can exploit. When that occurs, updates from the Drupal security team should be applied as soon as possible. This shouldn’t be expensive, though we recently got word through a client of another Drupal website development agency quoting an absurd $2,500 to run the most recent security update. An experienced Drupal developer should be able to do these updates inexpensively, in a couple of hours or less.

3. Drupal Error in a Module

You may see a notification that a Drupal module is producing a syntax error. This is an error in the way the software code is written that prevents it from executing properly. Because Drupal’s main scripting language, PHP, has evolved quickly in recent years and coding standards change with it, some contributed modules may be out of date. If the creator of the module has not kept up, the module might produce warnings visible to admins or even regular visitors. While it is often ominous looking, the syntax errors are most often innocuous and not normally a security threat. Check the module’s issue queue on drupal.org to see if a solution has been posted.

Drupal unexpected error

4. Fatal Error, Database Down, Database Unavailable

In these scenarios, something is obviously wrong and your site will likely manifest this in one of two ways:

Scenarios that can lead to this include a database error (duplicate primary key inserts, etc.), a problem with database credentials, the database is down or unavailable, a module is occurring twice in the codebase, or another fatal syntax error in the code.

Drupal syntax error

Best Practices and Website Maintenance Tools

It’s not enough to simply recognize there is a problem. You need a strategy for preventing these issues that can expose your organization to potential security threats. These are some best practices for website maintenance I recommend, including some helpful tools.

Drupal 8 Status Report

  • Make sure the Drupal update manager module is enabled and on. “The Drupal Update manager module “periodically checks for new versions of your site's software (including contributed modules and themes), and alerts you to available updates”(Drupal). Set up a software utility that is a time-based job scheduler and have it regularly running.
  • Set up email notifications about Drupal Security Updates for the person on your team who knows what to do in case of a problem.
  • Check the status page regularly (under Reports) - once every week or two, and after any core or module updates.
  • If you’re having problems, make sure the blog and syslog modules are enabled. They might be disabled as is recommended for production sites, so just enable them temporarily. One school of thought is that live/production Drupal sites should run as lean as possible. Drupal modules that log to the database constantly or provide an admin UI should be left disabled to reduce memory usage and improve site performance.
  • For the more technical user: If you have shell access to your server and Drush installed, then you can use ‘drush ws (watchdog show) to see the latest entries to the error log. This is particularly helpful when the site itself is unavailable. Other very handy Drush commands that can often unstick a site or reveal a hidden error are ‘drush cc’ (clear cache) and ‘drush rr’ (registry rebuild).
  • Some website hosting environments have particular restrictions on php file permissions or apache web server configuration. If you have access to your server’s error log (via the cPanel or otherwise), review it for clues to the cause of severe errors like a “white screen of death.”