Author: Michael G

Let’s define the scope and goals of our project to upgrade this very website to Drupal 10.

Essentially, that’s it: we want to upgrade this website to Drupal 10 so that we can benefit from security releases etc.
At the moment we want to do so with the minimum of effort, so I don’t want to have to be writing lots and lots of code or changing fundamentally how the site works, but I am up for simplifying things if it gets us to a point where we have to maintain less code.

Since Drupal 9, major version upgrades now take this basic form:

• Update your code to be fully compatible with the last version of Drupal, removing all deprecations: hard.
• Upgrade to the new version of Drupal: easy!

I’m going to install and use the fantastic Upgrade Status module to get a detailed handle on what we need to change, upgrade and rewrite to get the site working in Drupal 9, but ready for Drupal 10. We’ll use that as a basis to see what we need to upgrade, the best plan for each component and go from there.

Upgrade status – First pass

We previously have composer require’d the upgrade status module into our codebase, so after enabling and running the report, here are the major findings that concern us for this series:

Environment

• We’ll need to upgrade to PHP 8.x, the site is currently running on PHP 7.4.
• We’re using deprecated or obsolete modules that come with core and will be removed in Drupal 10. This is a rather scarily long list for us:
  • CKEditor
  • Color
  • RDF
  • Seven
  • Stable

But other than that, we’re good to go from an environment point of view.

Contrib projects

Upgrade status breaks the list of contributed projects down into a few sections, those are:

• Projects that need an upgrade that might make them Drupal 10 compatible:
  • Better exposed filters
  • Components
  • Disqus
  • Advanced link
  • Entity browser
  • jQuery UI Slider
  • Scheduler
  • Simple XML Sitemap
  • Twig Tweak
  • Webform
• Projects that don’t have Drupal 10 releases yet, so either require patches or work to get them to Drupal 10:
  • Entity Embed
  • jQuery UI Sortable
  • Kraken
  • Markdown
  • Social media share
  • Term Reference Change
  • Unified Twig Extensions
  • Video Embed HTML5
  • Weight
• Projects that are compatible with Drupal 10 already, I’ll not list those, but there are plenty already, it’s great to see community support for Drupal 10.

Custom code

Upgrade status will scan your code and tell you if there are problems that can be spotted that will stop the code working with Drupal 10. This is static analysis, so isn’t perfect, but is a really good start.
We have a few custom modules doing very specific things on our site, but we have a custom theme, doing quite a lot of custom things, and that’s where the main bulk of the issues the scanner found are, so we’re going to need to set aside some time for that.

Simplifications

This site was built in the early Drupal 8 days, and we’ve not actually made too many changes since, specifically when we upgraded to Drupal 9 we basically did the smallest amount of work to get it there. How you’d typically handle media on a Drupal site has fundamentally changed since we built this site, in that you’d likely use the core Media module and add entity reference fields to your entities rather than adding image/file fields directly. However, we never had that luxury and never got around to changing our approach to use the core Media framework.

So, we’re going to allow ourselves a bit of scope creep to do this ‘sub project’ given that the benefits are that we’re going to be able to remove a bunch of modules: entity browser, file browser, etc. that will then mean that we don’t need to upgrade those modules and our dependencies will be better supported: since they’ll be in Drupal core. It’s no slight against those modules, it’s just that we don’t need the functionality they bring, for our site today.

The scope/plan

So roughly the scope/plan is shaping up to be:

1. Convert our file/image fields to core media, and remove entity browser, file browser, etc.
2. Update our custom code
3. Evaluate the remaining upgradeable contrib projects to see if we can remove them, and if not, upgrade them.
4. Evaluate the remaining non-upgradeable contrib projects to see if we can remove them, and if not, work with maintainers to get them upgraded.
5. Handle the core modules that have been marked as deprecated or obsolete.
6. Upgrade the PHP version we use to run the site
7. Get the site running in tip-top condition with the latest Drupal 9 etc.
8. Do the Drupal 10 upgrade.

Then we’ll have a shiny Drupal 10 install, ready for the next few years of security patching.