The Time Has Come: Start on your Drupal 9 Update ASAP

Insert your favorite May gif here.

I cannot believe it’s already May 2021. I feel like my concept of time (and space) is so off thanks to everything that’s happened in the last year (and a bit). With another DrupalCon coming and going in lockdown, there was a lot of discussion about Drupal 8 and its end of life that is coming later this year.

I’ve written a bit about the D8 => D9 update in the past and I don’t want to beat a topic to death. BUT look, here’s the deal. There’s a lot of people out there talking about how easy this update is. Like this tweet I retweeted the other day!

OH: I literally can't believe I just upgraded a major version of Drupal in 15 minutes. Incredible!

— Greg Anderson (@greg_1_anderson) May 3, 2021

This is super exciting news! And I’m really happy for Greg and all the other folks out there that have done an easy update. But not all updates will take you 15 minutes. Or rather, the preparation to do your update may be significantly longer than 15 minutes.

I don’t want to sound like Chicken Little (no, the sky isn’t falling) but I don’t want you to wait until November when Drupal 8 finally goes end of life, start to do the update, and have an oh sh!t moment.

There’s a lot of work that can go into a D8 update. Let’s talk a bout a few recent examples.

Why Should You Update

There’s a lot of talk in the community right now about extending Drupal 7 support. Vendors are offering ongoing support beyond the Drupal 7 end of life (which is next year in 2022). This is not the case for Drupal 8.

Drupal 8 runs on Symfony 3.4 which is itself going end of life this year. This means that since security coverage is ending in Symfony 3.4 it is no longer safe for Drupal 8 to rely on Symfony 3.4. We have handled this in Drupal 9 by updating Symfony (so, no issues there). But! This fundamentally means that Drupal 8 must go end of life because its key dependency Symfony is also going end of life and losing security coverage.

No, Drupal 8 isn’t going to miraculously stop working after November 2021 but it does meant that there will no additional security coverage. Will it still be safe to run Drupal in December 2021 or January 2022? Probably? But the farther away we get from that end of security coverage, the more vulnerable you are going to be. Organizations and individuals that look for exploits and vulnerabilities in software will not stop looking for vulnerabilities in Drupal 8 just because it’s gone end of life. That means that if a vulnerability is found in Drupal 8 after November 2021, there isn’t going to be a Drupal Security Team intervention to keep you safe.

The TLDR is that you want to make sure that you are always running the most current version of Drupal. Not only does this ensure you are getting all the incredible feature development happening in the community but that you are also being kept safe by the security team’s ongoing releases of security coverage. To put it in perspective, Drupal 9 came out in June 2020 and since that time (just under 12 months ago) the security team has done ~10 security releases of Drupal 9. Not all of these were “critical” vulnerabilities but roughly half (5) of them were!

If we follow that trend beyond Drupal 8’s end of life, that means (on average) every two months you go, you have an additional critical security vulnerability in your Drupal platform that will not be resolved.

Don’t roll the dice. Make sure you are running D9 before D8 goes EOL. Please!

For the record, as of this writing the first week of May, here are the Drupal use stats. There’s still a LOT of folks running D8.

Incompatible Modules + Content

I recently saw a site that is using the Field Collections module in Drupal 8. For what it’s worth, this module is in such an alpha state that the D8 version isn’t even on the Drupral.org page for the module. That’s super double secret ultra alpha (which for those of you playing along at home is usually a great example of a module you shouldn’t use).

Field Collections is definitely, 100% not Drupal 9 compatible. Ding ding ding! We have a D9 blocker. But now we have an interesting problem…

We can’t just remove the field collection module in this case, because there is content in the database using field collections. We can’t update the field collection module, because there isn’t an update on Drupal.org. We definitely shouldn’t try to manually update field collections to make it D9 compatible. So that begs the question… what the heck do we do about it?

In this case, the right answer branches a little bit.

1. Review the original need for the Field Collections and the content it’s managing. Do you still need this feature?

2. If you do, is there an alternative way to implement it? Chances are the Paragraphs module is a more or less straight replacement for Field Collections. Can we re-implement the existing Field Collection functionality using Paragraphs?

3. If so, the last consideration is migrating the content from the Field Collection into the new Paragraph. Depending on how much content you have, this may be faster to do by hand because writing migrations for contrib entities (like Field Collections and Paragraphs can majorly suck).

4. OH and don’t forget: you are blocked from updating to D9 until you remove Field Collections. But you can’t remove Field Collections until you’ve completed steps 1-3 in this section AND deployed everything AND migrated the production content AND THEN gone back and removed all of the field collections content, configuration, and ultimately the module itself. There’s a high probability that this process will take 2-4 production deployments to complete.

So this? All of this is a great example of something that is a very real example from a functional D8 platform that will take a “fairly significant” amount of work to get into Drupal 9. The actual D9 update (when you finally can do it) should be pretty painless (just like in Greg’s tweet) but the amount of effort to get rid of Field Collections so you can get there? This could be weeks of work.

Deprecated Code

This is the other big thing that will likely block your update to “some degree.” Unless you’ve already started vigorously running scans on your code to find deprecated code, you almost certainly have deprecated code.

Thankfully, MOST deprecations are just straight copy and replace. Some are a bit more challenging. The bottom line is this is going to stop you from updating and you likely have technical debt you don’t know about. I strongly recommend getting Upgrade Status installed in your codebase and running the reports on both your contrib and custom code ASAP. This should very rapidly give you an understanding of:

• what contrib projects are incompatible with D9 and show you if they have an update available that will be

• what custom projects are incompatible with D9 and show you what you need to do to make them compatible

These two data points should prove to be invaluable in the coming weeks and months to help you guide your update.

Remember, at the very least every custom module needs a .info.yml file update to include the new core version requirement line.

Update Blocking Updates

This one surprised me a bit, but it’s one I also ran into. I recently reviewed a codebase that was running Drupal 8 (good) but was nearly 2 years out of date (bad). It was still running Drupal 8.6.x.

Obviously a big part of doing the update is making sure you’re running the most up to date version of Drupal 8 before jumping to Drupal 9. At the time of this writing that is Drupal 8.9.15.

So, double check your platform! See what version of Drupal core you’re running. If you aren’t on 8.9.15 make sure you do that update (and stay up to date over the rest of the year) before you jump to 9.x. If you’re running an earlier version of Drupal, make sure you are doing those updates and thoroughly testing them. You aren’t going to have an “easy” or “good” experience jumping from Drupal 8.6.x to Drupal 9.2.x.

In Conclusion

Remember, the D8 => D9 is the easiest Drupal update basically ever. The reason I can say that? Always before you had to totally rebuild your site! So if our comparison is “totally rebuild” vs. “just about anything else” the anything else is going to always be easier. But that’s a pretty low bar.

Make sure you take this update seriously and have a look at your platform. I do genuinely think “once you’re ready” to do the update it’s going to be super easy (and I would encourage you to do it ASAP). I just want to make sure you have time to handle all the things that will block you from doing the easy part.

Related Content