A Drupal 6 site keeps working, but no more security fixes will come for it or its modules. Plan a rebuild on a current system now, using paid long-term support only to bridge the gap.

What ended yesterday

Yesterday, Wednesday, Drupal 6 reached the end of its life. The Drupal project's security team no longer fixes problems in it, or in the modules and themes written for it.

Nothing switched off. Drupal 6 sites loaded this morning exactly as they did on Tuesday, and most will keep doing so for a long time.

What changed is what happens the next time somebody finds a flaw. For Drupal 7 and Drupal 8 there will be a fix. For Drupal 6 there will not.

Drupal 6 came out in 2008, and plenty of association, club and small business sites built between then and about 2011 still run on it.

What end of support means in practice

The second is the one owners underestimate. A typical Drupal 6 site runs dozens of modules, each with its own record of security fixes, and every one of those records stopped yesterday too.

Why waiting is the risk

Attackers rarely choose sites. Automated scans find them, looking around the clock for known versions of popular software.

Drupal 7 shares a good deal of its code with Drupal 6. From now on, when a flaw is fixed in 7, the published fix shows where to look in 6, and the project will not close it there.

What follows a break-in is usually dull and damaging: spam pages added to the site, phone visitors redirected elsewhere, or the host suspending the account until it is cleaned.

None of this is likely tomorrow. The risk grows month by month, and a site with logins or members' details carries more of it.

PHP is the second clock

Drupal 6 was written for versions of PHP, the language the site runs on, that are themselves past their end. PHP 5.3 and 5.4 no longer get security fixes.

Hosts are moving accounts to PHP 5.6 and 7.0. Many Drupal 6 sites will not run on PHP 7 at all, and some throw errors on the newer 5.x versions.

So a Drupal 6 site either holds its hosting account back on an unsupported PHP, or breaks when the host moves on. The decision arrives whether anyone plans it or not.

The realistic choices

There are three, and doing nothing is not one of them.

Rebuild on a current system: Drupal 7 or 8, or another current platform such as WordPress for a simpler site. The content comes across; the design and most modules have to be redone.

Pay for long-term support while the rebuild is planned. The Drupal security team has approved a small number of companies to keep publishing fixes for Drupal 6 and some popular modules, for a fee. That buys time, not a future.

Or freeze the site. For an archive that never changes, a static copy with no logins and no admin area removes most of what can be attacked, with any form handled separately.

A worked example

A tanning salon with two locations has a website built on Drupal 6 in 2010 by a developer who has since moved away. It has twelve pages, a price list, a gallery and a contact form.

The owner heard about the end of support this week and asked what it meant for a site that seemed to work perfectly well.

A look underneath found thirty modules, several untouched since 2012, a hosting account held back on PHP 5.3 for the site's sake, and a contact form that had been sending spam for months.

Long-term support would have meant a monthly fee to preserve a system far more complicated than the salon needed, still tied to old PHP.

The salon chose a rebuild: the same pages on a current system, a price list staff can edit themselves, and every old address redirected to its new equivalent.

Until the new site launched, unused modules were switched off, the admin accounts were cut to one, and backups ran daily.

Get the keys first

Many Drupal 6 sites have outlived the relationship with whoever built them. Before any decision, collect what the next developer will need.

The hosting login, the domain registrar login, an administrator account on the site and access to the database. Plus a full backup of the files and the database, stored somewhere other than the server.

If any of those cannot be found, finding them is the first job. A rebuild planned without them stalls on the day it starts.

What a rebuild involves

Start with an inventory: every page, every type of content such as news, events or members, every form and every file people download.

Then list the addresses. Old pages have links from other sites and places in search results, and each needs a redirect to its new home so neither is lost.

Drupal 8 includes tools for importing content from Drupal 6, though themes and many modules have no direct equivalent. Moving to any current system is a rebuild with the content carried across, not an update.

Leave time to test the forms, the redirects and the site on phones before the switch.

The counter-case

Not every Drupal 6 site is in the same position. A small brochure site that nobody logs into and that rarely changes is a lower risk than a members' site holding personal details.

A large site with many custom modules may sensibly sit on paid long-term support for longer, while a careful rebuild is planned and built.

And a site already due for replacement this year can bridge to that date, provided the date is real.

Whichever applies, the direction does not change: plan the move now, and do not leave a Drupal 6 site running unsupported indefinitely.

While the site still works

  1. Confirm the version with whoever maintains the site.
  2. Back up the files and the database off the server.
  3. Collect every login the site depends on.
  4. List the pages, forms and modules in use.
  5. Switch off modules and accounts nobody uses.
  6. Choose rebuild or long-term support by a set date.
  7. Redirect every old address when the new site launches.

Step six is the one that keeps the others from drifting. Without a date, a site that still loads every morning stays on Drupal 6 for years.

If the rebuild lands on WordPress, how its current version handles images on phones is covered in responsive images arrived with WordPress 4.4.

Frequently asked questions

What happened to Drupal 6 yesterday?

It reached the end of its life. The Drupal security team no longer fixes flaws in Drupal 6 or in the modules and themes written for it.

Will my Drupal 6 site stop working?

Not by itself. It keeps loading as before. What stops is security fixes, and the site may break later when the host retires the old PHP it needs.

How do I know which version my site runs?

Ask whoever maintains it and get the answer in writing. A file called CHANGELOG.txt in the site's main folder often names the exact version too.

Is moving to Drupal 8 a simple update?

No. Drupal 8 has tools for importing Drupal 6 content, but the design and most modules must be rebuilt. Treat it as a rebuild with the content carried across.

What is long-term support for Drupal 6?

A paid service from a small number of companies approved by the Drupal security team, which keeps publishing fixes for Drupal 6 and some modules. It buys time.

Does a small brochure site need rebuilding?

Yes, though with less urgency than a site with logins. It still depends on unsupported code and old PHP, so plan the move rather than waiting.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Still running a Drupal 6 site?

Send us the address. We will confirm the version, list what it depends on and price a move to a supported system.

Start a Conversation