"I have an older version Drupal site and I feel stuck between a rock and hard place..."

"Official support status" for various versions of Drupal core:

So, official Drupal.org policy is no support for more than one version back. Many Drupal developers/shops have the same policy as Drupal.org itself - no services, development, or maintenance for legacy Drupal versions.

In a perfect world free of money and time limitations, the benefits of staying with the most current version of Drupal make enough sense. However, the reality is that there are practical reasons to try and stick it out with an older site sometimes. These reasons can include (but are probably not limited to):

  • Older sites which are merrily chugging along. For these sites "upgrading" or "migrating" simply translates into having to paying big money just to have the same exact site they have now, only with a newer Drupal version number next to it.
  • Older Drupal sites of such customization, scope, and/or scale that upgrading them would be unmanageable in the near term. I worked on such a site for 4 years. With over 30+ custom coded modules (not just downloaded modules from Drupal.org), upgrading to a new version of Drupal would have taken hundreds if not thousands of hours.

Drupal project lead, Dries Buytaert, recently called for more developers to go after niches within the Drupal ecosphere. I believe serving users of older Drupal sites could be a valuable one to some Drupal users, as well as to the Drupal project itself.

As a fan of older Drupal versions and as someone who has spent a lot of time working with them (and yes, plenty of time working with newer Drupal versions), I'm throwing my hat into the ring to try and assist these particular Drupal users. If you have an older Drupal site (or know someone with one) which needs development, support, maintenance, or server administration drop me a line.

9 November, 2009

Comments

Drupal 7 hasn't even matured yet. The strides and comfort D6 had was that it was such an improvement over D5, that everyone wanted to be on it. As such, modules converted quickly and new ones popped up fast, there were many contributions. It stabilized and matured, and lasted 2+ years. You could count on it.

When D7 arrived, many people switched again, feeling that level of comfort. Some early adopters got bit in the ass hard. And now, before D7 even hits its plateau (things like Pathauto, Token, etc don't even work 100% with non-core Entities yet, along with auto updating modules from the admin is still busted), D8 is almost out. A lot of contributors are focusing only on D8 and left D7 behind.

So what is an average user to do? Pick D7 and find they may be in the dark without much support, or pick D8 that isn't finished, and has a more advanced API (which may take longer to port modules) and unproven formula?

The rush to get D8 out is a major mistake. With all the issues and bugs still filed, it seems that the focus is on the type of the issue (critical, major, minor) instead of the overall platform. The administrative UI is still clunky for the average person, the core theme is not great (if they did not select Bootstrap, Foundation 3, or Omega- I won't be surprised), and the support/integration of external data into core is still lacking. I would have shot for Q2 2013 at a minimum to give the contributors more time to finish their initial ideas, work on bugs, and go through reviews.

The best parts of D8 I've seen so far is the move of configuration to text files, the desire to implement Twig (and hope to god improve the theme system- jesus its complicated) and reduce the page requests.

There are a lot of great initiatives for D8 don't get me wrong- but they don't feel finished in the least. They may work, technically, but then again, so did D7- and it took over a year for people to even consider using it.

The single best move that can be made (in my opinion) for D9 is to scrap all old code from D4-D8 that is still lingering in the core, and make Drupal eat its own dogfood. That means, all data structures it implements need consistent implementation with its entity api, and the integration of EntityAPI itself (contrib) as well as define a consistent agreed upon implementation of a data structure. That said, Node etc become modules- and I think they already did that. However, along with that, destroy all code that maintains backwards compatibility for whatever reason- and stabilize the platform so that moving forward is guaranteed instead of a mystery. Solidify the APIs, and incorporating Migrate as an upgrade tool rather than writing ridiculously long and convoluted scripting routines or using Featuers etc would also be very welcomed.

Releasing fast is pointless if your users don't want to come along for the ride.

I would have shot for Q2 2013 at a minimum to give the contributors more time to finish their initial ideas, work on bugs, and go through reviews.

You realise the projected, earliest release date for Drupal 8 is August 2013, i.e. later than your minimum? And it's been that way for a long time.

All the core devs tweeted Xmas 2012 release like, last week.

That I find hard to believe here is the release schedule that was updated on 7th September this year http://buytaert.net/updated-dr.... We are just coming up to a feature freeze on the 1st December.

"all the core devs" rarely agree on stuff.

Examples, please :)

I imagine that a lot of them tweeted about the feature freeze, but that is not a release date.

They may work, technically, but then again, so did D7- and it took over a year for people to even consider using it.

No, this is incorrect.

Drupal 7 was released in January 2011, and you can see from http://drupal.org/project/usag... what the usage statistics a year after that looked like.

I have yet to work with a client that is on Drupal 7. Drupal 6 happened to coincide with an increase in Drupal popularity. Companies have invested a lot of time and money into D6 sites that are meeting all current needs. Drupal has matured to the point that much of the development is now focused Drupal innards that won't mean much to a lot of end users. The only difference non-dev folks talk about in D7 is the revamping of the admin interface.

D6 is very powerful. I really enjoy working with it and so do my clients. D7 adds features like a more abstracted (and flexible) DB interface and the new (and potentially very powerful) entity API. But I would consider these advanced features that most developers won't take advantage of.

The only reason these companies will feel compelled to upgrade to 7 or 8 will be that 6 is no longer supported (not because it no longer meets their needs). That's a pretty lame reason.

I don't blame Drupal for wanting to forge ahead and focus its efforts on improving Drupal rather than getting stuck maintaining old versions. But there's going to be an increasing demand for 'legacy' support for older Drupal versions that some company might be wise to take advantage of.

Drupal's not just for startups creating sites that will only be around for 18 months. Some of these sites stick around a while. The company that's willing to offer legacy support services for Drupal will have a sustainable business model, IMHO.

I agree there is a market for the kind of thing described in this blog post, but the tricky question is: How to handle security issues? Are the owners of these older sites willing to have their security issues fixed in public (as would normally happen for software that is no longer supported)? Or would the idea be to set up some kind of "Drupal security team for out-of-date versions" that handles this kind of thing in private? The latter might be possible but would require a lot of work to coordinate.

This is especially important because for most of these sites, I would think that security fixes are the main thing they care about at this point. (By definition they are not adding major new features, and they've probably already dealt with or worked around whatever bugs they faced also.)

Drupal 6 is going to be out and officially supported for 5.5+ years. D7 is likely to have a similar timeframe of support. If the site gets upgraded every *other* version then it has to upgrade once every ~10 years. What kind of website doesn't see a major overhaul every 10 years?

Also, I think David's comment that security is the most important element here makes sense and it never ceases to amaze me that most of the people calling for this support are not currently part of the security team (nor doing work to support the team). For info on how to support and/or join see http://drupal.org/security-tea...