Drupal 10: Sometimes it’s tricky!

Eli Stone / Nov 7, 2023

In Part I of our Drupal 10 series we talked about how Drupal 10 updates can be easy and the methods we follow to improve our workflow. In part II we’ll discuss the flipside, occasions when it’s not always as simple, the problems we’ve faced and how we’ve resolved them. Hopefully, some of the tips and tricks we used along the way will make updating less painful for you.

Contrib modules

The first battle you might encounter is modules that are not yet released for Drupal 10, for this you might find two things:

1. An open issue with a patch ready to use - reviewed and tested.

2. An open issue that has automatically been created.

If you see a reviewed and tested issue you’re in luck, this patch should be easy to apply and you’ll just need to use “mglaman/composer-drupal-lenient” to bypass the Drupal version checked - see our previous blog for more information.

If it’s the second option, you might need to put in some extra testing. The automatic issues generation might be all you need but not in every case. We recommend scanning the contrib modules with upgrade status to make sure everything has been found, and if not you might have to create your own patch. It would be great to submit that back to drupal.org to help out the rest of the community, for those who might encounter the same issue.

Custom code

The amount of custom code used on your site will affect how long this part takes to complete, but just like with contrib modules you will need to scan all your modules and work through the changes.

We found this to range in general from missing core_version_requirement to swapping out deprecated functions such as:

Functions file_create_url() and file_url_transform_relative() are deprecated - https://www.drupal.org/node/2940031
Functions drupal_get_path() and drupal_get_filename() have been deprecated in favour of extension listing services - https://www.drupal.org/node/2940438
Symfony responses have been deprecated - https://www.drupal.org/project/drupal/issues/3094398
Access checking must be explicitly specified on content entity queries - https://www.drupal.org/node/3201242

The above changes are just some of the things we had to deal with while updating our custom code, each time having to understand the code before just swapping something out.

jQuery/once

While updating custom code another big change is dropping jquery/once - https://www.drupal.org/node/3158256 - there are two parts to this change:

1. Adjust the value found in the module library from core/jquery.once to core/once - this part can be found by the upgrade status module.

2. Adjusting your JavaScript to work with the new library.

There are other examples found on the above change record, but this is the basic idea.

Your code before:

Your code after:

Don’t forget to check all of your JavaScript files to make this change.

Drupal 10.0 vs 10.1

During our updates we have found that some modules are not ready to work with Drupal 10.1 at the moment.

This leaves the option of not going higher than 10.0 for now or finding ways around it.

Two modules that we are aware of with this problem at the moment are:

https://www.drupal.org/project/advagg - “AdvAgg needs a major rework for Drupal 10.1 - recommend holding update or disabling AdvAgg until a new release comes out.”
https://www.drupal.org/project/swiftmailer - This module is no longer supported and as such cannot be used on Drupal 10.1 due to dependency conflicts, the solution here is to swap over to using Symfony Mailer

Updating to Drupal 10

The final steps of getting Composer to play nice with Drupal 10 might end up being a little challenging, often resembling a ‘chicken and egg’ dilemma.

What we have found that works in the end is:

Make sure to use mglaman/composer-drupal-lenient package to bypass Composer
If you keep seeing the same modules show up preventing the update, you can remove it and keep a note to add it back after.
Remove composer.lock to fetch everything from scratch
Remember to use --update-with-all-dependencies

Summary

The complexity of your site will always adjust the difficulty of updates, however, we have found that going from Drupal 9 to 10 was much easier than 8 to 9.

The more you update the easier it gets, leaning into your scans really helps but nothing beats testing so make sure you fully understand how your site should work so it can be tested in a safe environment.

Hopefully, some of the problems we’ve faced will ease issues you might be having. If you have any questions, be sure to reach out, we’re always happy to help.