Drupal 10 site upgrade

My experience upgrading my first production site from Drupal 9 to 10. Had run quite a few test Drupal 10 sites, and upgraded some tests but this was the first live upgrade of a real site with all the warts and contrib modules that usually entails. Despite it being almost 3 weeks until Drupal 10's launch, it was fairly smooth - certainly smoother than most D8->9 upgrades even a couple weeks post D9 launch.

What production site you might ask? You're reading this on Drupal 10 right now. Not a massive site, but decent functionality especially on the backend/currently unpublished sections. Given timeline pre-launch was a good practice run for my larger sites/work sites and got a few patches out and also published one new module version with Drupal 10 support. By next weekend I should have a bunch more of my modules with published versions as well as I continue to test some backend features.

Drupal 10 has removed two modules that I was using - RDF and CKeditor 4 support. RDF I wasn't using seriously on this site, so I simply uninstalled it. I then added the contrib ckeditor 4 module, because I decided not to convert to CKEditor 5 today - instead using the contrib space module provided to ease that transition.

Before making further changes, I deployed this - that way I don't have to worry about the missing module in the production environment making uninstall a problem later. Having the duplicate ckeditor 4 module wouldn't cause any problems - duplicate modules are simply ignored and modules in core take precedence. Long term I dislike duplicate modules and they a very minor performance negative but short term for this process was very much not a concern.

Additionally, the core theme classy was also deprecated in Drupal 9 and has been removed in Drupal 10 - like ckeditor, I decided not to fully migrate away from that and used the contrib replacement theme. As a bunch of the theme functionality in this site is shared with some other sites I will update my internal base theme and all the custom themes after that.

Next I updated my custom modules and theme functions - basically nothing to do other than update the version specs in the .info.yml file as I had been keeping up with deprecations fairly well. Had to update a couple of get_path functions and that was done - didn't even bother running these through rector because I was confident they were good to go.

Next came the steps that I expected would take a bit of work but should be straight forward. I knew I was using some modules that weren't yet up to Drupal 10 with any releases. On the face of it with the beloved (by me anyways) composer patches plug-in that isn't a problem especially with the automatic readiness patches the DA has running. However, there is one big flaw there. Composer patch plug-in runs after composer checks dependency versions - so you can't require the modules.

Luckily,  Matt Glaman has stepped up with another great tool - Composer Drupal Lenient. This is a composer plugin that let's you specify Drupal packages to ignore the core dependency conflict on. That was processing easily until suddenly hit a module that was an indirect dependency. My understanding was that would work but it wasn't! So I tried adding it to my direct dependencies. That did nothing. Removed it and went digging into my first challenge. 

Turned on xdebug. Ran it again and started walking through modules as each dependency was analyzed. Got to the module that had been failing drupal/calendar_datetime and then it made total sense. That's not a full drupal project. You can have multiple modules within a single Drupal project - like Views Slideshow has the submodule Views Slideshow Cycle or in this case drupal/calendar has the submodule Calendar DateTime. The Drupal composer facade exposes each submodule as a composer package specifically of the type metapackage. However, the Composer Drupal Lenient plugin only affects packages of type drupal-*. There are definitely good reasons to require the metapackages for dependencies, however in this case I believe that drupal/calendar is misusing the feature. Regardless, though it is a possible package type that should be updated with the module.

So my first patch and pull request of the day happened. In the boring side of things, I then added my patch to my composer.json and ran it. At which point it failed hard. Because the way composer patches works, is it removes the thing to be patched before composer dependency resolution takes place. So if the install ran the right order, that could work, but any deploy situation would be at best fragile and in most real cases would break. That though was a very easy fix that needed no debugging for me. Instead of using my patch, I used my entire branch as the version of Composer Drupal Lenient to install.

Finally! Smoothly from there on finding out what modules didn't have a compatible release. I ended up ignoring core dependencies on about 15 contrib modules.