by David Snopek on January 3, 2019 - 12:34am

As you may or may not know, we've been providing Drupal 6 Long-Term Support (D6LTS) since February 24, 2016, as one of two vendors officially blessed by the Drupal Security Team to do so.

In that time, we have made 99 releases (both Drupal core and contrib) for D6LTS!

Most of those were security releases, but there were also a handful of bug fixes, and most recently, updates to support PHP 7.2(FYI: As of a couple days ago, PHP 5 has also reached it's End-of-Life (EOL) - do you have a plan to update to PHP 7.1 or 7.2?)

When we were first talking to potential customers about D6LTS, I remember many people doubting that we'd be releasing anything at all!

They'd say something like "Drupal 6 has been around so long, aren't all the security issues shaken out by now?" Almost 100 releases later, and I'd say there was plenty to be done. There still is! :-)

In this article, I'm going to look back on Drupal 6 LTS, and also look forward to what that may mean for Drupal 7 extended support after it reaches its End-of-Life.

Lessons learned from Drupal 6 LTS

We learned many unexpected things from doing Drupal 6 Long-Term support over the last few years, which I suspect will continue to apply to Drupal 7's extended support.

The age/visibility of the code doesn't matter

This should have been obvious by looking at other Open Source projects. Many of the recent vulnerabilities found in OpenSSH (a hugely visible project, used by almost every Linux server on the planet) were introduced many years before anyone noticed (in one case, it took almost 20 years).

So, it doesn't matter that Drupal 6.0 was released almost 11 years ago - odds are, there are still some security vulnerabilities in there.

Looking at the projects we released the security updates for, the most common were also the most widely used, for example:

  • Drupal core: 4 security releases
  • views: 4 security releases
  • xmlsitemap: 2 security releases

These highly popular projects have gotten the most scrutiny, but that hasn't meant there aren't more issues to find.

This is especially true of Drupal core, which is independently audited several times a year by security companies hired by large organizations to evaluate their sites. (BTW, this is a great source of security issues reported to the Drupal Security Team.)

I suspect this will continue to be true for Drupal 6 and Drupal 7: we'll keep finding security issues for years to come.

Many issues affected Drupal 6, 7 & 8

Despite the fact that each major version of Drupal up to this point included breaking changes, and Drupal 8 could almost be considered a "rewrite", many security issues affected Drupal 6, 7 and 8, both in Drupal core and contrib.

In the case of the Highly Critical SA-CORE-2018-002, which came out in the Spring of 2018, all three versions (6, 7 & 8) - and even Drupal 5 - were affected!

The code fixes for each version of Drupal were quite different in some of these cases, but the shared history, and the test-driven of evolution of Drupal 7 into Drupal 8 has meant that many bugs (including security bugs) have been preserved.

Even as we move towards Drupal 9 (which is removing and re-organizing even more legacy code), I suspect we'll continue to see security issues in Drupal 9 or 10 that also affect Drupal 6 or 7.

Keeping up with PHP is going to be a thing

After PHP 5.3, there was a relatively long period where not that many breaking changes were introduced to PHP -- so long as you stayed with PHP 5. But now that PHP 5 has reached its End-of-Life, you can't stay on PHP 5 any longer.

PHP 7 has also entered into a regularly scheduled cycle of releases, and each release is making more aggressive deprecations and breaking changes. Many Drupal projects are just switching to PHP 7 now, but at some point PHP 8 will be released and remove all those deprecated features.

Keeping up with changes to PHP is going to be a thing that we'll have to constantly think about now -- in Drupal development in general, but especially for any Long-Term Support effort, whether that's Drupal 6 or 7.

What does that mean for Drupal 7's extended support?

As we've mentioned previously, we plan to offer commercial support for Drupal 7 after its End-of-Life, that will be very similar to what we've done for D6LTS.

And, as per the lessons above, we also expect that extended support will be essential for anyone who intends to remain on Drupal 7 after its End-of-Life!

The most important difference this time around is that Drupal 7's End-of-Life has been announced years in advance. This a huge change from the Drupal 6 EOL, which was "coming any day now" (along with Drupal 8) for 2-3 years, and then happened suddenly with only 3 extra months of support.

So, you have a lot more time to plan, but also, you have something concrete to plan for: Drupal 9 will be out for a year before Drupal 7's EOL, and intention is for the upgrade from Drupal 8 to 9 to much easier than previous major version upgrades - on par with upgrading from Drupal 8.5 to 8.6 (well... hopefully ;-)).

That said, if you do wish to stay on Drupal 7 for some time after its End-of-Life... I think D6LTS has shown that commercial extended support can work, and what that will probably look like.

Want to read more articles like this?

myDropWizard.com blog Subscribe to the myDropWizard.com blog and recieve e-mail updates when new articles are published!

Comments

Great article with some insight as we look back at the past. The evolution of PHP is certainly the big concern for Drupal, and all PHP based projects.

But what about jQuery? Drupal 7 ships with jQuery 1.4, which was released in Jan 2010! The jQuery_update module's stable release gives you version 1.10, that was released in 2013. Lighthouse audits always list vulnerabilities for jQuery in their performance reports.

Will jQuery be another big concern for keeping D6 and D7 sites alive in the future?

That is a really great point!

jQuery has occasional security issues, and is used by lots of other libraries that may have security issues, whose updates may need newer jQuery versions, etc.

This hasn't been a huge deal with Drupal 6, because jQuery isn't used all that much outside of some complex admin UIs (I'm thinking about Views and Panels) but will likely be a bigger deal with Drupal 7!

We probably can't update the jQuery used in Drupal core (even in LTS) but maybe the answer is to continue updating jquery_update, so that sites can choose to go to a newer jQuery? That'll probably also require updates to contrib to be compatible with both the newer and older jQuery.

Anyway, this is definitely something to keep in mind!

I'd like to get pay other do to D7 LTS support and I'd also like to be paid to do D7 LTS support, when is Drupal.org going to support crowd funding , bit coin tipping type shopping cart? This is something that we could build using Drupal commerce modules.

With D6, there was no alternative for LTS, so I imagine that releases focused on security issues and php7 compatibility ...perhaps also some major/critical bug fixes too?

With D7LTS, have you considered Backdrop CMS, which is a drop-in replacement for D7? As a member of that community, I would like to extend an invitation to discuss possibilities of working together towards that. We have been working on Backdrop for 5 years now, and besides security fixes, we have been doing a great work on providing new features on a regular basis (new minor/feature releases every 4 months - ), fixing UX issues and improving the out-of-the-box end-user experience in general.

One of the latest features you might be interested in, which will be included with the upcoming 1.12.0 release in a few days on Jan 15, is the ability to perform core updates via the admin UI! The end goal is to allow for (optional) automatic security updates (once the feature has been battle-tested enough), in the hope to have less hacked "abandoned" D7 sites.

I think that it would be a great option to offer to D7 customers seeking LTS:

- Most of the popular 7.x contrib modules have either been integrated (not just merged) into Backdrop core, or already ported: https://github.com/backdrop-contrib, or can easily be ported.

- Modules already merged in core for better out-of-the-box user experience: Admin Menu, Views, Views Bulk Operations, Pathauto, Token, Redirect & Global Redirect, Entity API, File Entity, CKEditor, Transliteration, Ctools, Date/Link/Email fields, and more: https://backdrop-ops.github.io/slides/intro-mini.html#/20

- We have been keeping jQuery/jQuery UI up to date (currently on 1.12.4 and 1.12.1 respectively, and looking to upgrade to jQuery 2.x and perhaps even to 3.x at some point). We also have a commitment to keep other 3rd party libraries like CKEditor up to date.

- We have made hundreds of UX fixes/improvements: https://github.com/backdrop/backdrop-issues/issues?q=is%3Aissue+sort%3Au... ...with 100s more down the pipeline: https://github.com/backdrop/backdrop-issues/issues?q=is%3Aissue+sort%3Au.... These do not have to wait for the 4-month minor release cycle, as they are allowed to be included in the bug fix releases (as often as deemed necessary).

Since MDW seems to be after LTS for D7, which is practically what Backdrop CMS is about, it would be silly not to make a joint effort :)

I think it's great to have Backdrop around as an alternative! I'm always impressed by the work that the Backdrop community does, and all the cool, new stuff that keeps getting added. :-)

