Drupal is an ever-evolving and improving platform and part of these improvements includes the strategic initiatives. These help to guide the community in their efforts towards making Drupal the stand out product it is. These initiatives are decided upon by a number of factors, but high on the agenda recently has been improving the experience for people coming into the Drupal world.
I thought I would look into these initiatives and see what sort of awesomeness is on the horizon for Drupal.
The administration interface for Drupal hasn't seen much change since Drupal 7. Indeed, the Drupal 8 administration interface is just a port of the Drupal 7 theme to Drupal 8. A revamp of the existing Drupal administration theme has been on the cards for a while, and the Claro theme is the fruit of this labour. A lot of time was been spent just looking at the new theme from a design point of view. Making sure things like font sizes, icons, buttons, fields, messages and even just element spacing were all taken into account before work got started on the theme.
Accessibility has been at the forefront of the efforts to build Claro and it fully supports WCAG 2.0 and ATAG 2.0. This makes Drupal one of the most accessible CMS systems on the market.
If you're curious about what Claro looks like in Drupal then the good news is that you can try it out right now. Claro is available in Drupal 9 as an experimental theme so you can activate it on your site. There are one or two little things that are clearly being worked on, but the theme is mostly complete and it looks fresh and modern.
If you're interested in getting involved to finish off Claro then you can view the issue queue to stabilize Claro and start making contributions now.
If you've come into work on a Thursday morning in the knowledge that your day is already ruined by pushing through Drupal core updates for your clients then you are not alone. In case you weren't aware, Drupal's security team pushes out security announcements on a Wednesday night (well, night time for the UK) and so Thursday mornings can sometimes be spent triaging those updates to see if they are critical enough to warrant immediate action.
I can only remember two occasions where the security issues have been so critical I have needed to spend Wednesday night applying patches to sites. Thankfully, the security team has forewarned everyone before the event so we can plan ahead accordingly.
This automatic updates initiative is intended to take some of the pain out of the critical updates by simplifying the update process for Drupal core. Included in this are site readiness checks, code signing and verification of updates, and potentially an A/B bootloader so updates are done in a separate location and switched over if they are good to go. This doesn't include minor or major version updates, just the security releases and also doesn't cover contributed project updates.
Rather than being focused at large Drupal hosting providers who already have sophisticated systems in place to roll out security patches, this initiative is instead aimed at the small to medium site owners. The idea is to cover those who install Drupal and don't touch it much.
The team behind this initiative have a start by creating an automatic updates Drupal module that covers a lot of the functionality needed. The currently released version of this module will show you pending security updates, report if your site needs them and can support the changes and even apply the updates. This module is currently being ported to Drupal core and so updates should be simpler to manage in the future.
Ever since my first steps with Drupal 8 I have realised composer is essential. It is, however, perfectly possible to run Drupal without composer using the pre-build zipped version that you can download from drupal.org. Although Drupal 8 and now Drupal 9 are built using composer and many contributed module require a composer-based approach, it isn't officially supported by Drupal. In fact, many of the 'best practice' composer setups were created outside of the Drupal core systems.
The idea behind this initiative is simply to bring in-house some of the great tools and initiatives created to make Drupal work with composer. Essentially, making composer a first-class citizen of the Drupal world. Key to this is not leaving preventing the use of the pre-built zipped version of Drupal so embracing composer does not lead to a barrier to entry.
Although the configuration system in Drupal is brilliant, it's not without problems and limitations. This initiative is intended to solve those issues. Already included in this is the ability to install a site from an existing configuration, which was actually introduced back in Drupal 8.6.
Next on the radar for this initiative is to add environment-specific configuration to the core of Drupal, which handles much of what the Configuration Split module is used for. This will also include some improvement to the way in which configuration is imported and managed, which should make it easier to spot, correct and manage configuration clashes within Drupal.
The configuration management system Drupal has is already a standout feature for the CMS, so these improvements will strengthen that position.
Drupal menus tend to be 'hardcoded' into sites; being heavily reliant on pre-processing steps or special styles in the theme to make things work. The problem is compounded by the fact Drupal's HTTP APIs have no support for exposing menu links, which means that front-end developers have to rely on menu code produced by the back end. I have often battled against Drupal's menu systems to inject the correct classes or produce a decent sub-menu.
So far, this initiative is in the early stages of development, but there has been a lot of thinking around how this will work though. There is plenty to read about here.
Having decent documentation can make a project a success and Drupal has (admittedly) been a bit lacking in that department. You could always look at what a template file is or what a node is, but how they worked, how to use them and best practice approaches haven't always been there.
This initiative is looking to correct the documentation found on the drupal.org site, as well as a better help system within the Drupal site itself. A documentation module has been available in Drupal core since version 6, but as this is more developer help I have always found this tricky to manage. Allowing clients access to this tends to scare them as it will talk about managing Views or database logging. The information it contains is quite short as more effort is generally put into the documentation on the drupal.org site.
The new help topics module will address some of this by creating a better way of managing the help text in the site. This module is already available to install in Drupal 9 so you can give it a go now. Having a documentation system driven by Drupal itself (and twig templates) makes sense and I can see this system being used by agencies to embed help docs within the sites they are building.
The general state and quality of the documentation on the Drupal website have vastly improved. Mostly thanks to the continuing efforts by the documentation team and the community in general. A few years ago it was common to see a page of documentation followed by a bunch of comments that were much more helpful than the documentation itself. This trend appears to have reversed and the quality of the docs themselves is really good.
But Drupal 9 has only just been released?
True, but thanks to the groundwork done in Drupal 8 to make the system fully tested and modular it means moving to the next version of Drupal is just a case of updating some packages. I have done a couple of upgrades from Drupal 8 to Drupal 9 and the only major stumbling point was making sure that PHP was at the minimum version requirements. The upgrade process is pretty simple, assuming that all of the needed modules have also been updated. This is in contrast to upgrading from Drupal 7 to 8/9 is a major undertaking and often involves a migration of some kind to convert data from one format to another.
Drupal 10 is due to be released in 2022 and this initiative is about flagging and removing deprecated code in Drupal as well as encouraging module developers to also remove the same deprecated code. Generally, the contributed space has been responsive to removing deprecated code, helped in part by an automated scanning and issue creation system that will flag any problem code to module developers.
When Drupal 8 was first released the support for embeddable media and a media library was quite noticeably lacking. This space was filled for a couple of versions by a contributed media module but since Drupal 8.6 media has been part of core. Every new release of Drupal since 8.6 has seen something new from this initiative culminating in a robust media library system. Uploading media (including external media like YouTube videos), viewing that media in a library, embedding the media into copy has never been easier thanks to the fantastic efforts of this initiative that has made this possible.
There is, however, some way to go and the media initiative is not finished. Just looking at the roadmap of issues for the media initiative shows they have some great ideas and interesting problems to solve.
Just as the administration theme is seeing some much-needed love, the default front end theme for Drupal is also getting a revamp. The Olivero theme is the first new front end theme to be included into Drupal since Bartik which is technically a port of the Drupal 6 theme. Olivero is a really nice looking theme with excellent accessibility standards support and a component-based CSS setup.
The good news is it's already part of Drupal 9.1. The initiative is now looking to stabilise it and make it the default theme for Drupal 9.2. This should really help Drupal stand out for project evaluators and will be a good starting point for many users to build their own themes. If you don't want to use Bartik, then building everything from scratch is the way to go, apparently. I hope this effort helps that situation.
Last, but not least, is the Workflow initiative. I talked about this initiative in my post about content deployment as the Workflow module was born of this initiative. The aim is to allow content editors a better experience when publishing multiple content items at the same time. The module itself is just the start of this as there are also plans to bake content deployment into Drupal itself, which would be awesome to see.
The Workflow module has been available in Drupal for at least a year. Since being included it has been through some changes and now appears to be nearing full release. I can see why this module has taken a while to see fruition as there can be a lot of moving parts in publishing multiple Drupal items at the same time. Some of the work in this initiative has also been focused on allowing things like blocks and taxonomy terms to be revised.
There is a lot of work being done in Drupal, and these initiatives are tied together under a common goal of making life easier for people using or developing with Drupal. This actually ties in with what has been found in community surveys and market research done by the Drupal Association. When Drupal 8 was first released many of the initiatives were geared towards making Drupal an enterprise-level product. This has somewhat left behind the small to medium scale users who just want to use Drupal to publish content. This is why many of the initiatives are either looking at improving things on the front end or allowing users to get on board as easily as possible.
You can help these initiatives reach their conclusion by getting involved. There are some very clever people managing these initiatives, but there is a lot of work to be done to get these over the line. If you're interested in having a go, take a look at the initiative links I've posted above, look at the issue queues and get involved. I'm sure they will be delighted to have some help with these projects.