Given my recent migration of my blog and the planned launch of Drupal CMS on January 15th, I thought it might be a good time to dig in and see what's currently included in this milestone re-packaging of Drupal.
In this post, I'm not going to dive into every feature—though I hope to add some specific feature reviews in future posts. Instead, I would like to talk about how I think Drupal CMS will fit into the type of work that I do for clients, the type of work that isn't really supported by Drupal at the moment, and what future planned initiatives might mean for both.
With just a couple weeks to go until a stable release, and following the December 2024 Driesnote in Singapore, it feels like what will be included in Starshot 1.0 is coming into focus. If you are interested in seeing what tracks have been kicked off and which are in proposal, I recommend browsing through [META] Drupal CMS work tracks or Dries's slides. That said, even if you dig deep into those tracks, you'll likely miss quite a few features that have made it into the latest release candidate.
Drupal CMS versus core install profiles
Drupal CMS includes a lot of functionality by default in a stark difference to the standard install profile or even the Umami demo profile. The standard install profile was really a tiny set of best practices and a very basic theme that would work for the simplest of sites. I know of a fair number of developers that find even the standard profile too opinionated and only start a new project using the minimal profile. (Sometime in the last year, I remember running across a module that failed to install based on minimal profile dependency because it expected configuration that is in Standard. Your experience may vary.)
Umami was never intended to be a starting point for a website, but it's purpose was to show what could be created with Drupal. Similar to Drupal CMS, it was very opinionated. Unlike Drupal CMS, Umami was not opinionated as a starting point for a new site and was difficult to install—though uninstalling a profile became possible in Drupal 10.3.
Drupal CMS is a bit more than just an install profile or a distribution. It includes a new launch experience that allows choices in what features are included. It also represents a new way of adding features after installation with the ability to apply recipes from directly within the new project browser.
How should I use Drupal CMS?
In the Drupal CMS Strategy Document that Dries shared in August 2024, the strategy was summarized as such:
Drupal Starshot aims to empower marketers to create exceptional digital experiences without relying on developers, setting the gold standard for no-code website building.
Drupal Starshot is a code name for an initiative that aims to revolutionize the way we build and maintain websites using Drupal. The final name of the product is yet to be determined.
The initiative seeks to expand Drupal's reach by targeting content creators and marketers, as well as appealing to a wider range of budgets.
The ultimate goal is to increase adoption and solidify Drupal's position as a leading CMS solution while championing an open, accessible internet.
I don't think version 1.0 will fully realize these goals. I would be impressed if it did. That's a lot to accomplish in eight months.
I do think version 1.0 will be a pretty complete demo of common Drupal features rather than a true starting point that every new Drupal site will use.
So if you are a sales or solutions engineer in an agency or a Drupal lead within an organization, you should install Drupal CMS at least once to see everything that has been added. If Drupal CMS is in any way successful, it represents an tested set of modules that are either well-supported or will be more supported due to their inclusion in this packaging of Drupal.
Think of Drupal CMS as a reference point for more broadly adopted best practices. I think most seasoned developers are going to agree with 80 – 90% of the choices—and likely be dissatisfied with the rest. That's actually pretty good if you considered the breadth and depth of the choices included in Drupal CMS.
I think Drupal CMS will get much closer to the stated strategy over the next year.
If I were creating a new blog—or migrating one such as this site—it's not a bad starting point to build upon. If I were a marketer trying to create an exceptional experience without a developer, I would be out of luck just installing Drupal CMS, but I might be impressed enough to explore further.
There is a very important reason why a marketer wouldn't be able to achieve that goal just yet.
Drupal CMS will need both a successful experience builder and a better base theme that works with experience builder to truly break a web marketer free of the need for a developer.
Experience Builder (coming soon)
The Drupal community, at least those paying attention to core development, sees a lot of exciting possibilities in the Experience Builder Initiative—even though it is not a part of the first release of Drupal CMS. Community members are also likely a bit scared by it because of the scope of the change it represents. I'm excited to see how far we can get between now and the anticipated first release of Experience Builder in late 2025 as part of Drupal CMS 2.0.
Back-porting any existing site to use Experience Builder is likely to be extremely challenging. Even if all of the stated migration goals for sites using Layout Builder and/or Paragraphs are achieved, like every big Drupal change, this one will require a fair number of developer hours.
That said, new Drupal sites, Experience Builder could be a radical way to grow adoption. As long as previous techniques for layout continue to work, the growth could still fuel a lot of positive change in Drupal.
Experience Builder is trying to solve a problem as old as Dreamweaver—well, really older than Dreamweaver.
People (who don't know how to code) want to create a website that matches their aesthetic vision.
Web developers hated Dreamweaver because it created atrocious code that was difficult to read and bloated. Some designers loved it because it let them create the thing they wanted without a pesky expert telling them they were doing it wrong. Neither of those viewpoints are wrong, but the best websites still require a team of experts applying their craft to achieve ambitious goals.
Empowering marketers (and small business owners)
Modern web teams for most robust CMS-driven websites (managed or SaaS) have a combination of roles that range from backend developer, frontend developer, visual designer, user experience designer, content strategist, quality assurance testers, SEO analysts, and more.
Building really big websites, typically with teams of 4 to 10 web specialists (sometimes more), is what I do, but it's not the only kind of website.
Those teams are expensive, which is why so much downward pressure on cost has been created by outsourcing website development from areas where those costs are highest to areas where those costs are less. Small to medium-sized organizations who want brochure-quality (relatively simple) websites, want them for the least cost possible.
As the complexity of the product, cause, or service being sold by a website increases, the cost of that larger team becomes easier to justify to ensure higher quality and conversion rates. Up until now, I would argue that modern Drupal is much easier to adopt in organizations that require significant complexity and integration.
Drupal CMS wants to change the size and complexity of websites that are a good fit for Drupal.
Drupal CMS has a (paraphrased) strategy that as a marketer wanting to build an ambitious website you don't need a team. This strategy may help gain market share, and increase profits for hosts that figure out the margins on hosting these new small-to-mid-market Drupal sites.
The strategy will also increase the number of poorly built websites on Drupal—for better or worse.
That's not to say that there are not poorly build websites on Drupal currently, but I don't think ambitious content models that power complex enterprise sites and applications are suddenly going to only require a team of one person.
So maybe the "marketer" referred to in the strategy is really a small-to-medium-size-business owner, or their marketing department of one, that is empowered to build a less ambitious content model, but still a compelling web presence, that lets them use the host of their choice instead of a site building tool like Squarespace or Wix—or another open source project like Wordpress that has its own issues with vendor lock-in in its plug-in ecosystem.
For Drupal CMS to meet its strategic goals with this sort of marketer, it needs to have Experience Builder. That said, I do think there is room for Drupal CMS to grow adoption, and succeed, without a new ambitious page building experience, but it will need better themes.
Olivero (the default) and the theme ecosystem
One of the strategy document's stated "must have capabilities" is "easy to implement custom brand and design." I do not see how Drupal CMS will have this capability with version 1.0.
Olivero is great for so many reasons. It shows that the Drupal community can build a highly-accessible, clean, simple, and attractive out-of-the-box theme. It supports all the best parts of Drupal from the point of installation, such as translation and performance settings. It has great test coverage—and contributed modules can count on it for stable test coverage with their libraries. It looks so much more modern than Bartik. (Okay, that last one is reaching a little. It is a very low bar to look more modern than a theme that was released in 2011 as part of Drupal 7.)
Olivero was not really built to be a flexible theme for page building. It supports Layout Builder, which was already in core when Olivero made its way into core, but it doesn't really account for the idea of designing within the browser that Experience Builder is supposed to achieve.
Drupal CMS 1.0 will ship with an enabled Olivero for Drupal CMS theme. This theme is mostly to adds bug fixes to make some of the contributed modules included in Drupal CMS work better. It should allow for development that is faster than core, but it's still a custom sub-theme at heart.
So Olivero, at least in its current state, is not going to be viable for an ambitious "marketer", at least not one without some significant web skills who is "designing" a website without developers or designers.
That's why there was a call for proposals for a new design system for Experience Builder and Drupal CMS. (Happy Christmas Mediacurrent! You have some challenging work ahead.)
In theory, the result of that project should be a design system that helps define a solid set of starter components that most sites could use to kickstart a project to match a custom brand and design. I'm assuming this is going to also include a new theme for Drupal CMS in addition to Olivero. (Or maybe they'll extend Olivero for Drupal CMS further, that's still not clear.)
It looks likely Experience Builder will support single directory components (SDC). A SDC allows you to include the Twig template, CSS, and Javascript in a single directory that is registered in a theme or modules libraries and loads only when used in a rendered page. In practice, you want to tie components to a unified design system in most projects. Design systems tend to be created by designers in tools that are focused on visual creation combined with a detained technical specification—Figma seems to lead the pack these days. There are also many design systems that are based on well-established, utility-class frameworks, such as Bootstrap or Tailwind.
I've found SDCs tricky to implement with utility-class frameworks. The idea with those frameworks is that you can reuse the utility and component classes to create new components. When done well, you should rarely need to add classes for anything other than truly original components. So SDC implementation of a common framework is often only twig templates and no new classes.
For custom design systems, you are defining all your components based on classes you create, so the match with SDC is a bit easier to implement. Except... most design system maintainers are not necessarily enamored with Twig as their templating language if the design system is going to be used multiple frontend technologies. A headless site with React or Vue or Next.js for the frontend with Drupal providing the data doesn't seem like a clear match to the SDC model. Though maybe we'll get support for component types other than SDC.
All that to say, theming in Drupal is challenging for those without experience in the Twig and at least some sort of CSS compiling. The same can be said for headless theming. I'm still a little unsure how Experience Builder fixes these issues within this space. It definitely provides another option, but it doesn't make the underlying challenges easier to tackle.
I've long felt it would be great for Drupal to have a "default" frontend framework that was well-documented outside of the Drupal community that could serve as a basis for most themes. That would be so very difficult to get the community to agree upon. I don't see that happening anytime soon, which likely means Experience Builder is going to have the same theming challenges of Layout Builder and Paragraphs.
I hope I'm wrong and this all comes together in a demonstrable way in the next year. There are so many approaches to page/layout building in Drupal that I worry a little bit. A "new way" that is "the way" could lead to a lot of legacy code that people feel they need to refactor. All of this thinking leads me to wonder if we are only supporting "marketers without developers for new Drupal sites and not existing". How is that going to work?
Marketers without developers (or designers?)
If you are reading this, you likely have some interest in Drupal. Right now, that likely means you are either a web professional that works with Drupal and are trying to figure out what Drupal CMS means to you or you are one of those rare folks reviewing Drupal to see if it meets your needs.
In the strategy document, the term "marketer" seems to be the placeholder for someone reviewing Drupal to see if it will help them achieve their website needs or perhaps a plucky site builder that wants to quickly stand up a website to get the word out about "something" (product, cause, service, etc.).
If you are a "marketer", I hope you understand that you are likely going to fail if you try and build a solution with any platform based solely on your own biases. "You can do this alone" is the fallacy of the site generator sales pitch.
Yes, a large percentage of the web is made up of sites built on Squarespace, Wix, Shopify, and even Wordpress. How many of those sites do you visit even once per year? For every success story (likely less than a percent), there are so many more website failures (most websites ever).
Even with a healthy does of pessimism, I can see some advantages to Drupal competing in space that builds a lot of throw aways websites.
A site built with Drupal CMS should be:
- more accessible out of the box because it has a better base structure and teams of contributors ensuring things like link target size, color contrast, and even built-in accessibility checking with tools like Editoria11y are included.
- search engine optimized because tools like pathauto, Metatag, and Simple XML Sitemap are included.
- easier to translate because Drupal core does this so well.
- so much more structured than a site generator (Squarespace, Wix, etc.).
- free to move from the host of your choice to the host of your choice—no vendor lock-in.
To take advantage of all of those amazing traits, marketers are going to need a hosting option as turnkey as Wordpress.com. I'm curious which Drupal hosts are going to reach that market first. It should be a great time to be a Drupal hosting provider if you can figure out that experience.
How I might use Drupal CMS this year
I am optimistic for Drupal CMS even if I'm not that optimistic for agencies focused on web projects in the coming year. Based on the number of developer job posts and RFPs for Drupal-specfiic projects, 2024 seems to have been a pretty significant market contraction. I think the artificial intelligence hype cycle was part of the issue. While I have had some pretty successful moments using AI as a coding partner over the past year, I've been depressed by the reduced quality of content across the web over the last time.
As the AI hype cycle wears down a little, and people realize they need to publish content on a website to train AI, I'm hopeful that 2025 will see a bit of a rebound in new projects and growing digital teams.
My business has been focused on mentoring and coaching teams of developers, designers, and content strategists (often in government) showing them best practices creating enterprise digital solutions using agile product management.
To start the year, I think the biggest change to my approach will be using Drupal CMS to show these teams the direction that the Drupal project as a whole is taking with the features it includes. Some of those technical approaches are nearly identical to the content models and feature implementations I have been using throughout my modern Drupal journey—but they are all so much faster to implement by applying a recipe!
So in the short term, I think a lot of the proof-of-concept feature demos that I've put together over the years are either going to be replaced by a Drupal CMS recipe, a contrib recipe, or are going to be turned into a recipe. (Now we're cookin'!)
Over the rest of the year, I'm going to be following hosting options closely. It has been decades since I worked on small-to-medium-sized projects, I think I'll have to consider adding a few smaller clients to test the waters a bit.
I have also started a list of smaller government and higher education websites that are are on legacy Drupal versions, Wordpress, or proprietary platforms. These sites would not have been a good fit for modern Drupal before Drupal CMS. The risk to reward ratio for a project less than $30,000 USD was just too great when starting from scratch. That said, these smaller organizations represent a key area of growth for Drupal as we lead up to the DOJ Accessibility ruling deadlines in 2026 through 2027.
Do you have a project or team that needs some expert help? Do you just want to chat about Drupal CMS and what it might mean to your organization? Connect with me on LinkedIn or reach out to me on Drupal Slack (@joshuami).