The latest version of Drupal is due to be released in December 2022, and it’s time to start planning for the update. So, what new Drupal 10 features can you expect?
Note: As of the 14th of December 2022, Drupal 10 has now launched. We will continue to keep you updated on all the latest developments in the world of Drupal.
In 2021 Dries Buytaert, the founder and lead developer of the Drupal CMS, presented his road map for Drupal, which was backed by extensive research. He identified several strategic goals that would culminate in Drupal 10:
- Drupal 10 Readiness: Updates required for the non-Drupal components that Drupal use that are reaching their end of life.
- Project Browser: Making it easier for non-experts to find and install new functionality on their websites.
- Automatic Updates: Keeping the code that runs the website updated and free of security vulnerabilities as a matter of course.
- Easy out of the box (EOOTB): Removing some of the barriers that made people lean towards Wordpress, whilst retaining Drupal’s power and flexibility that made people lean away from Wordpress - the best of both worlds.
- Decoupled Menus.
These initiatives are “coming in Drupal 10”, but all are in various stages of completion. Some are already complete and present in Drupal 9.4, some will arrive when Drupal 10.0 launches in December 2022, and for others, expect to wait for Drupal 10.1 or beyond.
Drupal 10 Readiness
Drupal core is heavily dependent on other awesome open-source projects, such as Symphony, CKEditor and, of course, PHP itself. These all have their own road maps, constantly improving because the web does not stand still. As these products change from version to version, Drupal needs to update accordingly. That’s all Drupal 10 Readiness is about.
The changes may be as simple as replacing some deprecated function calls in the case of Symfony or PHP, or the more wholesale update that’s been required for CKEditor 5. The 6-month delay in the release of Drupal 10 is largely down to the need to develop a migration path for content created in CKEditor 4 to CKEditor 5.
Project Browser
Drupal is built with a core solution, on to which you bolt additional modules. Some of these modules are within core, but many thousands more are provided by the Drupal community (for free!).
You can also create your own modules. Whether you call these “projects”, “modules”, “plug-ins” or “add-ons”, it's currently hard to find one that matches specific requirements, or that you might want to include in your website if only you knew it existed. Seasoned Drupal developers “just know”, but for small site owners this is a voyage into the unknown, or, even worse, a dead end that has them turning away from Drupal almost immediately.
The Project Browser aims to fix that. Taking a leaf from other content management systems, you will be able to browse modules by category. When we’re looking at using a new module, one of the best metrics is how many others are using that module and generally, how mature and well supported that module is. You can sort the list by this key metric. You will eventually be able to install these modules at the click of a button.
Version 1.0.0-alpha1 of the Project Browser currently looks like this. There are category filters down the left hand side to help find a module that might do what you want, a title filter at the top to find a module you know the name of, and a host of other ways to find new modules to download and install.
There has been talk of some form of curated recommendations in the final solution. The interface is quick, and the data used to drive the page is the same as that which generates the module pages on Drupal’s own website.
Version 1.0.0-alpha5 of the Project Browser.
The current version of Project Browser just gives you the manual instructions for including and enabling the module. Future versions will make this all happen within the browser, so there’ll be one-click installations. Making sure that’s done in a secure and safe fashion is complicated, and is a work-in-progress. We’re not sure what will be available when Drupal 10 is launched, but I feel it won’t be that full solution.
For corporate users, expect to see this facility turned off on your live website and developers continuing to use a manual process. Ongoing development projects should have a well-defined product workflow that includes development, testing, quality assurance, user acceptance and source code version control. I wouldn’t want a large client of mine installing a new module because it looked cool, only for it to break their website.
Automatic Updates
Drupal’s security group is second to none. Once a vulnerability is identified (even on the least-used modules), they work with the module maintainers to fix and then release a patch, which is then made available through various mechanisms. However, the sad truth is that the vast majority of websites remain unpatched. Site owners are often in ignorant bliss that their site is no longer as secure as it was when it was first launched all those months ago.
Cyber-Duck have developed a solution that allows us to monitor all our client’s sites from a single dashboard. In a few seconds, we can check whether any sites use the vulnerable module for which a security patch has just been released, and plan to hotfix those sites as required. It’s a huge time saver for an agency the size of ours with dozens of Drupal sites to maintain. Cyber-Duck have plans to make this an open-source solution, so watch this space.
Any company that is reliant on the availability and data integrity of its website, and who recognise the impact of web-vandalism on credibility, will have some sort of support process in place to make sure sites are regularly updated with the latest versions of Drupal core and contributes modules. Keeping things up to date greatly reduces the risk when an immediate security patch to one of those components is required.
Doing this automatically has complexities that should not be underestimated. Checking a site after automatic updates, and then automatically rolling back any database or code changes, is difficult. The current aim of the Automatic Update initiative is to apply “Drupal core patch and security releases only”, and it’s not clear whether that includes all security updates or just those from Drupal core and core contributors. Non-security patches and non-security contributed module patches will be looked at again in the future. This may not be the magic wand that was expected when first announced, but it’s certainly a step in the right direction.
Again, for corporate clients, developers will turn this feature off for the same reasons already given.
Easy Out Of The Box
The EOOTB initiative is all about making Drupal easier for casual users, but the improvements will also make it better for seasoned users. The initiative is the sum of many smaller initiatives, so let’s jump into each one.
New Themes
The theme is the “display layer” of Drupal, and is the first thing a user sees when they try Drupal. The old default themes in Drupal did not offer a great first impression, and many simply swiped left!
Two new default themes have arrived: Claro for users and Olivero for administrators. Both are modern in every sense of the word. They both look great, work well across multiple devices, and pride themselves on meeting and exceeding WCAG accessibility guidelines - something that Cyber-Duck have a team dedicated to.
Claro is a far cry from the old Bartik default theme for users.
Can’t wait for Drupal 10? No problem! These themes have already been available for a while, and Drupal 9.4 sees them considered fully stable and now implemented as the defaults.
Easier Custom Themes
Despite Claro being the default user theme, the whole purpose of Drupal’s theme layer is that it can be replaced and customised. Most sites will see the default front end theme replaced – we don’t want every Drupal site to look the same, after all. Replacement themes are available from many places: some free, many for a small fee, and of course, you can create your own from scratch or base it on an existing theme, such as the very popular Bootstrap.
Drupal 10 will make the creation of custom themes easier with the adoption of a new starter kit theme. The core Classy theme was frequently adopted as a parent theme, from which site specific custom sub-themes were added to. This meant that the Classy theme stagnated, because any change could have broken thousands of custom themes using it as a parent.
The new starter kit solution gives you a starting point which you can rename and create your custom theme from directly. That’s the same approach we started using at Cyber-Duck about 3 years ago – we even called ours the “Starter Kit”. Great minds...
CKEditor 5
With CKEditor 4 end of life, and with CKEditor being 10 years in development, the new default WYSIWYG for Drupal will mark a major change in one of the most used components by content creators. While the user interface is a little different, most of the functionality will remain familiar.
An interesting change for Drupal’s use of CKEditor is that the H1 tag is disabled within the CKEditor default configurations. You should only have one H1 per page, and that’s the page title, which Drupal looks after. There is no place for an H1 tag in your content, as that breaks SEO and confuses screen readers.
You can also allow the user to reverse the order of an ordered list and allow them to specify the start index of an ordered list. All subtle, but useful changes.
The major challenge with the move to CKEditor seems to have been the migration path of CKEditor 4 content to CKEditor 5 compatible content. Drupal are working hard in collaboration with the CKEditor team to remove this major blocker.
After changing the “Full HTML” text editor configuration to the currently experimental CKEditor 5, this is the default editor experience. Sure, it looks a bit different, but once everything is configured correctly, I don't expect users to have problems getting to grips with this compared to current version if you’re replacing like-for-like. I’m interested in seeing what additional goodness CKEditor might bring to the content creation party. More info on the new version of CKEditor can be found here.
The default editor experience of CKEditor 5.
There is a new API for adding theme specific styles in CKEditor 5, which themers will need to be aware of because CKEditor 5 is no longer provided via an iFrame.
Media and Layout Builder initiative
Media Library and Layout Builder are not enabled by default in Drupal 9. The Drupal 10 EOOTB initiative aimed to change that, but the exact requirements were not well defined. While both these Drupal 9 components are well used and considered stable, not much work has been done to define what changes are required for Drupal 10 at this time. The Media Library is pretty good, but some tweaks would be nice. This very much looks like a work in progress for Drupal 10, with no significant changes expected at launch.
The following exists as a “must have” list for the Media initiative and we’ve not seen any evidence of them being worked on as yet, so there’s nothing available to show you at the moment.
- Clear up the confusion around media entities, files and images because files and images should already be media entities.
- Clear up some confusion about where the ALT text for images comes from.
- Provide tools to manage transcriptions and captions/subtitles for local video and audio.
- Make media compatible with content moderation.
- Provide a facility to convert files and images to full media entities.
It’s a similar story for Layout Builder. Many sites still use the non-core Paragraphs solution for layouts, and Layout Builder itself has some drawbacks. You generally need to load a few contributor modules to make it fit for purpose. As it stands, the initiative focuses on using Layout Builder for full-page layouts, rather than just page content layouts. But many in the community think some of those contributed modules simply need to be brought into the core solution to improve first impressions. Drupal can then focus on making the core solution better. Again, don’t expect much in the way of change for Drupal 10.
Field Layout
The Field Layout module, which “allows users to configure the display and form display by arranging fields in several columns”, is experimental and already available in D9.4. Think of it as Layout Builder, but simplified and for content creation forms.
To look at this module, visit the “Manage form display” of one of your content types. At the bottom you’ll see a new “Layout settings” field-set that allows you to define the layout of your form.
Once saved, you can move the content type fields into whatever area you like. Here the body field has been dragged to the “Second” column of the two defined above.
However, just enabling and configuring it does not currently give a very good user experience. It looks like you’d need to implement additional theming as part of your admin theme, so you may need to operate a sub-theme of Olivero to make the most of this new feature for now. I would expect both the Claro theme and Olivero theme to support this new markup, but at the moment, this doesn’t seem to be the case.
Entity Permissions Tab
Any administrator who has looked at the permissions tab for Drupal will know it can quickly become a monster. There are several great modules that can be used to improve it, but one small improvement has already been released in Drupal 9.4. This is a new entity permissions tab, giving easy access to all the permissions settings that relate to each content type or taxonomy.
Access to those frequently needed permissions to content types are now all in one handy place - right against that content type.
Image Lazy Loading
Lazy loading for images has been available for some time in Drupal, but Drupal 9.4 introduces the ability to configure it for each image, making it even more user friendly. Lazy loading means images are only downloaded when they near the browser viewport, which vastly improves the perception of page load speed for users.
You can now configure lazy loading for every single image.
Decoupled Menus
I’m not shy in saying that this initiative has always been the most confusing to me.
The initiative’s goals are to:
- Give Drupal the best JavaScript developer experience of any CMS.
- Make Drupal the best decoupled CMS overall.
The first goal will be achieved by establishing a repeatable pattern for building, shipping and maintaining easy-to-use, high quality JavaScript packages. The second goal is to make sure Drupal provides an excellent non-developer experience.
That sounds quite simple, but it’s new for Drupal, and the challenges are significant. Instead of taking on this challenge as a large project, it was decided to trial it with a single component and make sure it was done the right way to repeat it again for additional components in the future. This first will be an official JavaScript menu component; hence “Decoupled Menus”.
As always, Drupal aims to integrate with existing libraries and components, making use of components that already exist and concentrating on integrating those well into Drupal. The example menu shown here is using React Bootstrap Navbar component.
This simple React menu is a big deal for Drupal’s future direction.
This seems to be a back-end module for serving up menus in JSON file format, and a front-end module for displaying those menus on the Drupal website. The benefit here is that non-Drupal front-ends could consume that JSON file to create their own menus.
This first initiative concentrates on the creation of a custom JavaScript menu solution. It’s supposed to be the first of many that will lean towards the creation of more bespoke decoupled JavaScript solutions for different elements of Drupal.
Beyond that, I’m still at a bit of a loss!
To sum up Drupal 10...
Drupal 10 is but a milestone on Drupal’s journey. Drupal 10.0 will be exactly the same as Drupal 9.5, but updated so that all the components around it that are soon end-of-life have been replaced. Much of what was expected for Drupal 10 is already available in Drupal 9.4, and some of what we might have expected at launch may not arrive until Drupal 10.1 or beyond.
Next Up: Drupal 11
We even know a little of what to expect from Drupal 11. That will focus on those non-developers who use Drupal daily, turning them from content creators into power users, able to perform many tasks that traditionally required Drupal developers. Developers welcome this, as once we’ve built a solution clients can look after themselves, we can concentrate on pushing the functional boundaries of Drupal’s capabilities. Expect Drupal 11 in late 2024.
Think Drupal is not for you?
Many people have tried Drupal and didn’t like it. Some of that experience is from the deep history of Drupal 5, 6 and 7. But things have changed. Drupal 8 was a massive shift. Drupal 10 is an unapologetic domain-grab from Wordpress, while offering so much more.
Stuck with the retro experience of Drupal 7? We can help.
If you’re still stuck on Drupal 7, you really are missing out, and your website’s longevity is severely limited. Moving away from Drupal 7 is a significant process; the migration from Drupal 8 to 9 is easy, and with Drupal 8 already end-of-life, you should already be on Drupal 9. Drupal 10 arrives in December 2022, and the migration from Drupal 9 should be relatively painless if you have kept your Drupal 9 site up to date.
With the new release date coming up, and all the new Drupal 10 features that are listed in this article, now is the perfect time to update to Drupal 9 or 10. Our new, updated Drupal white paper will get you up to speed on the latest Drupal happenings, help you understand why migration is so crucial, and let you know how we can achieve a smooth, effective migration process while optimising the ROI for your business.
You can also get in touch if you’d like to discuss migrating an old site, or want to see the power of Drupal – we'd love to chat.
