About this session
In this session from the Drupal CMS track, product lead and Technocrat CTO Pamela Barone and Drupal core product manager Lauri Timmanee make the case for Drupal CMS: why it exists, how it relates to Drupal core, and what the split means for anyone starting a new Drupal project — developers, agencies, and site builders alike.
The first half settles what Drupal CMS actually is: a prepackaged starting point built entirely with Recipes rather than as a distribution, shipping only stable module releases and no patches — so a site that starts with Drupal CMS is a standard Drupal site, with no lock-in and no inheritance. From there, Pam and Lauri walk through how the project consolidates the best of contrib, page building with Drupal Canvas and the Mercury design system, a lower on-ramp through the Launcher app and DDEV, and site templates as near feature-complete starting points for common use cases.
The second half looks ahead: how Drupal core is slimming down into a leaner framework in Drupal 12 while Drupal CMS takes on the product role, what shipped in Drupal CMS 2.2 — multilingual out of the box, with Canvas page translation — and where AI tooling and headless rendering with Drupal Canvas are headed, including support for front-end frameworks like Next.js, Nuxt, Astro and Angular.
"It really honestly still gets me a little bit excited when I install Drupal and I see something that looks like this, because it's just such a long way from where we were even 12 months ago." Pamela Barone
Key takeaways
- Drupal CMS is built entirely with Recipes, not as a distribution: a site started with it is a standard Drupal site with no lock-in, and it ships only stable module releases with no patches.
- Drupal core is becoming a leaner framework in Drupal 12 (for example, Default Admin based on Gin, Navigation replacing Toolbar, and removal of Olivero, Search, Contact, Ban and History), while Drupal CMS takes on the product role.
- Site templates provide near feature-complete starting points per use case, and Drupal CMS 2.2 adds a multilingual recipe, a setup checklist, and Canvas page translation via Canvas Translate.
- The AI tooling goal is for every Drupal CMS workflow to be operable by an AI agent with humans in the loop, through MCP for content work and skills and CLIs for local development.
- Headless support in Drupal Canvas consists of a Content Delivery API, a Headless SDK, and authenticated live preview, letting teams use frameworks such as Next.js, Nuxt, Astro and Angular while editors keep Canvas.
In this session
- 0:00 Introductions
- 1:05 Agenda and the vision for Drupal CMS
- 3:02 AI, vibe coding and winning the developer
- 8:08 What Drupal CMS is: Recipes, not a distribution
- 12:14 Consolidating contrib modules and ECA
- 14:15 Drupal Canvas and the Mercury design system
- 17:19 Lowering the on-ramp: Launcher app, DDEV and docs
- 18:54 Site templates
- 21:04 How Drupal core is adapting in Drupal 12
- 28:30 New in Drupal CMS 2.2: multilingual out of the box
- 31:04 Canvas translations, multilingual ideas and product analytics
- 35:13 AI tooling, structure and headless with Drupal Canvas
- 46:35 Try Drupal CMS and get involved
Full transcript
Introductions
All right. Thank you, everyone, for coming to see our session on the case for Drupal CMS, all about growing adoption and expanding our focus for a new digital era. My name is Pamela. I am the Drupal CMS product lead and also the CTO of Technocrat, which is a Drupal services agency based in Australia. You may remember me from the DriesNote earlier. And I have very good news for you because that session that he promoted is going to be very similar to the one that I'm going to do today. So you don't have to worry about watching it.
And today I'm joining Pam because we have a lot of exciting things to share. So we wanted to join to share the fun together. I'm Lauri Timmanee. I'm a manager of product management, which Pam loves to give me a hard time about because she's like, what does that actually mean? So what it actually means is I oversee the developer experience products at Acquia, so if you have thoughts around those, very happy to talk about them with you.
Agenda and the vision for Drupal CMS
Just quickly, the agenda for today. We'll talk initially about why we decided to build Drupal CMS. Then we'll talk about what it is exactly, because I do know there's still maybe a little bit of confusion about that. Lauri's going to talk a little bit about how Drupal core is adapting in the new era of Drupal CMS, and then we'll both talk a little bit about what's new and what's next. So I'll get started on the vision and strategy. If we take a look at the Drupal marketing, we see this a lot. We talk about Drupal as the web's most powerful open source CMS. It gives you freedom and flexibility and privacy, accessibility, performance, and we have this line on the drupal.org homepage that no other content management software is this powerful and scalable. This is marketing, but I happen to believe that it's true, and I think probably most of you do as well. If we look at where Drupal is today, it's very strong for these content-heavy use cases and high-traffic sites. These are very well-worn stats, but 71% of the top 100 universities in the world are using Drupal, governments in more than 150 countries, and at least 60 confirmed Fortune 500 companies. It's been said before that Drupal makes hard things possible, but it also makes easy things hard. Again, I think everyone in this room could agree. I think if it's true that there is no other content management software that is as powerful and scalable as Drupal, then we should really be doing whatever we can to adjust that and start making some of those easy things that typically used to be hard start making them easy again. So this is where Drupal CMS really came from. The aim is to make Drupal's power accessible to a far wider range of builders and their clients by making it the go-to platform for web developers by making them successful faster.
AI, vibe coding and winning the developer
A lot has actually changed since we started on Drupal CMS. Drupal CMS sort of got its infancy in 2024. And so we are having to adjust to that change in the world. Probably the biggest change that we've seen in the industry, which you can't really avoid hearing about — I mean, if you watched the DriesNote, you heard it from him — is basically how AI is making building cheaper. Obviously, it doesn't make the whole development lifecycle like 10 times faster as a whole, but the actual point where you write code, where you generate code, is becoming significantly faster from what it has been before, which means that it changes how we need to approach building our products. What's interesting about that change is also where it has sort of spun up a completely new industry. Vibe coding applications like v0, Lovable, Replit, and so on are generating millions, hundreds of millions of revenue, and are growing at an insane speed. So that's also obviously adding pressure on us in terms of, like, it's changing what it means to be a no-code, low-code platform. Because if you imagine something like Lovable, it's not really particularly like a low-code or even no-code product, even though they don't make the code very visible on their platform. So it's a very high-code but still easy-to-use product. Another realization, or something that we've known, but something we didn't prioritize as much before, is just the importance of how much developers weigh in making decisions on which solution to go with. Developers are usually a critical part of tendering software, and because of that, it's important that developers actually are ones that vote for our solutions. Same is true for agencies. We need to make sure that agencies, who are often the ones who make that decision for their clients, that they choose Drupal more in future. The vision is basically to win the developer with Drupal CMS, and marketers still get Canvas and all the good things that we've been talking about. It doesn't mean that now that we are prioritizing developers more and more that we somehow forget about what the marketers still need to do. We want to keep that same experience for the marketer, whilst making this all more fun and productive for developers to work with. If you think about Drupal CMS, if you try to contrast that against Drupal core, the most recent way for us to talk about it has been where Drupal core provides a stable, secure, scalable foundation for all of Drupal. That's what all the modules, all of the themes, everything that you have in Drupal is really built on top of. Then Drupal CMS is our front door, which is an opinionated version of Drupal that has been built to accelerate that first starting experience with Drupal. It gets you 0 to 1 much faster than what you can if you try to build everything from scratch. What this means in practice for [unclear, 3:02] prioritization and product strategy for these 2 products: Drupal core will continue to prioritize that advanced developer experience. How do we build APIs? How do we build a platform that developers want to build on top of? That's where module ecosystem and ecosystem at large is the primary focus for Drupal core, not so much about what it is to build a site. It is part of it, but it's just that it's a smaller part of it, whereas Drupal CMS is primarily focused on what does it mean to create these experiences for our end users? What does it mean to set Drupal up for an end user? How do you go from 0 to 1 as quickly as possible using those foundations that Drupal core offers? That's great because it removes a huge burden, like adoption and getting people to actually ramp up in your product. It is a major part of the work. It is not a small lift. It's one that actually, when we tried to do all of this in Drupal core, it was very hard for us to prioritize because of those — basically, the people who are good at building the kind of ecosystem that Drupal core is trying to build for modules are not the same people who are good at thinking how to make your product easy to adopt or get started with. There's a lot of good reasons to why the split makes sense from both product and then team perspective. That means, in a nutshell, that Drupal core no longer needs to do 2 jobs, which it always tried to do before. It no longer needs to do product and a framework in one package. Now it can focus on the framework and not the product aspect of it, which is interesting for me to say given that I'm a product manager for Drupal core, to say that, okay, we are no longer a product, so I guess what is my job? Maybe I made myself obsolete.
What Drupal CMS is: Recipes, not a distribution
So I'll just talk a little bit then about what Drupal CMS is because — so in this room, who has tried Drupal CMS version 2? Okay. So —
Around maybe one-third of the room, just for the recording if anyone's wondering.
About one-third. So what Drupal CMS is, is a prepackaged CMS starting point that's designed to make it faster and easier to build websites, as we have said several times so far. But I think the key thing that I want to call out is that it is not a distribution. So it's built entirely with Recipes, which essentially gives you configuration applied at install. And then from there, they can be modified as any other Drupal site. So there's no difference between a site that starts with Drupal CMS and a site that starts with core and then just makes all of the same configuration changes. It's exactly the same thing. So there's no lock-in. There's no inheritance. There's none of the old headaches that we had with distributions.
Maybe you can make yourself obsolete as well then because no one is depending on you for updates.
That's good because the salary is really bad, so. So just visualizing this in a traditional Drupal project model, you always start with Drupal core. Then you add contrib modules. Then you add config. Then you create a custom theme almost always, and then you add some custom modules. So obviously, this is not to scale, and the amount of each of these things would change depending on what the project was. But if we think about where Drupal CMS fits into this, it essentially just does some of the customizations that you would probably be doing every single time anyway. It does them for you in a way that you don't have to worry about. But I think the key message to really kind of hammer is that Drupal CMS is just a Drupal site. It's not something different. You don't have to have this sort of debate with clients or whoever. Should we use Drupal CMS? Should we use Drupal core? It really doesn't matter. I mean, I would say generally if you're building a Drupal site that is publishing-focused, it probably makes sense to start with Drupal CMS. Maybe you have your own kind of starter kit, but I mean, I think if you look at what Drupal CMS includes out of the box, it is basically just all of the CMS stuff that our editors expect. These are things I think we've all set up a million times and it's not a lot of fun. I was actually surprised to find — I've been building Drupal sites for 15 years, and I was honestly quite surprised to find when I started this that there were actually a lot of really cool contrib modules that I had never heard of. I thought, I can't believe we haven't been using these for our clients. If you haven't taken a closer look, I recommend that you do. You might find that we're doing things a little bit differently to you, but maybe you'll like it. I mean, you can just pinch things from us. If you are still rolling your own starter kit, it might be worth asking whether you need to do that anymore. Or similarly, if you think that there's something over here that we're doing badly, let us know. And we're very much open to changes. We actually also do get — very frequently, we get people trying to sort of sell their contrib modules to us for inclusion. So we're very often hearing about the latest and the greatest organically. We're not really having to hunt this stuff down because we've kind of created a central repository for the latest innovations. Another thing just to point out for those in the room who are kind of into this stuff, we only use stable releases of modules with very specific exceptions, including one unfortunately that Lauri caused us to do this time, and we don't ship with any patches whatsoever. So the idea is a super clean starting point that gives you what you need. And I mean, the thing with the no patches and the stable is actually what we end up doing is pushing these modules to commit patches and create releases where they might have languished before. So we help them, we offer assistance, and we are able to accelerate that.
It's been also interesting to see how much of a carrot it has been for some of the modules to tag a stable release because it is a precondition.
Yes. Not just the stable release, but also major version support. So we launched Drupal CMS initially on Drupal 11 relatively early in the cycle, and that was quite difficult. But we were able to accelerate the Drupal 11 readiness for a number of really common contrib modules, and I expect that we'll be able to do the same for Drupal 12 as well.
Something else I do want to mention here is —
Keep interrupting.
Sorry.
No, I'm just kidding.
Consolidating contrib modules and ECA
I'm trying to prove myself because I just made myself obsolete, so I'm trying to find something new to do. So something else that we did that I found very interesting was that something that you probably, when you built Drupal sites, have noticed is that there are many use cases where there are maybe 3 to 5 modules that sort of do the same thing but slightly differently, with different trade-offs in there. Something that we've been doing is working with some of these module maintainers to try to understand first what those trade-offs are, what is a particular module good for, and then sometimes we've been able to help where, okay, we could actually consolidate on this one module if we just did XYZ in here. If you have examples of this where you feel like there's this one module that works almost great, but there's this other module that does it better, we are happy to help with that because we are quite familiar working with the maintainers to do this type of work.
Yes, and if we're not careful, then ECA is just going to eat all the modules. In a number of cases when we were debating which contrib module to use, we ended up just using very simple ECA workflows to achieve the same thing. For example, cloning of content is done purely with ECA. There's no contrib module for that. Then I think one other thing just to point out about that is it's not necessarily about, like I said, you're doing the same things over and over, but I think especially when it comes to people that are new to Drupal, that kind of module roulette thing where they would be coming in and figuring, okay, well, I want to be able to clone my content. Which of these 5 contrib modules should I use? That decision is essentially just gone now for inexperienced people. Then just speaking to Lauri's concern that he is obsolete, one of the things that I want to focus on, specifically in Drupal CMS, is Drupal Canvas, which I do know has been probably covered ad nauseam, but this is the Canvas editor. And for those of us who have been longtime Drupal users, I just — this is just such a leap forward. And I think for so long choosing Drupal meant trading off the — you know, you get the power, you get the scalability, you get the reliability, but you had to compromise on the user experience. And that's simply just not the case anymore. And I just can't even tell you how much fun I have when I use — I do want to bring a quote from —
Drupal Canvas and the Mercury design system
I was meeting with a customer last week, and they were really impressed about one aspect of Drupal Canvas because they realized how well it allows you to keep structured content from Drupal. They have a very complex use case where they're pulling in data from various different backends, so they need structured content for everything in their case. Even though you see visual drag and drop in there, it is built to utilize Drupal structured content on top of it. Yes.
So I think it's just worth highlighting that Canvas is a really foundational uplift for our entire project. So for organizations, it provides a way to enforce brand consistency while essentially managing how much flexibility you give. So because you can bring your own component library, you can decide how much power you want to give your editors. For editors, I mean, it's just true drag and drop, real-time previews. I mean, it's not really game-changing in terms of competing with other platforms because they all just provide this out of the box. It's kind of the assumption now in 2026. So it actually allows us to compete with them at that same level.
And what is different about ours is that you can customize every aspect of what components you want to offer and what are the settings that you offer in there. And that's sort of the misconception there, is that it makes Drupal Canvas somehow less powerful because you don't have like 150 settings when you enable it, but it's intentionally built that way because a lot of the customers that Drupal tends to work with are ones where you really do want to customize a lot of those aspects. So we have optimized the experience for that. What's interesting is there are some community modules that are starting to spin up. There's a module called Canvas Builder, which is actually providing you that, where you can get a bit of a firehose from the beginning, so you have 150 settings in there if that's what you want. And it's really just to prove that it is a framework that you can build anything on top of, that we've wanted to leave it up to the site builder to decide.
And if you are looking for something in between zero and a firehose, there's also Mercury, which is the Drupal CMS design system that we developed to sort of coincide with the release of Drupal Canvas. It's a perfectly comprehensive starting point that even if you don't want to necessarily use it — whenever I build a site now, I start with Mercury. I just copy it and then I use it from that. Once you get to understand the components and how they fit together, I mean, the flexibility is genuinely mind-boggling. And it's just a nice way of kind of — even if you don't want to use it, it's a nice way of just kind of using Canvas without having to do a bunch of setup and kind of think of what components you want.
And we've talked a lot in the DriesNote and different presentations about sort of the editor-facing improvements that Canvas brings in. But Canvas brings major improvements also for the developer experience, especially for frontend developers. Because it is a true component-based system that you get to build with when you use Canvas. You can pick between SDCs or code components, as you saw in the DriesNote. So you can use JavaScript in there. And now we have headless, then, which we are going to talk a bit more about in a moment. If you're interested in the developer experience, I just want to mention that Bálint Kléri will be doing a full session tomorrow. And you can get a lot more info about the developer experience there.
Lowering the on-ramp: Launcher app, DDEV and docs
Yeah, and I would say as well, because it has also support for SDCs, I have found, especially probably in the last 12 months — maybe 12 months ago, trying to use AI to generate SDCs was a little bit dicey, but doing it now is pretty seamless. And I think if you still wanna sort of stick with the traditional Drupal architecture, you can do that. So you can use React if you want, you can use SDCs if you want. But the main thing is that you don't have to understand Drupal's entire theming, like the render pipeline and all of that sort of stuff, because it's like what you present is what you get. We've also created some ways to try to sort of lower the on-ramp to new or less experienced developers. So for true beginners, we created what we call the Launcher app, which is basically a single download that gets you a fully functional Drupal site locally. You don't have to install any other software. You just download the application, and it gives you a little dashboard so you can delete the site, restart the site, all of those kinds of things. Super, super easy. Then of course we ship with DDEV support included. It's just one less decision for people to make when they're getting started. And then of course, because it's Drupal, you can bring your own insanely complicated setup if that's what you prefer. We also rewrote most of the user guide when we launched 2.0 earlier this year, and we launched it with docs as code, so it's much easier to maintain. But I will say this is one area that does not get a lot of attention, and it could definitely use some more work. So if there are any doc heads out there, please put your hand up and we'll take your assistance.
Yeah, I have something drafted sort of in my back pocket, so if anyone is interested to sort of review and help with some of this, there might be something that we can start with.
Site templates
The next sort of piece of Drupal CMS that's new in 2.0 is — like, when we were building 1.0, we spent like way too much time having really ridiculous debates about what content types to have and what to name them and what to name the fields and what to do, how to do all of these things. And what we realized was basically we couldn't provide something that was useful but also generic. So we were either making too many decisions or not enough decisions and essentially pleasing no one. So we came up with this concept of site templates. We scaled back essentially what the baseline Drupal CMS gives you, and then we offloaded all of the rest of it to the site template, which is — the way I describe a site template is it's a near feature-complete starting point for a website based on a specific use case. So they're used for new site setups. You don't apply a site template to an existing site. They provide features for the use case. They provide the data model, and they provide generally a specific theme. I mean, you could have a theme that's used for multiple site templates, but a theme that's ready to go out of the box for that specific use case. So if we go back to the kind of project makeup, if this was Drupal CMS 1, we actually shrunk the red circle a little bit and then did a little bit more by adding site templates on top of it. So in the whole, we're doing more, but we're doing less sort of in the baseline. And this, if you haven't — again, if you haven't tried Drupal CMS, this is what you get on the installer. This is a list of the site templates that we have right now available. All except for one is free, and you can try them out. Yeah, I encourage you to if you haven't. And these are just some screenshots of the site templates that the Drupal CMS team have built. [unclear, 18:54], but it really honestly still gets me a little bit excited when I install Drupal and I see something that looks like this because it's just such a long way from where we were even 12 months ago.
It's fascinating how we've been able to get now frontend developers really excited to create all of these things. It makes Drupal look fresh.
Yes. In fact, I was showing Lauri my screen the other day, and he was like, ooh, what's that? I was like, well, that's the Everbright site template, free to use with Drupal CMS.
How Drupal core is adapting in Drupal 12
That really did happen. How is Drupal core adapting to this? Obviously, we talk a lot about what we're doing with Drupal CMS, so I'm going to highlight some of the changes that are coming with Drupal 12 to accommodate what Drupal CMS is doing. Drupal core, Drupal CMS, even though they're separate products, the teams themselves, we are working very closely. We have a common strategy between the two, so we are really working as one Drupal project between [unclear, 21:04]. It's just that each of these products have their own role that they are serving. The big highlight here is that core is getting leaner as a consequence, which allows Drupal CMS and Drupal core to move faster. We have some things leaving from Drupal core in 12.0. We are moving from Claro into what we call Default Admin, which is based on Gin, which is a very popular contributed [unclear, 21:04]. We've named it as Default Admin with the intention that we are not trying to replace it with another admin theme in future, but maybe, who knows? If we have to do that, then there's a Default Admin 2.0, I guess.
Well, and I think part of the idea as well is that we shouldn't have multiple admin themes. We should be providing an admin theme that's good enough for everybody to use, and so essentially we will remove support for changing the admin theme in the user interface. If you fully know what you're doing, you'll still be able to do that, obviously, but it's no longer going to become a supported thing to just swap out the admin theme and use Olivero as your admin theme. These things that just shouldn't be happening, that create complexity and things that we have to support, it's just not going to be there anymore.
Yeah, so we are removing some of the admin theme-specific configurations. The theme negotiators, if you know what those are, they will remain, so you can build all of that in contrib or custom module if you want to. We are also consolidating our admin navigation, so we are moving from the toolbar that served us well for the last more than 10 years to Navigation, which is the sidebar navigation you may have seen in some of the demos. And if you install Drupal, it comes already out of the box with it. This was great actually because it allows us to get rid of some of our JavaScript dependencies in Drupal core, because we had some pretty old dependencies in there that we used for toolbar. We're also getting rid of some modules like Shortcut and Settings Tray just because they are not — the adoption of those hasn't been very broad. Then there's the bucket of site features, and this is probably the most interesting bucket to me from here. Drupal core historically had this strategy where it tried to provide simplified versions of certain contributed modules as part of Drupal core. A good example is search, where it should be turnkey to install search, but the challenge with that was that if you actually went and relied on the core-provided search, it was a dead end. You would never be actually able to implement like the fully fledged enterprise search on top of it. And to get that, you would have to rebuild your search as a consequence. And this is also duplicating our efforts, where we have sort of now a division where we have some people building on top of the Search module from core and some people on Search API. We wanted to try to unify these a little bit and move on what is the best of breed in the community, and to try to avoid core from competing with those contrib solutions. Also, the adoption on these was largely inflated by the fact that we enabled them by default when you install core, and we saw that they're largely just being disabled from sites from there. So it's very hard to tell actual usage based on the data that we had, but we could tell that people are actively going and uninstalling these things when they install Drupal core. So Search is being replaced by Search API.
Not in core.
Yes, not in core, but this is for Drupal CMS. There are conversations about that, maybe Search API, maybe some of these things should be in core once we are done with the cleanup, but this is way future in horizon. First step is to get rid of the duplication. We're going to use Search API in Drupal CMS instead of Search. We use Webform in Drupal CMS instead of Contact today, so Contact is going away from Drupal core. There are some discussions around that because Webform isn't fully compatible with the idea of headless, so there are some conversations around how to resolve that in future. Then there's modules like Ban and History, which just sort of — Ban you would usually handle on the CDN layer or some other way. Ban, it isn't particularly useful to handle that on your Drupal site. Then History also is just a specific use case that Drupal was built for in the very early days and doesn't make a lot of sense today. And then we are doing the same on the frontend layer, where we are removing Olivero, like Pam mentioned. So there is no longer going to be a default frontend theme as part of Drupal core. So in order to get that, you have to install one of the site templates that Drupal CMS offers. We're also getting rid of things like the default content types that you used to get with Drupal core. So if you now install Drupal core, you no longer get an article and page content type in there. What I find fascinating is that right now, if you install Drupal core, all of those things are removed. You basically get a blank slate. It would be just a blank page, and it's like, there's a lot of code in there. What did I just install for this blank page that I had? You don't even get a Hello World at that point, so I can't see if it's the most complex Hello World generator. We've replaced it with a welcome page now that explains what you've installed, [and] recommends some things like, hey, maybe you want to install Drupal CMS or Drupal Canvas in here, so that there's some direction on how to get started from there. Obviously, it's just one static page, so it doesn't really impact anyone other than when you're getting started with Drupal. The big question might be, what is happening with Layout Builder? Because it wasn't mentioned in the previous slides. Right now, it looks like it's going to stay in Drupal 12, that there isn't a way for us to remove it by Drupal 12, but we are working on decoupling from Layout Builder. Navigation, for example, actually depended on Layout Builder before, so we are removing some of those dependencies. On the long horizon, the goal is to remove Layout Builder from Drupal core and then essentially make Drupal core agnostic to the site-building, page-building solution. So this doesn't mean that we would be replacing it with Canvas in there. That's not in the goal. Drupal Canvas is what we recommend with Drupal CMS, and there's some competing products that you can — or modules that you can select from the contrib ecosystem if you want something different. Some of the new things that we are adding: so as mentioned, there's a new admin theme that we have. We have Navigation. And then the biggest part probably that you're interested about is that there's been a lot of focus on improving the performance of the foundation that we have. So there's been major improvements to the lowest levels of Drupal core to improve the performance that you get in there. And that's sort of the benefit that we get from reducing our focus on innovating on the products, which could be the Search module, which is not being adopted at large. We focus on these kinds of innovating on the foundations, and now everyone can benefit from those improvements.
New in Drupal CMS 2.2: multilingual out of the box
Yeah, and I mean, obviously it depends a little bit on your machine, but I got a brand new MacBook and I can easily install one of the simpler site templates in under 10 seconds, and it just blows my mind every time. So I'm going to talk a little bit about what's new in Drupal CMS as of 2.2, which we tagged on Friday. So the main thing that's new, and that Dries did touch on, I'll go into a little bit more detail, is that we've finally got sort of the multilingual out-of-the-box release. So we've improved the language selector in the installer. We've added a multilingual recipe, which does all of the basic stuff that you have to do when you're installing a site for multilingual. So enabling modules like Language and Locale and all of the things that you do too. And then you go to find — and then you — oh, I forgot about content. So all of those things that you had to do and remember to do them in order, you don't have to do those at all anymore. So it installs the foundational modules. It gives you this checklist that then takes you through the steps. So first you add the languages that you want. Then you just confirm that you're happy with the language detection settings. Then you select which content you want to be able to translate. And so this was also touched on in the DriesNote. But I mean, if anybody's ever done this before, this form was diabolical. I mean, you would check a box for content and then save and then come back and the form would reload and it hasn't changed. And it's because it added a fieldset down below that you had to expand, and then check all the checkboxes. So anyway, what we've done now is this is just a totally altered version of the form that provides a recommended setup for you to use if you want. If you don't want to use that, you don't have to. You can still do all of the usual customizations. And one of the other changes that we made — and I just want to say also that 99.999% of this work was done by Gábor Hojtsy, who's sitting here — is that this form will also now respect the settings of your site template. So you can ship your content types excluding fields such as, say, the byline for an article from being translatable by default. So obviously the site owner can still override that, but it just provides what we would call sensible defaults, whereas previously core would just check literally all the boxes and ignore those settings. So this is, I think, just a really great example of how we're improving this for Drupal CMS, but also we want to get this change into core. Maybe not exactly in the same format, but in some format we want to get this into core as well.
I just want to say that this is an area where there's a lot of — it's a big rabbit hole. I feel like we were barely able to get up from that rabbit hole to come talk about this. So if you're interested in helping us with multilingual, I think there's a lot of opportunity in here.
Canvas translations, multilingual ideas and product analytics
Yes. And I mean, the last thing, and probably the biggest thing, is that Canvas now supports translations for pages. So there's a contrib module called Canvas Translate, and it adds this handy little UI inside the Canvas editor that lets you translate each — the strings in each component. And also, if you have your AI provider enabled, you can enable the Canvas Translate AI module and just kind of get an initial AI-generated translation for each field. And then of course adapt them if you want. And then publish that content. And you can also use the preview. I wasn't able to get a screencast of that. But you can also use the Canvas preview to check the translation in each language. At the moment, we are doing this with 5 separate contrib modules, but essentially 4 of these should be going away because they will be adopted into either Drupal core or Drupal Canvas. The language checklist probably doesn't make sense to be adopted into Drupal core, and we might decide to enhance that, but this is to say that all of these things that we're doing, sometimes core can't do it quite as quickly as we need, so we do what we need to do, and then we'll work on getting that kind of folded back into core when we're able to. Then I'll talk a little bit about some of the things we're thinking about doing. And this is one that I really, really, really want feedback on because we've gone a little bit back and forth about this. But in doing some interviews with people and asking how they use multilingual, we found — and also some people had direct experience — that if you're installing a site in a language that doesn't have great UI translation coverage, you actually prefer the UI to remain in English. And that way you have sort of 2 separate languages. You have your content language and you have your admin language. So we — I see some nodding, so that's good. So we were thinking of including this in the installer. So in the initial installer selection screen that I showed you, we could add this little tick box. How this works, there are many variations of how this could work. But the checkbox to say keep the admin interface in English, or it could be a checkbox that says use the same language for the admin interface. Whatever we decide, I think if this feels like a useful feature, there's a lot to unpack here, because the distinction between admin strings and end user strings are not always clear, because you have things like webforms and commerce checkout forms that are config. So it does that. This is a lot to deal with. So if nobody wants this, we don't need to go down that road. But if this is useful for people, we would love to know and then we can spend a little bit more time unpacking and trying to figure out the best way to do this. Another thing we really want to do is create a translation dashboard. Canvas Translate provides this for the Canvas pages, but it would be great to have such a thing for the content as well. And potentially, to get both of those merged would be even cooler. And then another idea that we had that we weren't able to do just yet is — instead of the checklist that we created, which is a little bit of a workaround — what we really wanted to do is have a wizard that would actually take you through the questions that you need to answer. Which languages do you want? Which detection method do you want? What type of content do you want to translate? Later on, there would potentially be a question of, do you want asymmetric or symmetric translation? But Canvas doesn't support asymmetric just yet, so that's not a part of it. But maybe having this wizard could even make the process 20% simpler, whatever it is. And then just what's coming up next, so the future priorities. The big one that has developed over the last 48 hours, thanks to Adam Adam Globus-Hoenich, who's not here because he's preparing his session: we really want to get product analytics into Drupal CMS. Of course, with full GDPR compliance and opt-in consent by default. No worries there. But we really honestly just want to know some kind of simple stuff. We want to know what site templates people are choosing. We want to know how many new sites there are every month. We want to know what modules are being installed and uninstalled, and we want to know what recipes are being applied. Right now we have literally no idea who's using it, how they're using it, are we shipping with the right features. Any kind of analytics that we get is going to be really beneficial. So I think we'll probably start relatively simple and then just build on that as we kind of get the hang of it.
AI tooling, structure and headless with Drupal Canvas
So AI tooling is a big part of what we need to focus on next. There's a lot that has shipped, as you saw in the DriesNote, but there's still more way to go. As Dries alluded to, the goal with the AI tooling is essentially to allow every workflow and process that you would take in Drupal CMS to be able to be operated by an AI agent, obviously while keeping the humans in the loop. This might mean different things when you're working in production on content. This would mean your content workflows. When you're working locally, there's already human in the loop by the fact that in order to push your changes to production, someone needs to open a pull request and push it there. So we don't need quite — we don't need to own the governance loop when working in local development. So those are the sort of targets that we work on top of. This also means that with the introduction of the vibe coding platforms, we need to position Drupal CMS against the vibe coding platforms. And what Drupal CMS offers in there is essentially this enterprise-ready answer. And what that means is we provide you the governance. We provide you the tools that you need for collaboration in the platform. If you imagine something like Lovable, it's really just where anyone can do anything. And if you have a team of 10 people prompting in there, it's probably going to be quite a spaghetti that you get yourself into. Drupal CMS is able to absorb what you built in Lovable. You can turn those into code components quite easily. And now you have a platform where your content team can actually collaborate in. You saw in the release notes the example of how you can connect outside-in agents. So that's a big part of the focus for us. So we have AI both inside and outside. Right now we have a lot of focus on how do you use external AI agents, because there's a lot of sort of low-hanging fruit in a way in there, because we get all of the context, all of the tools that you have access to from your existing AI tools. So if you already use Claude or ChatGPT and you've connected it to a bunch of MCPs, you have a bunch of skills in there. What is interesting when I use Claude is also it has history, like it actually saves conversations that I have with it. So if I do vague references to something, it knows to go back to history and knows how to refer back to that, which makes it very easy and convenient to work with any kinds of products, including Drupal, as part of it. Outside-in AI could be done both through MCP — so that's primarily what your content creators might use — but there's also tooling that we are creating for local development. So that would be things like skills, for example, CLIs that you then just run in your local development environment. So that's basically where we want the AI. If you just, let's say in Cursor, when you're doing development, you're doing a task, it should know how to best accomplish the task in there because it has the full access to your site. It can do anything. It could run a raw database query to it. It could run a Drush command. We have skills that then help guide it: this is the right way to get to that, which makes it more efficient and more successful. A little bit more about what does Drupal bring in, especially when you compare it to vibe coding platforms, is Drupal brings you structure. It's not just about structured content. Structured content is a big part of it, but it's about how do you scale it? How do you add modules? How do you add an ecosystem around it? Because Drupal provides you a consistent structure with the entity system, it means that you can add capabilities from the module ecosystem. What's great about it is when you add something from the module ecosystem, you don't have to do a full code review of it. I mean, maybe some of you do. But that's why we have the security team coverage on these modules. It gives you some level of trust on modules that you're downloading from the ecosystem because they are providing coverage on them. You have permissioning in Drupal, and this actually applies to headless as well, which I'm going to talk more about briefly. Permissioning is not something to be taken for granted. It's obviously for your editor permissions, but also for permissions when you're creating authenticated content. If you need login, with Drupal it's very easy to build login portals, because the permission model is designed to support that. Drupal brings workflows and workspaces, so you can have legal reviews or translations go through the process that your organization follows. And then finally, Drupal is working with the best open standards, so you're not locked into any particular solution. So you can modify the underlying code because it's open source, and then you can connect different tools to it you already use. All right, now finally jumping on to headless. So this is going to be a fairly brief summary of headless, so if you want to hear more, Bálint will be talking about it tomorrow. Essentially with headless, the goal is to provide better experience for developers who are building with Drupal. We want to provide them the tools that make them pick Drupal. We want to keep the experience equivalent to what it is today for marketers. So this is headless without the trade-off where marketers need to give up control. The headless that we delivered — and this is actually in the next column even though this is part of Canvas, because this is not officially part of Drupal CMS yet. So you can get all of this as part of Drupal Canvas already today. You just have to install it yourself and there's no site templates for it today. There's essentially 3 parts to this. First is there's a new Content Delivery API, which allows the backend to essentially turn the content that you have into a flat static tree of components and the props that need to be rendered in there. It doesn't matter where the content is coming from. If it's an entity, if it's a module, if it's a third-party system, it could be translated into static props, and that then gets passed along to that component, which then makes the job very easy for this next layer, which is the Headless SDK, which essentially takes the output of that API and renders it using components that you've created. And the components follow a very similar structure to how you create components with code components or with SDC. So you have a YAML and then you have a JavaScript file pair, and the YAML file defines what are the props and slots that the component accepts, and then the JavaScript file renders the component. And the SDK simply just takes the output from the API and connects everything together in there. And then the final piece of this, which probably was the hardest part of this, is where you want to be able to live preview something that is rendered by your headless application. And you don't want to do that in a way where it gets published accidentally to the internet. So it needs to happen in full privacy. And so the Headless SDK and this Content Delivery API have authentication for draft content in there. And how it works is you just pass in your client URL and we automatically generate the [unclear, 35:13]. We run an OAuth process when we are in the preview session in there. We create a very short-lived token to render the preview. And using that, the client knows that, OK, I need to pass this key along when making requests against these APIs. And then once the key is there, it gets the same permissions that the user has to view that content. OK. This opens up very interesting opportunities. We've talked a lot about integrations in our past slides, but I want to mention that headless oftentimes for organizations also comes as an integration play. Let's say you have a customer who already adopted Shopify or commercetools as their go-to commerce platform. In order for them to adopt Drupal, if they don't use headless, they would have to essentially either have a different commerce platform, or they would have to somehow in PHP be able to render the commerce. They don't have SDKs in PHP, so they would have to essentially DIY that themselves. Or they would have to just move over to Drupal Commerce. Obviously, all of those are a lot of work for them to do. So the solution with headless is that most of these platforms are designed to work already with Next.js or Vue.js or Nuxt. And because of that, it's very easy for you to adopt both the Canvas headless as well as one of these commerce solutions. Commerce is just one of the examples that I have in here. It could be other examples. Many other platforms, like HubSpot and others, provide integrations in JavaScript to their platform. So now your clients can essentially then use tools that they already have in your headless application without putting a lot of effort. I built a demo application with Shopify Commerce in less than half an hour, where I had full Shopify Commerce experience and Drupal rendering content in there. That's how quickly you can set this up. Experience of getting started is actually very quick. Like, it's almost like where it's hard to believe that these are all the steps that you need to run. So you literally have to install the Canvas headless module. You need to scaffold an application. You can do that step manually if you have an existing application, but easiest way to get started is with the create command. You register your frontend in Canvas, so you just give the URL. And you open a page in Canvas. And then you're done at that point. If you have existing components that you've created with code components in React, what you can do is you can run canvas pull in this headless application. And it will pull the code components into your headless application, then if the framework that you're using supports React, they work as is. So if you use Next.js or Astro, those components would work there just after the pull. So now what Drupal CMS is planning to offer is essentially allowing you to choose which technology to go with. Do you want to go with coupled? That could be either code components or SDC. Or go with headless, where you get Next, Nuxt, Astro, TanStack Start, and now recently also Angular. I talked a little bit about the why already in here. I do want to hit on one more point, which is the full flexibility to also customize the backend in here, which you don't get if you go with SaaS headless platforms. With Drupal, you can customize any aspect of the backend, whether that's the UI or any of the workflows in there, but also where Drupal — you can make a direct comparison with Drupal and many of these other players in the SaaS headless market. Drupal actually offers a much broader spectrum than what they do. Oftentimes, if you actually want to achieve what Drupal does in terms of permissioning and governance, you would have to first take one of those SaaS headless solutions, then you have to add a middleware on top of it somewhere, and then you build your frontend application on top of it, which means that if you compare this now against many of those SaaS players, you actually get a lower total cost of ownership with this because you can do it with 2 platforms.
Try Drupal CMS and get involved
Well, that's it. So I think for those who haven't tried it, I encourage you to try it. If you don't want to download anything, you can use the brand new revamped simplytest.me, which Matt Glaman has graciously resurrected. So you can go there. I don't think that all of the site templates are on there, but a number of the site templates are on there, so you can one-click install those in under a minute, or the DDEV setup is really easy as well. It's just a different Composer create command. You can go through the installer or you can use Drush the old way. Yeah, we'd love for you to join us. There were a few areas we called out that we would love some help with. I think documentation's probably pretty up there, and then also just feedback on the multilingual things that I mentioned, or if there are things I didn't mention that you want to talk to us about. We are very active in Slack, and given that I'm based in Australia, Lauri's based in Finland, and we have several contributors in the US, we have basically every time zone covered. So any hour of the day, someone will be around to chat.
We love hearing feedback.
We do.
Yeah, so long as you are being productive and not ass about it. So there's a difference between the two. Any kind of feedback, even if it's critical feedback, is welcome.
I have full confidence in everyone in this room that they know how to provide constructive feedback.
I have to be — this goes also on the recording.
Oh sure, oh yes, oh yeah. Those people can't be trusted, yeah.
It is the internet, after all.
Yeah, yeah, yeah, you're right. Sorry.
This transcript was generated from the session recording and corrected for names and Drupal terminology. Timestamps link to the moment in the video. Spotted an error? Suggest a correction on drupal.org.
Session page template for DrupalCon Rotterdam 2026. Video and transcript published by the Drupal Association.