In the past couple days I've gotten two different questions regarding building functionality out in WordPress. This seems a bit...weird with timing, given that Drupal CMS just launched three days ago!
We've long been Drupal advocates here at Freelock. While we manage some WordPress sites, we hear complaints whenever there's work to be done on them, compared to current Drupal sites. I've written several posts comparing Drupal with WordPress, but with the release of Drupal CMS, it's a good time to revisit.
Why Drupal CMS?
Drupal has a reputation for being hard to learn. There's a quote I'm finding attributed to Jeff Eaton:
Drupal makes easy things hard, but hard things easy.
-- Jeff Eaton
Drupal CMS represents the efforts of 300+ people working over the past 8 months to make the easy things easy. And the result is pretty impressive.
The result? A full-featured content management site that can be spun up in minutes. Pre-configured with privacy features, publishing/approval workflows, scheduled posts, media management that lets you place images that look great across devices from mobile to 4K screens, and much, much more.
Using DDEV as a generic development platform, you can spin up a dev site in a matter of a few minutes with 3 commands. Installation is two pages - one to select the "recipes" to install, and one to create your initial user account and password.
From there, you have a regular Drupal site installed -- but pre-configured with a bunch of things that normally you would need an agency (like us) to configure, things that Drupal experts know to do, but people not familiar with Drupal's ecosystem of modules and common practices would have no idea they even need.
What's new in Drupal CMS
Drupal CMS is regular Drupal Core, with a bunch of widely used/best of breed contributed modules, and a collection of recipes to jump-start configuration of a bunch of different things. Compared to starting a Drupal project from Drupal Core a week ago, here's what you get in Drupal CMS that didn't exist before:
1. Recipes
The Recipe system is the cornerstone of Drupal CMS, which makes heavy use of it as really the first effective use. However, it's something that actually went into Drupal 10.3 core, which released in June 2024. It was experimental then, but it is really the foundation of what makes Drupal CMS possible.
Drupal 7 had a module called "Features" which was intended to do this kind of thing -- create a set of configuration you could easily move to another site -- but that ended up being heavily used for managing configuration and bundling configurations into "install profiles." Install Profiles have also been around for ages, and have been successful for creating single-purpose sites based on Drupal, but these sometimes become very tricky to upgrade, and leave a lot of remnants around if you want to transition to more standard Drupal site management.
Recipes, on the other hand, live up to the promise of features -- they can be easily installed on any current Drupal site, and once installed, you're done with the recipe -- from then on, you have a regular Drupal site that can be managed like any other.
2. Project Browser and Automatic Updates
Project Browser is meant to help people unfamiliar with the Drupal ecosystem find, install, and configure recipes and modules. For people familiar with Drupal, this isn't necessarily a big deal -- but for those just wanting to see what it can do, it's a huge benefit, making so much more of what Drupal can do discoverable.
Along with Project Browser comes some automatic update functionality.
Both of these are key features for people getting started with Drupal who do not have strong server administration skills. As a vendor that makes security and reliability a high priority, we don't plan to use these, and keep them disabled on production sites -- we actively manage changes and store configuration so we can roll back functionality, detect when a site has been compromised, and more -- these are features that go against all the systems we've built to make sites safe, secure, and reliable.
But these features aren't for me -- they are for people who want to try it all out themselves without a Drupal shop at their beck and call. And they make Drupal CMS much closer to the administrative burden that WordPress has, with its plugin browser and auto-updates -- when we manage WordPress, those features are disabled on our production sites as well, for the same reasons.
I still don't recommend using these on a production site -- but it levels the playing field between WordPress and Drupal, when it comes to "easy to administer".
3. Polish
This is the real improvement Drupal CMS brings to Drupal -- thousands of little bugs fixed to just make the whole ecosystem better. Modules that have been in beta status for years now have full stable releases, and security team coverage. Far less error messages, whitescreens, or weird behavior -- there's still plenty of bugs like there is in all software, but the user experience for a content editor has seen a ton of improvement.
A lot of this are things built in Recipes. There's a dashboard with recent content, top tasks, announcements, which you can edit to add whatever else is useful. There are ECA models set up to redirect users in ways that make better sense after creating content, creating a new account, logging out, configuring search.
Drupal CMS uses an admin theme called "Gin", which is the same one we've put on most of our client sites for years. There's a new "Navigation" module which moves the toolbar to the left (like WordPress, but far better organized, especially after you have 50+ addons). There's "Coffee" to provide a fast lookup for admin tasks. And it all looks and works great!
What's missing?
Ok. There is one huge missing feature you'll notice, when comparing Drupal CMS to WordPress: Themes. WordPress has long been the favorite of designers, and there are thousands of themes available to install with a few clicks. Drupal has nowhere near as many, and Drupal CMS doesn't even have any way to browse what's available -- you need to poke around drupal.org to find something you can use quickly -- and then go to command line to install it (I'm not sure why the Package Browser doesn't install themes).
The stock "Olivero" theme is decent, and there are themes like Solo and Tara and a bunch of others available when you browse themes on Drupal.org, but the breadth of what's available that looks good out of the box is nowhere near the selection of WordPress.
That said, how you style both WordPress and Drupal is changing a lot.
In WordPress, the push has been towards using the Block Editor (Gutenberg) for everything on the site, and having much less in the theme. WordPress has long had a bunch of different competing theme systems, most of them requiring a license, that embed different page builders, different widgets, and often themes are bundling actual functionality that you lose when switching. This is part of the mess of WordPress -- there's a lot of different ways of building WordPress sites, and often they don't work well together -- sometimes getting functionality you need means rebuilding with a different theme.
Meanwhile, in Drupal we're moving towards Component-based systems, Design systems, and using elements from the broader web community. WordPress with Gutenberg is doing the same thing -- and design systems like StoryBook or PatternLab or DaisyUI provide building blocks for both WordPress and Drupal -- but these take some work to get styled and built, not something you can use just out of the box. (Though you might check out the US Government design system, which has a pre-built theme for Drupal).
The other major initiative for Drupal CMS did not make it in time for the launch -- a whole new "Experience Builder" (XB) that takes managing components on a page to a whole new level. WordPress has Gutenberg, which is fine for managing individual pages. Drupal has Layout Builder, which is great for managing page templates and putting a lot of what used to be custom theming into the hands of admins. Drupal can also use Gutenberg -- if you like using that in WordPress, you can have it in Drupal too. You can read why we think Layout Builder is a better choice for a lot of scenarios -- but Gutenberg does have some advantages. XB promises to greatly improve on Layout Builder with some of the improvements Gutenberg has made, while keeping the structure that makes it work on sites with thousands of content items.
What's great
The best part of Drupal CMS? The recipes that have been built up for Drupal CMS can be easily applied on existing Drupal sites, as long as they are up to date.
Some of the core recipes are things we're going to focus on with our monthly effectiveness program -- this month's Privacy Tune-up includes applying the Privacy Recipe from Drupal CMS as a starting point!
There's a recipe for installing an Artificial Intelligence chat agent that can actually create new content types and fields for you. There's a Search recipe that jump starts setting up advanced search with autocomplete. There's an Accessibility recipe that configures a tool that flags issues for editors to help your site pass accessibility testing. There's a Media recipe that configures a bunch of responsive image styles and makes them easy to drop into your content as you write.
All of these are things built for Drupal CMS -- but the results add value to every existing Drupal site!
Drupal CMS is Drupal, which has always made really hard stuff easy -- or at least possible. Now most of the easy stuff is easy, too!
If you haven't checked out Drupal in a while, now is a great time to do so! And if we can help in any way, please reach out.
Add new comment