A New Age of Drupal: Drupal CMS
Drupal is at a crossroads. Currently, enterprise-level Drupal implementations provide amazing capabilities for digital experience platforms. However, these platforms often require specialized talent to build out so that enterprise organizations can realize the power Drupal brings to bear. Should Drupal stay on the same path, or should it adapt and become more friendly to marketers and less technical people looking to create new websites? If Drupal stays on its developer-driven, developer-focused trajectory, it could become a niche content management system (CMS) with a smaller footprint in the enterprise CMS platform space.
Having worked with Drupal for more than 15 years, I know that Drupal is easy to implement and use. But when looking back at that time, it was not easy to get started and learn. And now, 15+ years later, Drupal is much more feature-packed and complex. Getting started with Drupal today can be overwhelming for users without a technical background or who haven't used the underlying technologies in other projects or contexts.
During the DrupalCon North America 2024 main keynote (affectionately called the “Driesnote”), Drupal founder Dries Buytaert said that Drupal has been part of many “golden eras of the web,” including leading the way on low-code/no-code capabilities and democratizing web publishing—but Drupal’s competitors are doing it better today.
So where does Drupal go as an open-source project?
Dries’ point of view is that Drupal should become even more friendly to marketers, evaluators, and less technical folks than it is today. Dries offered a vision for what this new flavor of Drupal could look like and has named the initiative “Drupal Starshot.”.
Drupal has been around for 23 years and has evolved to incorporate innovations in modern CMSs, integrations, technologies, and accessibility. Over time, there have been efforts to simplify the complexity of Drupal to make it easier to learn and adopt. These have been met with varied success. Drupal is an amazing platform and CMS for enterprise DXPs, but the new features and technologies introduced by continuous innovation have outpaced the efforts to simplify. Oftentimes, specialized skills in the Drupal platform are needed to activate the power and potential of Drupal. It is time for the Drupal project to take a big step to make the platform easier to adopt.
The primary focus of the Drupal Starshot initiative is to create an interface that is easier for everyone to use, particularly for marketers, content editors, site builders, and junior developers. One idea is to create a Drupal platform where someone does not need to use the command line at all to install and launch a Drupal site. This is ambitious and a goal worth pursuing.
The result of Drupal Starshot will be a new version of Drupal called Drupal CMS that is based on Drupal Core and includes features and contributed modules that bring an easier-to-use site-building experience for marketers and junior developers.
Installing Drupal Isn’t Easy
When preparing to install a Drupal site for the first time, a lot of setup must take place, and much of it happens on the command line. For example, when setting up Drupal on my laptop for the first time, I had to install Docker and my preferred tooling (DDEV), then run Composer commands to get the source code of Drupal. Most of this setup happens on the command line, and even when you do a perfect copy/paste of commands following any of the many useful setup guides and tutorials, it’s not uncommon for something to go sideways the first time installing a site. When this happens, you have to work through the problem, often with only a cryptic error message and a lot of conflicting information from a web search. This can be a steep hill for new developers or those who simply want to try Drupal for the first time.
Services like GitPod and SimplyTestMe can help those who want to test out Drupal for the first time, which helps remove that pain. But those instances can be ephemeral and are difficult to find unless you know what you’re looking for. The new install from the browser approach will remove this huge barrier to taking Drupal for a test drive.
Drupal CMS’s Installer and Setup Experience
Drupal CMS’s most notable difference over Drupal Core is a new installer experience, installing Drupal with pre-shipped contributed modules and configuration, and introducing new entity types. The current installer asks the user to pick an installation profile and database credentials, among other information. The profile selection and database credential forms should be removed to make the experience less technical. These steps will likely be replaced with something similar to the wireframe presented in the Driesnote, where the user picks the types of content the site will have (articles, forms, events, etc.). The challenge with the initial setup is to give the user the flexibility to create the site they want without overwhelming them with options or unnecessary steps. It will also be important to let the user know what options can be changed and modified after the setup is complete.
Module Configuration and UI
I love the idea of bringing some of the best contrib modules and common configurations to the initial setup process as part of the new version of Drupal. This will bridge a huge gap many first-timers experience when setting up their first Drupal site. It will help them by giving them many of the most popular modules out of the box without having to learn the details of the contributed modules ecosystem and how to go about finding, installing, and setting up these modules.
Take, for example, the ability to create a URL for a page based on the content title—a common need that doesn’t come with Drupal core today. Putting myself in a new user’s shoes, how would they know where to look and how would they know that ‘Pathauto’ is the module they are looking for? And then once it’s installed, how does a new user know about tokens and how to use them to configure Pathauto? Having Pathauto ship with Drupal CMS removes much of the guesswork.
Bringing the concept of Recipes into the Drupal ecosystem will be a game changer for Drupal Core and Drupal CMS. Giving users and developers the ability to quickly spin up fielded content types and reuse common configurations will greatly reduce effort and timelines in building out complex Drupal platforms.
New Entity Types
Dries noted that they will take the “best of Paragraphs” to help create the new Experience Builder. During DrupalCon, Bounteous x Accolite had a chance to hear some of Drupal Starshot’s principals on this front. Their current hypothesis is to create a new entity type that encapsulates the best of Paragraphs to use within the new Experience Builder. This new component entity type is planned to have all of the content of the component contained within it instead of a nested tree of paragraph entity references. This makes loading these entities from the database much easier and faster. It will also make it easier to marry these to Single Directory Components. But the biggest benefit it will bring is to resolve the longstanding complexity and confusion with translating Paragraphs. I look forward to this new component entity type being added to the Drupal ecosystem, either as a contrib module or a core module that complements Single Directory Components.
Experience Builder
Layout Builder is great. It was a giant leap for Drupal when it was rolled out. Giving content managers the ability to add and arrange blocks and content on a node gives them a tremendous amount of control and flexibility with how content is presented. Taking this to the next level with Experience Builder will be huge for Drupal and content managers.
One of the limiting factors with many enterprise CMSes today is the ability for content managers to style pages without needing to know CSS or needing help from developers. Tools like Acquia Site Studio offer a low-code/no-code approach to building and styling components today. While technically accurate, one must know CSS, JavaScript, and a lot of Drupal (and Drupalisms) to effectively implement more advanced experiences using Site Studio.
The prospect of giving non-technical users the ability to style pages is exciting. It can be frustrating for developers to work in “just a tweak or two” to styling on a single page of a site. It’s equally frustrating for content managers to wait for those tweaks to be developed, tested, and deployed. Putting the control into users’ hands to make these styling updates will make content generation faster. It will also take work off of developers' plates, so they can build bigger things.
I wonder how much reign and flexibility will be available for styling pages. Will there be guardrails in place to ensure that what is styled meets accessibility standards (font size, contrast, etc.)? What about the ability to govern styling so that someone doesn’t veer too far from brand guidelines? I assume the first versions of Drupal CMS will be pretty unconstrained in terms of styling options, but hopefully future versions will give some controls here.
I am excited for the Drupal Starshot initiative and its potential. It will be a revolutionary addition to the Drupal ecosystem. As someone who helps build some of the most complex Drupal platforms for some of the world’s most ambitious brands, I think this is a good move for Drupal. It will bring more people into the Drupal community and increase global adoption of Drupal. While some sites will stay on this new version of Drupal, many organizations will need to grow their platform as they grow, paving the way for deeper adoption of Drupal.
Want to learn more about announcements from DrupalCon North America? Read our key takeaways blog.
Interested in learning more about Drupal? Contact me today.
