What can a WordPresser learn from Drupal CMS?

Drupal CMS dropped earlier this month to quite a bit of fanfare and discussion. I was surprised at how many eyes from the WordPress ecosystem have turned to Drupal for the first time in a long time. I took this as an opportunity to dig into Drupal CMS and was pleasantly surprised. Here’s what I learned.

What is Drupal CMS?

Drupal CMS is essentially a thin wrapper around Drupal core that adds "contrib" modules and configuration that simplify the user experience of installing and managing Drupal. 

Image

Fundamentally on install, you’re still using Drupal 11. However, that wrapper lowers the entry barrier for using Drupal to manage your content. Seasoned WordPress veterans will relate. Many of them may be used to the WordPress admin dashboard structure – with its sometimes confusing array of panels, menus, buttons and notices. They’ve learned to tune out the noise. But new WordPress users who are unfamiliar with experience can easily be overwhelmed by too many options.

User interfaces are hard, and even if you’re like me and used to the WordPress admin, you might find the Drupal admin interface even more frustrating and confusing. This is an important use case that Drupal CMS is trying to solve: the goal is to make it easier for non-technical users to do normal stuff in Drupal. That includes me, because most of the time when I’m inside a Drupal site, I barely know what I’m doing.

When Drupal founder Dries Buytaert demoed Drupal CMS (formerly known as Starshot) at DrupalCons, he primarily focused on four important areas. On the technical side, he introduced Recipes and Experience Builder. For users, he set out to improve the Drupal.org website, Drupal CMS marketing materials and documentation, specifically targeting new or newer users. He was quick to note that Drupal CMS is not a Drupal fork; it’s a Drupal evolution to make it easier for people to get started.

Digging into the install process

Since I wanted to see what the fuss was all about, I spun up a Drupal CMS site on Pantheon using the Terminus site:create command. With WordPress, I’m used to an installation form that asks for the site title, tagline, username, email address, password and whether to allow search engines to index the site. For a new user, this can be overwhelming and it’s unclear which questions are required and which you can skip. 

The typical Drupal installation process follows the same format. But the Drupal CMS setup process is distinctly different. It begins by asking you “What type of site are you building?” Honestly, this was almost intimidating. What content did I want on this site? This step forces you to think about your site goals right off the bat. The installation process then customizes the build based on your answers.

Image

Under the hood, you will select a few initial Recipes. In Drupal CMS, Recipes correspond to curated collections of modules (and configuration) to add specific functionalities like SEO, search or AI. Right now during installation, there are Recipes to handle specific content types you picked. In the future, this might also include other Recipe types like accessibility or analytics. 

In the WordPress context, imagine choosing from a list of post types on install that will be automatically added without any additional code. This isn’t exhaustive nor is it final – you can always add more content types or Recipes after the install, but this could give you a head start, especially if you’re just looking at creating a simple blog or event site.

I’m focusing on the Drupal CMS install process because I think it solves an important problem that I don’t know if  WordPress has figured out: first impressions. The Drupal CMS install process isn’t a single form where you dump all your information. Instead, it guides you through setting up your site and only asks you for one piece of information at a time. When you’re done setting up, you see a progress bar and descriptions of what’s happening. Even if you don’t know what it’s doing under the hood, it builds trust by being transparent about the process.

Image

Layout Builder and Experience Builder: what the difference?

Once the installation is done, you’re dropped directly into the admin dashboard. The new Drupal dashboard is similar to the WordPress admin. You’ll find landing pages created for the content types (your WordPress post types) chosen during setup, an announcement widget and a familiar left sidebar. What I really like here is the Top Tasks block, which gives you quick access to common administrative tasks. 

Image

But the best thing of all is I can change everything in this dashboard.

The Edit Layout button at the top will do the magic. You can customize this welcome screen however you want. In WordPress, this would have to be done mostly by using a combination of custom code (to add new widgets or change existing ones) and the Screen Options tab (to hide existing widgets). 

Image

This layout editor uses Drupal’s Layout Builder, but in the future, Drupal CMS will use Experience Builder. Dries has made it clear he wants Layout Builder replaced with something friendlier to content editors. That will be Experience Builder. Experience Builder is React-based like Gutenberg, and has taken some user experience lessons from Gutenberg as well.

Layout Builder and Experience Builder are designed to be modular in the same way as Gutenberg, but you don’t need to know JavaScript to build components (think blocks) for Experience Builder and Layout Builder. Instead, components are primarily built with twig templates, CSS and YAML files. In the Drupal admin, Layout Builder lets you tweak any of the available components. You’ll see a similar interface if you decide to edit the layout of any piece of content.

Image

Let’s talk about AI

While it’s not a core component, AI is seen as a fundamental function to lower the entry barrier for Drupal with Drupal CMS.  It’s played a role in the recent Driesnotes, which function similarly to Matt Mullenweg’s "State of the Word" keynotes at major WordCamps. There is an AI Assistant Recipe that can be installed with Drupal CMS. Once installed, and an API key has been added, a Drupal Agent Chatbot starts to follow you around in the Drupal admin. 

Image

For someone like me who doesn’t feel like they really know what they’re doing yet with Drupal – and who’s already using AI instead of search engines for figuring out how to do new stuff – having this Drupal Agent Chatbot is super helpful. Even if the only thing it did was give me instructions, so I wouldn’t have to switch tabs to OpenAI or Claude, would be great! But that’s not all the Chatbot can do. It’s designed to be able to make changes (like creating content types, modifying configurations and adding taxonomies, etc.) on your behalf, sometimes without you asking it to do so explicitly. 

For example, I asked it to create a Services content type and it just…did it for me. Imagine having a similar agent in the WordPress admin that could help you optimize your SEO plugin configuration, check for accessibility issues, help you build complex Gravity Forms, or design pages with Advanced Custom Fields or Gutenberg. It is a huge leap forward for usability and it’s something that I have yet to see WordPress do in a way that is as intuitively integrated into the CMS.

Image

Takeaways

When I have tried using Drupal in the past, even after joining Pantheon, I’ve always felt overwhelmed. I know how to do all of these things in WordPress, but their Drupal equivalents have often been a vastly different workflow. Learning new things is hard. For a long time, the Drupal learning curve was illustrated to me with this old meme:

Image

I appreciate Drupal’s intentional approach to make the CMS more usable for people who don’t already know how to use Drupal — right from the installation screen. Far more people fall into that category than we know. I’m one of them. I was really impressed just by the installation process. Even if it’s more screens, the fewer decision points are a welcome change. 

In the past few years, the concept of “canonical” plugins has been discussed in the WordPress ecosystem, but what does that mean exactly? As it stands today, it does not mean that there is a single canonical plugin for all things SEO, or analytics. For an agency or a single individual on a marketing team trying to spin up a site quickly, the infinite possibilities of the WordPress repository can create analysis paralysis. A key part of the industry of WordPress site builders is so users have someone who is simply familiar enough with the ecosystem to have opinions about what’s good or what to look for to determine what’s good. Recipes combines the idea of “canonical plugins” with common configurations so all you need to do is install the Recipe and go. I love this framework and if there was only one thing that WordPress should borrow, it’s Recipes.

The idea of “democratizing web publishing” has always been about lowering the bar so more people could join the club. Drupal CMS now allows us to have a smoother onboarding experience and even out that steep learning curve. The AI Assistant, for example,  transforms that curve into a speed bump.  Providing powerful tools to create content easily is what defines democracy in web publishing. I’m very interested to see where Drupal CMS goes next.

 Watch the livecast with major Drupal Contributors we recorded on the day of the launch!