I've finally updated this website from Drupal 7 to Drupal 10.
Drupal 7
Drupal 7 was released on 5th January 2011.
It offered a significant improvement on Drupal 6 (13th February 2008) and Drupal 5 (15th January 2007). Drupal 4.7 was 1st May 2006.
You'll notice a longer time-lag between Drupal 6 and Drupal 7 than between the previous major releases. Drupal 7 took some significant leaps forwards. Most vividly, I remember the old Content Construction Kit module (aka CCK) being incorporated into Drupal core. Many bugs were ironed out and the architecture much improved, which is why it took 3 years rather than 18 months.
Upgrading between those versions of Drupal up to and including Drupal 7 was relatively straight forward. You could use the database that powered the previous version site, run the upgrade script, and everything would work with the next major version.
Drupal 8
Drupal 8 was not released until 19th November 2015, a gap of nearly 5 years. That's because it was a complete rewrite.
Up to that point, Drupal had used its own ways of making PHP power the site. It had its own template engine, for example. From Drupal 8 onwards, the decision was taken to use tools others were already using, like Symfony and Twig. That meant it wasn't a matter of tweaking the old codebase, making (relatively significant) changes like adding new hooks and capabilities. It was a completely new codebase, using yaml files for configuration storage, and so on. That took its time.
It also meant that upgrading a site to work with Drupal 8 was a major enterprise. You had to install a new instance of Drupal, and then use a suite of migration modules to bring your old content and configuration across.
Why Drupal 10 not Drupal 8?
So why did I upgrade from Drupal 7 to Drupal 10, not to Drupal 8?
The simple answer is that I was not ready.
A significant site redesign like this takes time. I am not a paid Drupal web developer; maintaining this site is a hobby that has to fit into spare time, of which there's never much. Before I could start building a new edition of this website, I had to learn my way around configuring a Drupal 8+ website in general. I wanted to use git to manage my site development and deployment, and use the new configuration export tools to the full.
I also wanted to use the opportunity of a redesign to do things right. There's a danger in bringing the same site database through 4.5 to 4.6, to 4.7, to 5.x, to 6.x, to 7.x. That is the danger that some sub-optimal design decisions get carried forwards indefinitely. Drupal has evolved, as has this website, and what was the right decision in the early days may not be now.
So I took the time to plan everything carefully. Rather than exporting my Views to import into the new site, I built them from the ground up using the Views UI. That gave me the opportunity to merge a few Views into one. I gave thought to content types, taxonomy and other features. In moving from Panels and Page Manager to Layouts, I wanted to design things correctly. What contrib modules would I use, and how would I use them? How would I theme the new site? (That's a separate topic, to which I'll return in another post).
All of that took a considerable amount of time. Meanwhile, Drupal Core development kept moving. Drupal 9 was released on 3rd June 2020. Drupal 10 was released on 14 December 2022. Drupal 11 was released on 1st August 2024. There's now a clear release schedule where a new major release is expected every 2 years, and a new minor release (like 11.1 instead of 11.0) every 6 months. Each major release is supported until the release of the second subsequent one (so Drupal 10 is supported until Drupal 12 is released).
Fortunately, you can migrate a site from Drupal 7 to any subsequent version. Because content is being migrated into the new site, you can migrate the content of a Drupal 7 site directly into a Drupal 8, 9, 10 or 11 website. So the fact that Drupal 11 was released before I had finished my site migration did not mean I had to run multiple upgrades. I could install a brand new Drupal 10 website, import the configuration I'd been working on, then migrate the content from Drupal 7.
Why Drupal 10 not Drupal 11?
All of this begs another question: Why did I upgrade to Drupal 10, not Drupal 11? This time, not because I was not ready, but because it was not ready.
The upgrade path from one major release of Drupal to the next is now smooth. The big rewrite from 7 to 8+ has been done once, and going forwards it's much simpler to upgrade to the next major release. Simpler, but not automatic.
In particular, there need to be Drupal 11 compatible versions of each contributed module I'm using.
It's possible to use a Drupal module in a site that isn't working exactly as you need, and apply any uncommitted changes to the codebase. To do this, I (along with most Drupal developers) use the Composer Patches packagist tool developed by Cameron Eagans. This allows you to put links to patch files into your composer.json file. Those patches are then applied each time a composer package (like a Drupal module) is installed. So, if you have a patch that fixes a module bug (maybe from the Drupal issue queue), but the module developer is yet to commit that fix to the code repository, you just link to the patch that fixes the bug and your site can benefit.
Unfortunately, you can't do that with the tag that says which Drupal core versions a given module release is compatible with. If a module is not compatible with Drupal 11, composer will see this and refuse to install the module alongside Drupal 11 core. You therefore never get to the stage where the patch is applied to adjust the core compatibility.
So if a contributed module is not ready for Drupal 11, I cannot move the site to Drupal 11 without finding a different module to use instead, or forking the missing module to my own git server to give me a private copy. That latter option would move my instance of the module outside the watchful care of the Drupal security team, who handle timely disclosure and fixing of any vulnerabilities. So, mostly, it's best just to wait.
I'm left waiting for 3 modules:
- Menu Import and Export (version 1.4, released May 2023, supports Drupal 8, 9 or 10).
- Configuration Override Warn (version 1.4, released April 2023, supports Drupal 9 or 10).
In both those cases, I think the code is ready to go, it just needs a tagged release that supports Drupal 11.
- Avatar Kit (version 1.3, released December 2022, supports Drupal 9.5+ or Drupal 10).
That is more complex, as there have been no commits for some time, and there is a pretty major bug unaddressed in the issue queue. The maintainer has made pretty clear that they wish to remain sole maintainer, and will not be approving co-maintainers, so it seems this project is stuck for now. Seeing this, I chose not to incorporate that into this site — yet. I may, at some point, code a much simpler version to use.
I do need Menu Import and Export and Configuration Override Warn, so I will need to wait for their Drupal 11 versions. If end of Drupal 10 support draws near, I'll need to make another plan.
First Thoughts
So now this website is running on the latest version of Drupal 10.
My first thoughts are that I love it.
- The content editing experience is more up-to-date, and much easier to work with.
- Having all site configuration exportable and then manageable in git makes it much easier to build and document a site. Changes can be rolled back if required.
- I love Twig as a theming engine.
- I have a much more modern workflow, and find using composer for package installation much easier to manage. I also have a development and staging copy of the site to work on any changes, which is a big improvement on the development copies I was creating to test changes to the Drupal 7 website.
- It seems to me that Drupal 10 has much better content caching than Drupal 7, and so the pageload times are faster and navigation is snappier.
So it was worth the upgrade pain, I'm just a little late to the party.
I'll post another time on theming.
Let me know of any problems you spot
I've not finished tweaking, and I keep noticing bits of layout that can be improved. But if you spot things (CSS, content, responsive layouts) that don't look right, please let me know - either in the comments here, or by email.
Recent comments