Drupal 10 is coming out next month December 14.
Drupal 9 was released June 3 2020 and will be end of life November 2023. This means Drupal 9 sites have 11 months to upgrade to Drupal 10, to stay protected.
Why make Drupal 10 now?
Since Drupal 8, Drupal now depends on a number of top class libraries in the spirit of PFE (Proudly Found Elsewhere) so they can innovate faster while leveraging battle-tested opensource libraries where available. This has so many advantages like it weans Drupal developers off a lot of Drupalisms because they are utilizing same libraries other PHP frameworks are utilizing. In a way, these libraries and systems are uniting PHP developers to write code in same way, to follow same patterns and to write re-usable code. Adopting PFE also helps Drupal to innovate faster by leaving out lots of heavy lifting to focus on 'more important' stuff. It also brings lots of good stuff to Drupal as some of these libraries do bring kick-ass of their own alongside. Drupal layers on them and the Drupal community takes advantage of these kick-ass features. Why spend time making it in-house when it's kicking ass elsewhere already?
As an aside I believe Drupal did not make a total rewrite in Drupal 8 because it wanted but because the landscape was changing, PHP was changing and Drupal is written in PHP so have but to change along.
Depending on external libraries also mean you have to respect their life cycles. If an external library you depend on stops supporting a version for a newer version, you likewise have to move up to the newer version else you will be using a dependency that does not have security coverage.
Symfony dependency forces Drupal to make a new major version
Drupal 9's biggest dependency is Symfony 4. Symfony 4 will be end-of-life in November 21, 2023 so Drupal has no choice but to do something about it. The choices are either to fork Symfony 4 and start maintaining it in-house or move up to Symfony 5 or Symfony 6. Why start maintaining Symfony when we've got Drupal to maintain? So, move up Drupal must! Moving up to Symfony 5 or 6 require such changes that cannot be made in a minor release of Drupal 9 so a new major version has to be made and it has to be called Drupal 10. One good thing is Drupal 10 shall be requiring Symfony 6 and not Symfony 5. Symfony 5 was released November 21, 2019 and shall be end of life November 30, 2025 (3 years from now). Symfony 6 was released November 29, 2021 and sure has more years to live than 3 years. Drupal 10 using Symfony 6 which got released last year means the life cycle will be extended so it might be a bit longer before we get to Drupal 11 than it took Drupal 9 to get to Drupal 10.
What's New in Drupal 10?
1. A new administration theme
One of the Strategic Initiatives Drupal has been working on, included developing a new administration theme to replace Seven which has been the admin theme for Drupal since the days of Drupal 7. Making a new admin theme Claro, was a part of the now rested Drupal Administration User Interface and Javascript Modernization Initiative. Claro was developed and tested in contrib, added to 8.8.0+ core as experimental module, and as from April 27th, 2022 became stable and has been set as default admin theme for Drupal 9.4 and Drupal 10. This modernizes the Drupal administration interface and gets Drupal more ready for the future.
See a video demo:
2. A new front-end theme with a modern look and feel
Another one of Drupal's Strategic Initiatives was to make a modern front-end theme to replace the Bartik theme that has greeted you after you installed Drupal for over 11 years now. From Drupal 7 over to Drupal 8, Bartik announced to you 'Congratulations, you installed Drupal!' and Drupal needed a modern theme to match up with all the modernization taking place in the backend. So work started on the Olivero theme in contrib, next the theme was moved to Drupal 9.1.0 core as experimental theme. In April 2022 it was set as default front-end theme for Drupal 9.4 and now is also default front-end theme for Drupal 10.
See a video presentation:
3. CKEditor 5 to replace CKEditor 4
One of the deficiencies of Drupal 7 was the text editor you got when you installed Drupal. You actually got none. Just a blank box staring at you, no text editing tools, no HTML editor, no rich-text editor, just a blank box. If you wanted to add a rich-text editor you would have to find one from contrib.
Drupal 8 solved this by shipping with CKEditor as default text editor. This made Drupal easier and more approachable out of the box. Drupal 8 used CKEditor 4 up till Drupal 9.
Work started on CKEditor 5 in contrib and the module was moved to core in Drupal 9.3.0-beta1 as an experimental module. On September 8, 2022 it was announced as a stable core module in Drupal 9.5.0 and upcoming 10.0.0.
CKEditor 5 improves and modernizes the content authoring experience. Check out the features.
4. Responsive Grid Views style
The Grid Views style has not been responsive up from Drupal 7 to Drupal 9. Some people do not care to use it unless they do not bother about columns fitting different screen sizes, but who wouldn't bother about that these days? If someone wanted to use it, s/he had to add a contributed module to make it responsive.
In Drupal 10, Views now adds a Responsive Grid style format. Instead of specifying the number of columns, and screen widths, users specify the maximum number of columns, the minimum grid cell width and the gutter spacing. When the grid cells resize to a point where they’re below the minimum width, the grid will reflow to have less columns. Alternatively, the grid will expand to fit in as many columns as permitted, while keeping the grid width above the minimum value.
This will be helpful and will make the Grid style format to actually be usable.
5. Modern JavaScript components to replace some uses of jQuery
First it was jQuery UI and the asset libraries, and then it is jQuery itself.
jQuery UI was marked as an Emeritus Project by OpenJS Foundation and for that Drupal deprecated it, removed the asset libraries that are not used by core nor contributed modules, added core replacements for some like jQuery UI Sortable and jQuery UI position, and moved the rest to contrib. Moving them over to contrib will help so if there is a security issue or some issue with one library, it can be isolated and fixed instead of posing a problem to core.
There is also a gradual, though not urgent move to replace most uses of jQuery itself in core, and libraries that depend on jQuery. Some of the replacements is by way of alternatives, Drupal's own home-grown solutions (open-sourced for anyone else outside Drupal to use) or vanilla JavaScript.
In Drupal 10, modern JavaScript components will replace some uses of jQuery.
6. Starterkit theme generator
Since Drupal 8, lots of people sub-themed the core Classy theme for their custom themes. As Drupal 8 progressed, the problems with this began to show. Issues were posted for Classy theme but the issues could not be closed because committing changes to Classy would break the sites using the sub-themes if they didn't override the affected files. A task was then started to provide a starterkit theme in core. In April 2021, a starterkit theme generator was added as an experimental new tool in Drupal 9.3.0 core.
In September 2022, Classy was removed and replaced with Starterkit theme generator in Drupal 10.0.0-beta1 core. The Starterkit theme generator is now the recommended way to create new themes. (Well, this may not be for Drupalistas like me who hardly sub-themed Classy. I usually sub-theme one of the popular contrib base themes for my custom themes.)
The new approach copies all files needed for the theme over to the sub-theme and the starterkit theme is not used in the runtime as part of the theme. This separates the starterkit theme from the live sites and makes room for innovation and improvements on the starterkit theme without breaking sites using themes generated from it.
This is a command line tool.
7. PHP 8.1 required
Drupal takes security seriously and is known not to support outdated system packages. For example take a look at Drupal's PHP requirements and take a look at PHP's official Supported Versions. You can see that Drupal recommends at least PHP 8.0 to run Drupal 9 or Drupal 10 (at press time). This is in tandem with the supported versions of PHP.
You will also see that Drupal 10 already supports PHP 8.2 (at press time). This defines bleeding edge.
Yet more goodies
There are two items on the list of Drupal's Strategic Initiatives that I personally am so fascinated about. They are the Project Browser and Automatic Updates Initiatives. There is a third one, Recipes.
These three initiatives will not ship with Drupal 10 in December. They are planned for Drupal 11 but in the DrupalCon Prague 2022 Driesnote presentation, Drupal's creator and project lead, Dries Buytaert, did mention there is a chance they might land in one of the minor versions of Drupal 10, something like 10.2.x or 10.3.x.
Project Browser
As an ambitious site builder, this tool is so dear to me, not that I cannot use Composer but it would be a big time saver and will make finding and installing modules a breeze. Project Browser writes to composer.json so if I already manage a site with Composer and I install a module through Project Browser, it will update my composer.json!
I once visited a client's office and we had to do some work in his office. I didn't go with my laptop and he offered me his own laptop to work with. He doesn't have Git, Composer, Git Bash, FTP client, SSH Client and such on his laptop. He is not a web developer. When we started working on the website I had need to add extra modules on the site and he also noticed there was a security release for core and he asked that I equally update the site at once. I realized how limited I was without my laptop. I had to install the modules from the UI and told him I would update core when I got back to my office. He said, 'oh, is that the Composer thing you always talked about?'. I said, 'yes sir'. I didn't tell him I would also re-install all new modules we added when I get back to my office, so Composer would know them, and then push to Git and then deploy to the server. Project Browser and Automatic Updates would have come handy that day. It would not have made much difference that I didn't have my laptop.
Project Browser will solve lots of problems for Drupal. Among the initiatives Drupal has worked on since Drupal 8, the Project Browser and Automatic Updates initiatives are the most game-changing. They both will be serious game changers for Drupal. Mostly for non-developers and also for developers.
When Drupal 8 shipped, the loudest complains from site builders were issues with Composer and the fact that it is not recommended anymore (even though not disallowed also) to install Drupal 8 the Drupal 7 way - download tarball, install with Drush, install with Softaculous, or clone with Git. Also when you got Drupal running, it is also no more recommended to install a module from the UI or from tarball or even using Drush (even though these are not disallowed also). This was a barrier for lots of people and even for people that can well use Composer. It is not convenient that each time you want to add a module, you have to launch terminal, launch Git and follow a whole process - just to add a module on the site.
For people new to Drupal or that are trying out Drupal, Project Browser will retain 7 out of 10 people that otherwise would have felt out of place. Right now if they install Drupal and click on Extend. They will have to follow links to go over to Drupal.org to hunt for a module, if they finally find, they will see note that the recommended way to install the module is with Composer. They may hardly have heard the word Composer (in computing) not to talk of knowing what it means or where to find it or how to use it. They will feel they landed in a strange land and will most likely look for an exit route. Project Browser would have made them feel at home and welcome. With Project Browser, they would find it fun to look at the spectrum of modules available to them, filter them, find one, and install it with a click. It would be more fun. Project Browser will update their composer.json, if they knew Composer they would care about that, if they didn't, they wouldn't care.
Project Browser will bring back the verve in Drupal 7 site builders that are disgruntled and will make them like Drupal more because it is even far easier now than in Drupal 7. Drupal got so much easier to own and use for site builders with Drupal 8+ than in Drupal 7, just if you can remove the Composer hurdle. For most site builders the bridge they have to cross to take advantage of all the shiny new things in the new Drupal is Composer. When you tell them about CKEditor, Layout Builder, fieldable blocks, comments as their own entities, Views in core, form displays, Commerce 2, madda Webform and all the cool things in the new Drupal, they will sure like and want them, but when you tell them they must install Commerce 2 with Composer and the recommended way to install any module is by using Composer, they will see a barrier in the way. They are not developers and even though many are used to Drush many still never touched a terminal. This is why I said Project Browser will be a game changer. It will not stop Drupal from being managed with Composer but at the same time it will not stop a site builder not comfortable with using Composer from working with Drupal. It will manage the site with Composer on behalf of the site builder. It's powerful!
Lots of times there are so many amazing modules that Drupalers don't know about maybe because they have not happened to come across them. Project Browser will have highlights for some of these amazing modules that Drupalers need to know or hear about.
When Drupal 8 was launched, some analysts said Drupal has moved away from small sites and now has made itself a framework for big sites and for the big dollar enterprise market. I think I read Dries somewhere say at the time, that was not so. Project Browser will open the door for small sites and for more little guys to work with the new Drupal.
A prototype of the tool is available in contrib, you can try it out and report any issues if found.
Here is a video demo of the tool,
Automatic Updates
Keeping Drupal code, especially core, updated is one of the pain points of owning a Drupal site. Most times when I read some of the 'Drupal vs Other CMS' comparisons, the one point they will always make bold as a con for Drupal is the process of applying a code update. It's technical to update Drupal core. Modules and themes have been able to be updated from the UI since Drupal 7 (can't remember about Drupal 6) although with Drupal 8 this changed a bit. With Drupal 8, if you manage the site using Composer then all updates should be applied using Composer so the update process from the UI wouldn't be recommended for you, even though it will still be available and would work. If you are managing the site manually as of old, you can update modules and themes from the UI.
To update Drupal core has never been easy. With Drupal 7, if you manage the site manually, you will have to download tarball and SFTP the update, or you use Drush for an easier process. Both methods are technical for most people. With Drupal 8, an extra method was added which is to update the site using Composer. This is even more technical.
The process to update Drupal core adds to the cost of owning a Drupal site. If you are not a technical person then you will have to keep a technical person around to apply updates on the site and you may have to keep him on your payroll.
Like Project Browser, Automatic Updates will be a game changer for Drupal. It will reduce the cost of owning and managing Drupal sites, and help sites to update on time when security updates are released thus making Drupal sites more secure overall.
The module is being developed in contrib, you can try it out and report if you find issues.
Here is a video demo of the tool,
Fully automatic, completely unattended updates are not yet supported, but is in the roadmap.
Recipes
Recipes are like distributions but not as difficult and bulky as distributions. A recipe is a defined feature-set that serves an isolated purpose. It's a combination of code and configuration in a YAML file that can be bolted on a site to add a standalone complete functionality on the site. Let's say you have an existing site and there becomes a need to add a blog feature on the site, or a news feature or an e-commerce feature. You would browse Recipes directory on Drupal.org, find one for a blog and install it on your site with Composer or Project Browser. With that you have a pre-defined blog functionality on the site and you can straightaway start posting blogs on your site.
Unlike distributions, recipes can be added on a site at any stage of the site and can be removed at any stage. You can add multiple recipes on a single site. Sounds cool, dunnit?
Distributions can only be installed at the beginning of the project; require lots of developer technical skill to install, and are difficult to upgrade. Recipes will be easier to use; can be added on existing sites or also at the beginning of the project; can be removed at any time unlike a distribution; are for site builders and developers alike unlike distributions that are developer-centric.
Recipes were to be called Starter Templates so you can think of them as starter templates. You want to build an event website so you find an event recipe and install and you have a functional starter template you can expand on.
How easy will it be to upgrade from Drupal 9 to Drupal 10?
One of promises made during the launch of Drupal 8 was a commitment to easy upgrades. Upgrading from Drupal 7 to the new Drupal 8 at the time was more or less a rebuild of the site and was damn painful, difficult and costly. To assuage the pain Drupal users were promised that would be the last painful upgrade they will do, and that from Drupal 8 it will be easy upgrades forever!
This was proved in the Drupal 8 to Drupal 9 upgrade. It was the easiest upgrade in the history of Drupal as at then. You didn't need to rebuild sites or change themes or spend days to upgrade a site. It was fairly an automated process and was quite easy (in the Drupal context).
Drupal 9 to Drupal 10 will be easier than Drupal 8 to Drupal 9 upgrade. The upgrade tools were refined and improved on, to deliver a yet easier upgrade process thus becoming now the easiest upgrade in the history of Drupal! The process is now more automated both for contributed modules & themes and custom modules & themes.
This video explains better,
This is the easiest major version upgrade process in Drupal.
Like I mentioned at the opening, Drupal users have 11 months after Drupal 10 release, to upgrade to Drupal 10.
3x more modules are already ready for Drupal 10 than were ready for Drupal 9 on the eve of Drupal 9 launch. This means most sites would likely have all the modules they are using Drupal-10 ready early enough, and would mean many sites will upgrade early on time as their sites will be D10 ready early on time.
If your site is still running Drupal 8 then you must upgrade it to Drupal 9 before upgrading it to Drupal 10.
Wrapping It Up
In closing, the outstanding fact from all these is that Drupal is getting easier. Drupal 8 was peak hardest and now it's becoming easier and easier to own, use and manage a Drupal site. After Drupal 8 looked like Drupal was distancing away from site builders and small sites, the subsequent initiatives and roadmap has shown that Drupal is lowering the ladder to take site builders and small sites along it's ambitious journey. It manages to uphold the standards, integrity and quality it is known for, and at the same time, lower the ladder to take 'everybody' along.
By the way, Drupal 10 was finally released on 15 December 2022.