And the Drupal 7 End-of-Life will be an interesting "test" of the foundation of Backdrop. When Drupal 8 was first released, there wasn't really any pressure to upgrade, and also a lot of uncertainty about what Drupal 8 will eventually grow into (both the core code, and contrib from the community). But when the community stops supporting Drupal 7, and those site owners are forced to decide between (a) Drupal 8/9, (b) Drupal 7 extended support, (c) Backdrop, or (d) moving to some other platform - will they find option (c) compelling in large numbers?

Anyway, I don't think Backdrop is a complete replacement for extended support or LTS for Drupal 7. While I haven't migrated a Drupal 7 site to Backdrop myself, I believe the hype that it's easier to do than migrating to Drupal 8. But my understanding is that you still have to do some kind of migration process, and possibly port a couple modules that haven't been ported, and maybe update your custom code. For some site owners, staying on Drupal 7 with extended commercial support may be preferrable to all that disruption - it's an additional cost, but everything just keeps chugging on as always with no changes.

Perhaps Backdrop will be less compelling to the people to are considering buying LTS for Drupal 7, and more compelling to those who have some technical expertise but can't afford to buy commercial support at all? I don't know if that's true, I'm just brainstorming theories. :-) My point is just that I think both Backdrop and commercial long-term support have a place in "the market" that doesn't necessarily fully overlap (I'm picturing a venn diagram).

That said, we're here to support Drupal site owners, and we plan to keep listening to the community and their needs. There's a long time between now and the Drupal 7 End-of-Life, and if it becomes clear that helping folks move to Backdrop is something that makes sense for them and us, then we'll start getting involved in Backdrop migrations. ;-)

Add comment

o