Drupal CMS: It's About Time

Earlier this month the 1.0 version of Drupal CMS was released. It enhances Drupal core with essential features that experienced developers would typically add if they had unlimited time. Providing this functionality out of the box makes Drupal more accessible to new users.

Admittedly, the naming is confusing. And by extension, so is the substance of what makes Drupal CMS noteworthy. As the release date approached, I couldn't agree with myself on the most exciting part of this new wrapper.

However, after livestreaming a discussion with some of the major contributors, I can clearly articulate what makes Drupal CMS meaningful: It promises a radically shorter "Time to Value." (Sidenote: it might be a sign that I've worked at a tech company too long that I'm unironically using the phrase “time to value.")  A few key changes:

• A focus on a different user persona: marketers
• A new way of adding and assembling functionality: Recipes
• A new mode of interacting with Drupal itself: An AI Agent

Targeting a time-pressured first-time user

As someone who loves fictionalized stories of how web teams work, I greatly appreciated how Dries Buytaert has explained Drupal CMS in the context of an imaginary marketer. In recent Driesnotes, particularly at DrupalCon Europe 2024, he described how Drupal needs to change to be successful with someone who is not an "ambitious site builder" Drupal has historically served. Site builders with years of experience might be willing to spend long hours clicking together an ideal event calendar. A time-crunched marketer needs quick proof that Drupal can deliver an event calendar they want.

Drupal already has constructs like installation profiles (or "distributions") as well as the Features module ecosystem serving similar values. So why hasn’t that worked to meet the Drupal CMS’ goals?

The slow status quo

Distributions were a major focus point of the first DrupalCon I attended. The year was 2010 and the city was San Francisco. We dreamt big of Drupal operating with many purpose-built distributions. Even Pantheon's concept of "upstreams" was architected to support these distributions like Open Atrium and CiviCRM.

The trouble is that while distributions could work (and still do work) for creating large sets of websites with nearly identical functionality (like the separate websites for a university's academic departments), they're not effective when the developers using a distribution want maximum flexibility too (which is often the thing that led those developers to Drupal in the first place). Drupal core comes with an example food magazine called "Umami," delivered as an installation profile. It is a reference implementation. Developers can see how it was built and manually reconstruct details in their own real sites.

That is not great for improving time to value when an ambitious site builder or marketer wants to build something new. If the Drupal modules function similarly to Lego bricks, an installation profile is like a pre-assembled set where the pieces have been glued together.

Recipes: Faster for users

To stick with the Lego metaphor, Recipes offer a happy middle ground between a pile of loose bricks and a glued-together set. If implementors want a Lego car of their own, a Recipe can supply an assembled (metaphorical) chassis.

To jump to a real example, long-time Drupal architect Lindsey Catlett mentioned that Drupal architects really do have about 200 decision points when implementing Search API. 

Recipes cut that number by an order of magnitude, saving time, budget, and mental overhead.” 

– Lindsey Catlett, Principal Solutions Architect at Pantheon

In the same livestream, Jim Birch, a leader of the Recipes Initiative, highlighted how his agency Kanopi Studios is already leveraging Recipes for common client requests like strict password policies. Recipes are an excellent fit for such use cases because they cut the time and effort spent on repetitive clicks while not completely removing the potential for per-site configuration.

Recipes: Faster for contributors

Much of the effort expended by contributors to Drupal's pre-existing constructs (distributions, modules, and themes) came from the complexity of updates. If someone installs a module in one year, next year they expect to be able to upgrade it without breakage if need be. Thinking through what users will perceive as an enhancement or a breaking change is a lot of work.

Recipes don't have that problem.

Recipes are meant to be applied (not installed) at one moment in time. Most recipes bring modules along with them, and those modules still get installed and updated, but the configuration within the Recipe is applied just once.

Consider the example of that password policy. It includes the requirement that passwords must be at least 12 characters long. Later the author Jim might decide that the Recipe should require at least 16 characters. Again, that change could be perceived as a breaking change if it were hard-coded in a forever-updating module. But with Recipes, individual sites get the configuration values as they exist on the day they're applied, so they don't get automatic changes to those configurations if the Recipe changes in the future. 

In some situations, the Recipes’ users will want such updates pulled into their sites. They will still be able to compare the current state of their sites to the current state of a recipe and pick and choose which changes to add.

Recipes: Faster for the community

Getting modules into Drupal core takes years of effort. Drupal CMS on the other hand is "just" a collection of Recipes. And Recipes, as we've seen, can be changed much faster. So while it took years to get Migrate module or Views module into core, Drupal CMS’ maintainers can bring in commonly used contrib modules with less review than is required for core. By removing the expectation of seamless upgradability, a Recipe maintainer has the option to toss out their module of choice for any given area (SEO, accessibility, etc) if a better choice becomes apparent.

Wildcard: AI agent reporting for duty

I have put a lot of focus here on Recipes as the key detail that unlocks the Drupal CMS value faster than Drupal core. But it is possible that soon folks working inside a given Drupal site won't care about or notice Recipes because they will just be asking an AI agent to make the functionality they want.

Installing the SEO recipe is a bit like asking an AI agent (or a human developer): "Can you configure my existing site to use the widely accepted best SEO modules and configurations?" For a Drupal team working on a real live website, the end result, and even some intermediate steps are the same:

1. There's a ticket in the backlog highlighting the site's technical SEO deficiencies.
2. A developer makes a Git branch to fix the deficiencies.
3. That branch gets reviewed, tested, merged and deployed.
4. The SEO function has been improved.

Does it matter if step two is done by applying a Recipe or by asking an AI agent to just do it? In either case, there is still a need for an appropriate level of reviewing in step three.

Read Chris Reynold's recent post for more thoughts about how the AI Recipe changes the game of building sites. My main thought is that speed expectations are only ramping up.

Back to the Future of Drupal

In these early days of Drupal CMS, it is hard to know where we are on the Gartner hype cycle.

I guess we are at the top, but we'll soon hit some friction points with Drupal CMS, Recipes and AI. Coming out into the "plateau of productivity," I am optimistic that this combination of constructs will lead the Drupal community back to a better version of the dream that I saw at my first DrupalCon. The installation profiles that were new in 2010 partially fulfilled the promise of an "out-of-the-box" product. But they didn't allow for enough reconfiguration and flexibility to satisfy the reason people came to Drupal in the first place. Over a decade later, there is still one Drupal core but fewer viable installation profiles. Drupal CMS looks to be the first of many modernizations of the distribution dream.

Let me know on Bluesky or our Slack what you think the next one should be. Drupal for Commerce? Drupal: Fediverse edition?