When Your CMS Reaches End of Life

End of Life (EOL) in the CMS world refers to the point in time when an older version stops being supported by the company or community that has built it, and all efforts are focused on current and future versions. No support means performance, and more importantly, security issues, which nobody wants.

As a web host, we see our fair share of EOL CMS usage. While we often make our own patches to keep outdated client websites secure and in other cases we notify them about issues, it really is the application’s responsibility. We can’t possibly keep track of every outdated software we host and every security vulnerability that comes with it. Hence, here is more about what to do when your application becomes outdated and no longer supported.

When is it EOL?

Every CMS has its own development cycles and thus EOL strategies. Even among the free platforms that most of our clients use – Drupal, WordPress and Joomla! – there are observable differences.

At the beginning of this year, 3 months after Drupal 8 came out, Drupal announced the end of support for version 6. Drupal 7 and 8 are currently both supported and it will probably be a while before we see version 7 dropped. Drupal is notorious for longer development cycles and harder updates between versions, hence the longer support cycles. Drupal 6 for example, was in support for about 8 years.

WordPress and Joomla, on the other hand, are quite different in this aspect. The WordPress release archive states that only the latest version is safe and actively maintained, and the Joomla! version guide says pretty much the same thing. Given the much easier update processes of WordPress and Joomla!, it makes sense for them to focus efforts on the latest versions only.

Upgrading is Best, But Sometimes Hard

Of course, no one can argue with the fact that running the latest version of your CMS is the best idea, always. That’s why we’ve worked hard to build our own auto-update tools for WordPress and Joomla!

However, every experienced sitebuilder has run into upgrade issues at one time or another. Even one-click and auto-updates sometimes break themes or plugins, and you then have to spend time restoring backups, debugging and so on. In the case of Drupal, where upgrades are harder and more time consuming, planning and executing an update on a large website can be a very serious development task.

Additionally, some projects simply do not need further development and new features from the CMS (e.g. brochure company sites). They just need to stay secure. When you’ve got hundreds of such websites, upgrading all of them just to stay secure is an overkill.

External Long Term Support (LTS)

When you can’t upgrade for any reason, there are vendors out there that provide their own LTS support for different CMS platforms. One such is Tag 1 Quo, who specialize in Drupal 6 LTS, but have announced plans to move into WordPress soon, starting with versions 4.5 and 4.6.

With Drupal 6, Tag 1 Quo uses a module to collect information about your website. They compare version information with their database of known security issues, and can then provide up-to-the-minute information about your security status. What’s more, some of their plans include patch development, which means that when a given issue affects any of their customers, they’ll work together with the Drupal community to develop a patch for you (they are an official Drupal 6 LTS vendor).

SiteGround is partnering with Tag 1 Quo to improve our user’s security. All of our existing clients can find a discount code on the Resources Tab of their User Area.

Access email sent!

Sign Up For
More Awesome Content!

Subscribe to receive our monthly newsletters with the latest helpful content and offers from SiteGround.

Thanks!

Please check your email to confirm your subscription.

author avatar

Hristo Pandjarov

WordPress Innovations Director

Enthusiastic about all Open Source applications you can think of, but mostly about WordPress. Add a pinch of love for web design, new technologies, search engine optimisation and you are pretty much there!

Comments ( 8 )

author avatar

Davide Masserini

Oct 11, 2016

What about a solution for Joomla and WP??!! I don't get this post.

Reply
author avatar

Kiril Hristov

Oct 13, 2016

Hi Davide, Joomla and WordPress are much easier to update, so keeping them up to the latest version is best. Otherwise, surely there are external LTS providers for them, too. Tag 1 Quo is introducing WordPress support soon, for example.

Reply
author avatar

Steven

Oct 12, 2016

Very cool. Other than the big three (WP, Joomla, Drupal) what other CMS have hit end of life support? Think my XOOPS 1.0 site has hit EOL :-) Thanks! -- Steven

Reply
author avatar

Kiril Hristov

Oct 13, 2016

Hey Steven, any CMS with several versions on the shelf will usually have one that is no longer supported (EOL). It makes sense to focus on new versions and drop old ones as you go. Therefore, all of them hit EOL, eventually.

Reply
author avatar

Best essay writign service

Oct 20, 2016

useful

Reply
author avatar

Jigar Shah

Nov 04, 2016

Agree with you that Upgrading is the best option but it's time-consuming and sometimes hard working process, so (LTS) External Long Term Support is the best way for the site owners. It's cost-effective and easy to manage. Wonderful post with the supportable idea.

Reply
author avatar

Kiril Hristov

Nov 04, 2016

Thanks, Jigar. Cheers!

Reply
author avatar

Ian Macdonald

May 10, 2017

Very true, and I think this underlines the fact that people using a SQL-backed CMS frontend when there is no particular need for such - as when the site content is basically unchanging, or could easily be updated by FTP- ought to think carefully about whether a static site or file based CMS would be a better option. The time this choice bites you in the proverbial, can arrive before the CMS reaches EOL. It can be when a security update creates a conflict with the template/theme in use. Which can basically happen anytime. You are then faced with telling the client that they need a new website, or else a fairly costly theme rework. The client, understandably, thinks you're just trying to 'milk' them for unnecessary work, and says No. So the unpatched site stays up.. and gets hacked. Most of this grief can be avoided by not using SQL-based products, since the majority of hacks are SQL code injections.

Reply

Start discussion

Related Posts