Cloud Platform
What Is a Starter Template in Drupal?
Those of us who know Drupal well love it for its flexibility. Like a pile of toy building blocks, we see the myriad of possibilities offered between Core and Contrib. We know that Drupal can build just about anything. It is a differentiator: to intentionally provide a minimal starting point so you can customize the CMS build to your needs.
But this comes with an obvious trade-off. Something that new users run into face-first on day one: while Drupal can do anything, it does little out of the box. Everything requires implementation.
Like your toy building blocks - unless you have a solid vision of what you want to build and maybe a blueprint, you're often stuck looking at a pile of plastic, unsure where to start.
This is what we wanted to solve in the first iteration of Acquia CMS. We all recognize that we want Drupal to be able to do more out of the box, and easily. With Acquia CMS, our goal was to give users a system that could easily create a brochureware-style website within a few days. Between our predefined content model and our drag-and-drop page template creation via Site Studio, users who are new to Drupal can easily create a reasonably good-looking website in days.
But that's just a single use case, and it mostly focuses on customers who are new to Drupal and Acquia. Many of our customers who gave us feedback felt Acquia CMS was too prescriptive - that Acquia CMS v1, which requires Site Studio and our content model, isn't âone size fits all', and we agree!
We know that not every Drupal project has the same requirements. Some websites are brochureware, some are headless, while some need e-commerce. The Drupal community has tried several approaches for solving this in the past. Install profiles, Features, Config Splits - they're all different ways of solving a similar problem. That problem can be described simply as Shipping functionality and configuration for various site use cases into a Drupal site. Anyone who's tried to solve this problem before can tell you how complex it can be.
The most common approach for this in Drupal 9 is using a distribution and its corresponding install profile. However, they're likely to bloat your codebase because they typically try to do everything and ship all the modules you might ever need because, if they focused on a narrower set of functionality, they'd risk not shipping enough functionality to be useful.
So distributions have always had to walk a fine line between opinionation and flexibility.
When you get that balance wrong, the codebase becomes bloated with code you have to upkeep but are not using.
Perhaps worst of all, backing out of the decision to use a profile is often untenable. Profiles do not have an uninstallation path and the modules and themes they ship become dependent on the profile through the profile architecture.
Historically, Drupal shipped functionality and features in a modular fashion and used install profiles to group those modules together for particular use cases (e.g. event site, brochure site, ecommerce site, etc).
However, as Drupal has continued to mature, modules have become more function sets and features have become more configuration. For example, in Drupal 6 you could get a photo gallery (feature) module, but now in Drupal 9, you could just build it with Views (function) module.
While the Drupal community today has a way to share modules, it doesn't have a way to share configuration. So a common workaround is to ship configuration into a module.
It is a little weird though because configuration is not a function but an instruction set for functions to execute. Unlike modules, these instruction sets are actioned once only so conventions like versioning and version control don't make sense for configuration beyond their site context (which configuration management in core already solves).
The Drupal community is now working on a formal initiative: distribution modernization. Also mentioned as starter templates in the Portland Driesnote. This initiative introduces these configuration instruction sets as recipes and creating a formalized way for baking recipes into your Drupal site either as starter kits like what install profiles did or as post-install features without the need for a module.
I'm particularly excited about this initiative because it will completely change the way features can be shipped in Drupal and allow access to the rich feature sets you want without bloating your codebase.
The community has set a 2 year timeline for the transformation into starter templates to take place. Thats kind of a while to what, and, we wanted it now!..
In Acquia CMS v2 we wanted to move away from Drupal install profiles sooner so we could support three critical CMS archetypes without bloating the one-size-fits-all codebase:
We wanted to do this without the code bloat of install profiles so we needed to break our install profile into composable pieces and create a composable architecture we could assemble for the type of project Acquia CMS needed to deliver within.
We also created a starter kit tool that takes you through a wizard-style install experience on the command line. It will ask you what archetype of site to build, if you want demo content and other questions to help install according to the archetype of your choice.
Unlike Drupal install profiles, the starter kit tool wraps around composer and requires in the dependencies you need based on your choices made in the wizard installer. This really reduces the code bloat in your codebase.
We're really excited about our starter kit and how it streamlines your Drupal install for the archetype you're building within.
Get started with Acquia's Drupal recommended project and give the starter kit a go. Let us know what you think on our issue queue on github.
If you'd like to get involved in the distribution modernization initiative, checkout the page and also the Slack channel #distributions-and-recipes
Cloud Platform