It’s day 14 of the Drupal Advent Calendar, and today is a very special day for Drupal fans. Today we see the launch of Drupal 10, which is sort of a bit like Christmas coming early.
Yesterday I talked about getting ready for
Christmas Drupal 10 with the Upgrade Status module, so I thought that today it might be a nice idea to take a short break from modules to see about what we can expect from Drupal 10.
However, before I do that, I need to do a little expectation setting. In the past, a major new version of Drupal would come along every few years, and would contain lots of new features. However, once released, the feature set would be fixed until the next major new version, so new versions generated a lot of excitement.
However, since Drupal 8, new features can be added in minor versions, providing they don’t cause any “breaking” changes. Minor versions come out on a steady schedule, about 6 months apart, so new features are added fairly regularly. New major versions may add some new features, but they are just as much about removing old deprecated code.
The driving force for new major versions tends to come not from Drupal itself, but from other dependencies it relies on, and in the case of Drupal 10, those happen to be Symfony, CKEditor, and to a lesser extent, PHP. The versions Drupal 9 depended upon are all going end of life in 2023, so to ensure Drupal stays secure and supported, Drupal 10 is moving to newer versions of all of them.
The result of all of this is that there isn’t very much new stuff in Drupal 10, and version 9.5 is also launching today, and has a pretty much identical feature set.
So it would be easy to dismiss Drupal 10 as not very interesting, but I feel it has a lot to get excited about, and I’m going to talk about some of those.
As this is quite a long entry, I’m going to break with my almost traditional style, and start using subheadings.
Conducting a Symfony
The first is Symfony itself. Since Drupal 8, Symfony has been the underlying framework behind it. Many pieces of logic that had previously been coded in PHP directly have been reworked to take advantage of the Symfony libraries. There may not be much visual difference, but it contributes to the stability of the project. Drupal 9 used version 4 of Symfony, which won’t be supported past November 2023. Drupal 10 jumps to version 6 of the framework, ensuring it will remain supported for the next few years. Aside from ensuring support, it’s likely that newer features of Symfony will begin to be used in Drupal projects, and that more of the core logic will be leveraging its capabilities.
It’s also likely that modules utilising Symfony 6 features will start to appear, and they will only be available for Drupal 10 and above.
Making a nicer edit
One change that will be a bit more visual impact is CKEditor, the WYSIWYG editor used by Drupal. Again, the change is driven by the end of support for CKEditor 4, but version 5 has a lot of new capabilities, including a more advanced engine for creating the HTML content. The included version can do everything that version 4 could, and more besides. However, if you need extra features there is a very impressive premium version that offers a lot of additional functionality, including collaborative editing. If you want to try it out on Drupal 9, there is a CKEditor 5 contributed module you can install. Indeed, if you want to upgrade your site to Drupal 10, it’s generally recommended to upgrade to the CKEditor 5 module before upgrading core.
The last dependency upgrade is to PHP. Drupal 10 requires version 8.1. Again, this will make no difference unless you are a developer, but PHP 7 is no longer supported, so I feel that upgrading the minimum for Drupal is not a bad thing.
As an aside, this is not strictly a dependency upgrade, but Drupal 10 will no longer support Internet Explorer, meaning that it will only support standards compliant browsers. This will allow a lot of messy workarounds for IE to be dropped. It will also allow themes to use newer web standards.
Time to say goodbye
Aside from dependencies, there are a number of formerly core modules that have been deprecated. While they are no longer in Drupal core, they will be available as contributed modules. Some of the affected modules, such as Color, probably don’t have much of a future, but are available if anyone really needs them. However, there are others, such as Forum, that might actually benefit from a less restrictive update policy in the contributed module space, and I’m hopeful they will see new features and enhancements they didn’t get when they were in core.
It’s all about the theme…
The next area that definitely makes a noticeable difference is new themes. The default Drupal themes had been more or less unchanged since Drupal 7, making it look a little dated, even though a lot of work had been done to make them reasonably accessible.
The new default front end theme is called Olivero, which has quite a striking appearance. I will admit I have done a lot with a customised subtheme of Bartic, the previous default theme, often only requiring some CSS to make it look how I wanted. I look forward to seeing how well the same approach will work with with Olivero.
Drupal uses a separate theme for administration pages, and the previous admin theme was called Seven, after the version of Drupal it was developed for. While it’s a credit to the developers of that theme that it has stood the test of time, it has been getting a bit long in the tooth, and was due for a replacement. The new admin theme is called Claro and it provides a very clean, modern interface.
Olivero and Claro are available for Drupal 9 already, so you can try them out now. If you install a new 9.4 site, it will use them as its defaults, but if you upgraded your site from an earlier version, your existing theme will remain. However, if you want to keep Seven or Bartik when you upgrade to Drupal 10, you need to add them as a requirement to your Drupal project before carrying out the upgrade.
As another aside, if you like the Claro theme, you should also take a look at the Gin Admin Theme, which is based on Claro but adds a number of enhancements, including a dark mode, and a number of features to enhance the admin experience. Think of Claro as the conservative highly stable version for core, and Gin as its edgier sibling that’s a bit more risqué.
Kitting out your starter site
The other features of Drupal 10 are still something of a work in progress and will be evolving over the life of Drupal 10, and are not necessarily very usable now.
Sticking with theming, there are new Starterkit themes. The idea of these is to provide a tool to create a starting theme based on a template theme. At present there is only one such theme you can use it with, named Starterkit, and it’s something of a blank canvas. It’s expected there will be several templates that support it in the future, including Olivero, so you’ll be able to choose one as a starting point, generate a new theme, and build from there.
Cooking up a recipe
Another important feature is Recipes, which are designed to make it easy to set up a site for a particular purpose. In the past this could be done with Distributions, which were like a version of Drupal tailored for a particular function, and might have a set of modules preinstalled, various configurations, and often a custom theme.
There were several problems with this approach. First, you had to install your chosen distribution as your Drupal site, so you couldn’t add it on to an existing site. This also meant you could only take advantage of one distribution on the same site, so if you wanted functionality from two different distributions, your only option was to pick one and figure out the rest of the site on your own. But perhaps the biggest problem was that it was up to the distribution maintainers to provide updates to the distribution, and you couldn’t install regular Drupal updates. This could result in distributions falling behind the main Drupal release if their maintainers didn’t provide updates in a timely fashion.
Recipes aim to overcome these limitations by simplifying the process. They will consist of a set of configurations in the form of YAML files, which define various configurations that can be applied to your site. These could be modules to install, content types to define, taxonomy terms, or many other configurations. However, any custom code would need to go in a module that the Recipe would include.
There are several advantages to this approach. First is that it can be applied to your site at any time, not just when it’s installed. The second is there is no limit on how many Recipes you can install. Finally, since the Recipe only defines what modules to install, but those modules are still fetched through the normal Drupal Composer installs, updates to the site are not affected, so Recipe maintainers don’t need to provide them, and sites using Recipes get updates at the same time as any other Drupal site.
One aspect of Recipes that I think will be quite exciting for a lot of people is the ability to create your own custom recipe. For those that have a favourite set of modules they install on every site, it will be a handy way to automate installing them all up and making any setting tweaks while creating new sites.
Browsing for updates
Automatic Updates, as you might be able to tell from the name, is intended to download and install updates without the site maintainer having to take action. Initially it is just intended to do this for Drupal core, but in time it is expected to also update contributed modules. This is something that most other major content management systems have had for some time, so it’s good to see it starting to make its way into Drupal.
Project Browser is designed to let you search for Drupal modules and other projects, and install them from the web browser. Previously, you had to search for projects on drupal.org, so this is a significant departure. Beta 2 is currently being tested, so it may be a while before it’s ready for production sites, but it is an impressive demonstration, and you can try it out right now.
Project Browser will also be integrating with Recipes, making installing them a breeze.
What I find impressive about these projects is they have implemented the core logic of Composer, so all the dependencies are resolved during installation. So while some other systems may have similar functionality, most don’t have the same degree of dependency management, so may not do as good a job of tracking libraries or other dependencies.
So that’s my round-up of Drupal 10. Even though it may not look much different form 9.5 at the moment, I think there’s a lot of very exciting stuff coming over its life, and I’m really looking forward to seeing how it develops.
And that’s day 14 of the calendar. I hope you’ll keep coming back for the rest of the doors. Tomorrow, I’ll go back to talking about modules.