A Drupal site with many years of life, one or more migrations, or frequent content changes accumulates redirects automatically. Every alias change and every moved page leaves one behind, until there are hundreds or even thousands of them. A new project gets there too once content starts to be created, redirects added, and URLs moved.
The problem is silent. Nobody decides to create a redirect chain; chains appear when redirects pile up on top of each other over time. Reviewing them manually is unfeasible because of the time it would take, so they stay. These situations usually surface in audits run with different tools: until that moment they go unnoticed.
A redirect chain is several hops in a row: a → b → c → d. Each additional hop increases navigation latency for users and makes crawling harder for search engines. Keeping every redirect at a single hop contributes to better SEO.
Googlebot follows up to 10 hops in a chain before giving up, but …
read more
Today we are talking about Drupalcon Rotterdam, Canvas and evaluating modules. We'll also cover Revision Graph as our module of the week.
For show notes visit: https://www.talkingDrupal.com/573
TopicsNic Laflin - nLighteneddevelopment.com nicxvan Martin Anderson-Clutz - mandclu.com mandclu Tim Sharp - tea-sharp
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
read more
This blog has been re-posted and edited with permission from Dries Buytaert's blog.
Drupal is now light-years ahead of its reputation. Closing that gap is our #1 challenge, and it was the main message of my DrupalCon Rotterdam keynote.
Just over two years ago, I launched Drupal Starshot. I did it because I wasn't sure we could still innovate like we used to. It turns out we can.
Starshot became Drupal CMS, which brings together Site Templates, Recipes, Drupal AI, Drupal Canvas and more to make building websites easier.
Alongside that work, Drupal Core has become a faster and better framework for developers. A stronger Drupal Core helps us build a better Drupal CMS, while building Drupal CMS has driven further improvements in Drupal Core.
Unfortunately, many people outside the Drupal community haven't seen what Drupal can do today. In Rotterdam, I showed how far we have come and where we're going next, and we launched an advocacy program to help more people see how great Drupal has become.
If you missed the keynote, you can watch the video below or download my slides (86 MB).
The first part of my keynote showed improvements for multilingual sites, JavaScript front-ends, headless Canvas, and Drupal AI.
Drupal has long had strong multilingual capabilities, but Drupal Canvas, our powerful new page builder, didn't yet support multilingual sites. Not only did we add multilingual support to Canvas, but we made all multilingual sites easier to set up.
React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.
At DrupalCon, we extended that same model with Drupal Canvas Headless. Developers can now use Drupal to manage content while building the front-end separately with frameworks like Next.js, Astro, TanStack, Angular, or Nuxt. Editors still get the visual experience of Drupal Canvas: they can build pages in Drupal and preview exactly how those pages will appear on the front-end.
This changes an important trade-off. Teams no longer have to choose between a modern JavaScript front-end and Drupal Canvas' visual authoring experience. They can have both. That opens Drupal to more developers, more front-end architectures, and more types of projects.
Drupal AI is moving so fast that I could have filled a whole keynote with it. Instead, we launched a new Drupal AI demo where people can experience Drupal AI for themselves. It comes preconfigured, making it easy to explore what Drupal AI can do or even show it to customers.
With the latest Drupal AI, you can ask questions and get answers grounded in your site's content. You can audit your content against brand guidelines, translate content, classify content, build pages and React components with AI, and more. Through MCP, AI assistants can work with Drupal content from outside Drupal.
What excites me most is the foundation underneath all of this. Drupal AI turns Drupal into an AI harness: organizations can connect AI models to structured content, tools, and workflows, while keeping control through permissions, guardrails, observability, metering, and a choice of AI models.
The second part of my keynote looked at another important shift: AI assistants can give people a new way to work with Drupal.
In one demo, an editor simply asked an AI assistant to unpublish a page. They didn't need to know where to click or understand Drupal's revisions, moderation workflows, or permissions. The assistant translated their intent into action, but Drupal remained in control: it checked whether the editor was allowed to unpublish the page and applied the site's publishing rules, just as it would if they had done it by hand.
If you want to see the demo in more detail, Scott Falconer, who worked on it, recorded a behind-the-scenes walkthrough showing how to set it up yourself, what happens under the hood, and how to get involved.
That demo was built on the Tool module, which I believe is one of the most important modules for Drupal developers to watch. Drupal modules already contain thousands of useful capabilities: publishing content, managing users, processing media, changing configuration, and much more. The Tool module gives developers a standard way to expose those capabilities so AI assistants and other software can discover and use them.
Today, exposing existing capabilities as tools can still require too much code. My own album module didn't expose tools, and making its existing capabilities available to an AI assistant took about 1,000 additional lines of code.
But once those tools were available, the value became obvious. Adding MCP support has already changed how I manage the more than 10,000 photos on my site. Tasks that used to take a lot of time can now be done much faster and more accurately with an AI assistant, while Drupal still manages the content, permissions, and workflows underneath.
That experience reinforced something I wrote about in AI and the great CMS unbundling: AI can take on more of the execution work while Drupal remains the control layer. I expect more organizations will want to manage parts of their sites through AI assistants. AI can make complex tasks much faster and easier without giving up the structure, governance, and safeguards that Drupal provides.
I believe thousands of module developers will eventually want to expose their capabilities in the same way, so I've been working with Matt Glaman to make it much easier. Matt has been developing a change to the Tool API that lets developers expose existing PHP methods as tools using attributes.
The idea is simple: add PHP attributes to an existing method to describe its name, purpose, inputs and outputs. In my album module, roughly 1,000 lines of integration code became about 20 attributes. My site already uses the experimental branch, and we're working to get it merged into the Tool module proper.
And this isn't only about AI. The same tools can be called by AI assistants over MCP, by other applications over HTTP, or used to generate schemas for JavaScript components and connect Drupal modules to workflow systems like ECA, FlowDrop, and Maestro. The video below shows FlowDrop using capabilities exposed by my album module:
In the last part of my keynote, I came back to Drupal's reputation gap. We can make enormous progress with Drupal, but that doesn't automatically change what people or AI agents think of it. For example, an AI coding agent I tested in June didn't even mention Drupal CMS or Site Templates when it evaluated Drupal.
Over the past few years, much of my personal focus has been on accelerating innovation in Drupal. That work is paying off, and we have real product momentum. I'm now shifting more of my attention to the other side of the equation: making sure people see what we've built, understand what has changed, and know why it matters.
So I announced the Drupal Advocacy Program, led by the Drupal Association.
Drupal already has a contribution credit system. It recognizes the people who contribute to Drupal and the organizations that support their work. For businesses, those credits also help determine visibility in the Drupal marketplace. Until now, we've been much better at recognizing technical contributions and financial support than advocacy work.
The new Drupal Advocacy Program will change that. Advocacy work can now earn contribution credit, and work that reaches people outside the existing Drupal community can earn more weight.
If we want to close Drupal's reputation gap, we can't only talk to people who already know Drupal well. We need more talks at external events, articles in broader publications, customer stories, demos, tutorials, and other work that helps people see what Drupal can do today.
Blue Drop Labs is a good example of what I mean. The day after the DriesNote, they published a post on building a website with Drupal CMS and Canvas Headless. The project itself was already live, but they quickly turned that work into a story others could learn from, with demos showing how editors and developers work with Drupal today.
That is exactly what I mean by "talking louder". There is already a lot of impressive Drupal work happening. We need to do a better job of showing it to the world.
I was a little nervous about announcing the Advocacy Program. We've wrestled with Drupal's reputation gap for a long time, and I felt we needed to do more than acknowledge it. Using contribution credit to reward advocacy was a concrete way to change the incentives, but I wasn't sure how the community would react.
It turned out to be one of the best-received announcements of the keynote. That response gave me confidence that people were ready to act on the reputation gap, not just recognize it.
You can learn how to earn Drupal advocacy credit and submit your advocacy work.
My ask is simple: talk louder about Drupal, especially to people outside our community. Drupal doesn't need hype, but we do need a better public record. We need more people showing, with real examples, what Drupal can do today.
I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Bálint Kléri, Christoph Breidert, Gábor Hojtsy, Lauri Timmanee, Matt Glaman, Michael Lander, Pamela Barone, Shibin Das, and the Drupal AI partners. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.
This blog has been re-posted and edited with permission from Dries Buytaert's blog.
Drupal is now light-years ahead of its reputation. Closing that gap is our #1 challenge, and it was the main message of my DrupalCon Rotterdam keynote.
Just over two years ago, I launched Drupal Starshot. I did it because I wasn't sure we could still innovate like we used to. It turns out we can.
Starshot became Drupal CMS, which brings together Site Templates, Recipes, Drupal AI, Drupal Canvas and more to make building websites easier.
Alongside that work, Drupal Core has become a faster and better framework for developers. A stronger Drupal Core helps us build a better Drupal CMS, while building Drupal CMS has driven further improvements in Drupal Core.
Unfortunately, many people outside the Drupal community haven't seen what Drupal can do today. In Rotterdam, I showed how far we have come and where we're going next, and we launched an advocacy program to help more people see how great Drupal has become.
If you missed the keynote, you can watch the video below or download my slides (86 MB).
The first part of my keynote showed improvements for multilingual sites, JavaScript front-ends, headless Canvas, and Drupal AI.
Drupal has long had strong multilingual capabilities, but Drupal Canvas, our powerful new page builder, didn't yet support multilingual sites. Not only did we add multilingual support to Canvas, but we made all multilingual sites easier to set up.
React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.
At DrupalCon, we extended that same model with Drupal Canvas Headless. Developers can now use Drupal to manage content while building the front-end separately with frameworks like Next.js, Astro, TanStack, Angular, or Nuxt. Editors still get the visual experience of Drupal Canvas: they can build pages in Drupal and preview exactly how those pages will appear on the front-end.
This changes an important trade-off. Teams no longer have to choose between a modern JavaScript front-end and Drupal Canvas' visual authoring experience. They can have both. That opens Drupal to more developers, more front-end architectures, and more types of projects.
Drupal AI is moving so fast that I could have filled a whole keynote with it. Instead, we launched a new Drupal AI demo where people can experience Drupal AI for themselves. It comes preconfigured, making it easy to explore what Drupal AI can do or even show it to customers.
With the latest Drupal AI, you can ask questions and get answers grounded in your site's content. You can audit your content against brand guidelines, translate content, classify content, build pages and React components with AI, and more. Through MCP, AI assistants can work with Drupal content from outside Drupal.
What excites me most is the foundation underneath all of this. Drupal AI turns Drupal into an AI harness: organizations can connect AI models to structured content, tools, and workflows, while keeping control through permissions, guardrails, observability, metering, and a choice of AI models.
The second part of my keynote looked at another important shift: AI assistants can give people a new way to work with Drupal.
In one demo, an editor simply asked an AI assistant to unpublish a page. They didn't need to know where to click or understand Drupal's revisions, moderation workflows, or permissions. The assistant translated their intent into action, but Drupal remained in control: it checked whether the editor was allowed to unpublish the page and applied the site's publishing rules, just as it would if they had done it by hand.
If you want to see the demo in more detail, Scott Falconer, who worked on it, recorded a behind-the-scenes walkthrough showing how to set it up yourself, what happens under the hood, and how to get involved.
That demo was built on the Tool module, which I believe is one of the most important modules for Drupal developers to watch. Drupal modules already contain thousands of useful capabilities: publishing content, managing users, processing media, changing configuration, and much more. The Tool module gives developers a standard way to expose those capabilities so AI assistants and other software can discover and use them.
Today, exposing existing capabilities as tools can still require too much code. My own album module didn't expose tools, and making its existing capabilities available to an AI assistant took about 1,000 additional lines of code.
But once those tools were available, the value became obvious. Adding MCP support has already changed how I manage the more than 10,000 photos on my site. Tasks that used to take a lot of time can now be done much faster and more accurately with an AI assistant, while Drupal still manages the content, permissions, and workflows underneath.
That experience reinforced something I wrote about in AI and the great CMS unbundling: AI can take on more of the execution work while Drupal remains the control layer. I expect more organizations will want to manage parts of their sites through AI assistants. AI can make complex tasks much faster and easier without giving up the structure, governance, and safeguards that Drupal provides.
I believe thousands of module developers will eventually want to expose their capabilities in the same way, so I've been working with Matt Glaman to make it much easier. Matt has been developing a change to the Tool API that lets developers expose existing PHP methods as tools using attributes.
The idea is simple: add PHP attributes to an existing method to describe its name, purpose, inputs and outputs. In my album module, roughly 1,000 lines of integration code became about 20 attributes. My site already uses the experimental branch, and we're working to get it merged into the Tool module proper.
And this isn't only about AI. The same tools can be called by AI assistants over MCP, by other applications over HTTP, or used to generate schemas for JavaScript components and connect Drupal modules to workflow systems like ECA, FlowDrop, and Maestro. The video below shows FlowDrop using capabilities exposed by my album module:
In the last part of my keynote, I came back to Drupal's reputation gap. We can make enormous progress with Drupal, but that doesn't automatically change what people or AI agents think of it. For example, an AI coding agent I tested in June didn't even mention Drupal CMS or Site Templates when it evaluated Drupal.
Over the past few years, much of my personal focus has been on accelerating innovation in Drupal. That work is paying off, and we have real product momentum. I'm now shifting more of my attention to the other side of the equation: making sure people see what we've built, understand what has changed, and know why it matters.
So I announced the Drupal Advocacy Program, led by the Drupal Association.
Drupal already has a contribution credit system. It recognizes the people who contribute to Drupal and the organizations that support their work. For businesses, those credits also help determine visibility in the Drupal marketplace. Until now, we've been much better at recognizing technical contributions and financial support than advocacy work.
The new Drupal Advocacy Program will change that. Advocacy work can now earn contribution credit, and work that reaches people outside the existing Drupal community can earn more weight.
If we want to close Drupal's reputation gap, we can't only talk to people who already know Drupal well. We need more talks at external events, articles in broader publications, customer stories, demos, tutorials, and other work that helps people see what Drupal can do today.
Blue Drop Labs is a good example of what I mean. The day after the DriesNote, they published a post on building a website with Drupal CMS and Canvas Headless. The project itself was already live, but they quickly turned that work into a story others could learn from, with demos showing how editors and developers work with Drupal today.
That is exactly what I mean by "talking louder". There is already a lot of impressive Drupal work happening. We need to do a better job of showing it to the world.
I was a little nervous about announcing the Advocacy Program. We've wrestled with Drupal's reputation gap for a long time, and I felt we needed to do more than acknowledge it. Using contribution credit to reward advocacy was a concrete way to change the incentives, but I wasn't sure how the community would react.
It turned out to be one of the best-received announcements of the keynote. That response gave me confidence that people were ready to act on the reputation gap, not just recognize it.
You can learn how to earn Drupal advocacy credit and submit your advocacy work.
My ask is simple: talk louder about Drupal, especially to people outside our community. Drupal doesn't need hype, but we do need a better public record. We need more people showing, with real examples, what Drupal can do today.
I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Bálint Kléri, Christoph Breidert, Gábor Hojtsy, Lauri Timmanee, Matt Glaman, Michael Lander, Pamela Barone, Shibin Das, and the Drupal AI partners. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.
Yet another amazing DrupalCon Europe has come to an end, leaving us with unforgettable memories. This time, we gathered in a city where futuristic architecture meets historic streets, home to Europe’s largest port and an absolutely unique food market. Rotterdam is a city that has embraced the future and innovation and is sailing towards it with all sails set.
read moreSponsorship for Drupal Mountain Camp 2027 is now open. On March 2-4, 2027, the camp returns to Davos Congress for its sixth edition, ten years after the first gathering in 2017.
This year's theme is Humans with AI in the loop. Over three days of talks, hands-on workshops and contribution sprints, we look at how AI is changing the way we build software, why digital sovereignty matters, and where open source fits in.
The camp brings together people who care about the open web: developers, designers, AI practitioners, public-sector teams and open source communities from Switzerland and beyond.
As a sponsor, you have a visible place at the camp and time to talk with the people who attend. Sponsoring lets you:
We welcome sponsors of any size and from any field who want to support an open, independent web.
There are four packages: Platinum, Gold, Silver and Bronze. Places are limited, with 3 Platinum, 5 Gold and 8 Silver packages available.
Depending on the package, benefits include:
Every package includes conference tickets and a logo on our sponsor page.
If you would like to support a specific part of the camp, you can also sponsor the opening reception, a social event, the session recordings, the coffee breaks or a diversity scholarship.
You can find all packages and what they include on our sponsorship page.
To become a sponsor or ask a question, write to us at info@drupalmountaincamp.ch.
To stay up to date, subscribe to our newsletter and follow us on Mastodon, Instagram, Bluesky and LinkedIn.
We look forward to hearing from you.
The Drupal Security Team is pleased to announce that four provisional members have been added as full members of the team: Pierre Rudloff (prudloff), Joseph Zhao (pandaski), Bram Driesen (bramdriesen), and Swan Kalata (akalata). Each has demonstrated their commitment, trustworthiness, and effectiveness during their provisional membership, and we're proud to welcome them as full members of the team.
Pierre is a web developer based in Lille, France, working with Insite. He has been an active Drupal project contributor and software tester since 2019 and holds over 70 security advisory credits. Pierre recently created the Drupal Security Tips repository, a valuable resource that documents recurring vulnerability patterns drawn from two years of security advisories and their associated patches.
Joseph is a solution architect and open-source developer who has been designing, building, and supporting open-source solutions since 2004. He is a prolific contributor to the Drupal ecosystem, having contributed patches, modules, themes, installation profiles, documentation, translations, and automated tests. Joseph has also reviewed project applications and serves as a mentor to newer contributors. He has been a Drupal.org community member for over 13 years.
Bram is a Drupal developer at Sopra Steria, based in Belgium, and has been an active contributor to the Drupal ecosystem since 2015. His involvement extends well beyond code: he is a co-organizer for the Drupal User Group Belgium (DUG BE) and Photography Lead for DrupalCon Europe, with experience organizing events such as the Antwerp, Ghent and Leuven DrupalCamps and Drupal Dev Days Ghent.
Swan is an Architect and Technical Lead at Tag1 Consulting, Inc., based in the United States. They have been an active Drupal community member for nearly 17 years and are a prolific contributor with credits on over 180 issues—including nearly 70 for Drupal core. Their involvement extends well beyond code: they are a community mentor and have participated in numerous international DrupalCon events.
Promoting Pierre, Joseph, Bram, and Swan to full membership strengthens our ability to review vulnerabilities, coordinate with maintainers, and improve the overall security posture of the Drupal project. They join over 20 volunteers currently on the team.
Welcome to the team, Pierre, Joseph, Bram, and Swan!
If you would like to join the team, please read how to join the Drupal Security Team.
This post is a little late. Thanks for your patience :)
AI was used in the drafting of this post. Also thanks for support from pandaski, akalata, bramdriesen, prudloff, larowlan, benjifisher, poker10, xjm, mlhess in drafting this post.
Drupal is now light-years ahead of its reputation. Closing that gap is our #1 challenge, and it was the main message of my DrupalCon Rotterdam keynote.
Just over two years ago, I launched Drupal Starshot. I did it because I wasn't sure we could still innovate like we used to. It turns out we can.
Starshot became Drupal CMS, which brings together Site Templates, Recipes, Drupal AI, Drupal Canvas and more to make building websites easier.
Alongside that work, Drupal Core has become a faster and better framework for developers. A stronger Drupal Core helps us build a better Drupal CMS, while building Drupal CMS has driven further improvements in Drupal Core.
Unfortunately, many people outside the Drupal community haven't seen what Drupal can do today. In Rotterdam, I showed how far we have come and where we're going next, and we launched an advocacy program to help more people see how great Drupal has become.
If you missed the keynote, you can watch the video below or download my slides (86 MB).
The first part of my keynote showed improvements for multilingual sites, JavaScript front-ends, headless Canvas, and Drupal AI.
Drupal has long had strong multilingual capabilities, but Drupal Canvas, our powerful new page builder, didn't yet support multilingual sites. Not only did we add multilingual support to Canvas, but we made all multilingual sites easier to set up.
React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.
At DrupalCon, we extended that same model with Drupal Canvas Headless. Developers can now use Drupal to manage content while building the front-end separately with frameworks like Next.js, Astro, TanStack, Angular, or Nuxt. Editors still get the visual experience of Drupal Canvas: they can build pages in Drupal and preview exactly how those pages will appear on the front-end.
This changes an important trade-off. Teams no longer have to choose between a modern JavaScript front-end and Drupal Canvas' visual authoring experience. They can have both. That opens Drupal to more developers, more front-end architectures, and more types of projects.
Drupal AI is moving so fast that I could have filled a whole keynote with it. Instead, we launched a new Drupal AI demo where people can experience Drupal AI for themselves. It comes preconfigured, making it easy to explore what Drupal AI can do or even show it to customers.
With the latest Drupal AI, you can ask questions and get answers grounded in your site's content. You can audit your content against brand guidelines, translate content, classify content, build pages and React components with AI, and more. Through MCP, AI assistants can work with Drupal content from outside Drupal.
What excites me most is the foundation underneath all of this. Drupal AI turns Drupal into an AI harness: organizations can connect AI models to structured content, tools, and workflows, while keeping control through permissions, guardrails, observability, metering, and a choice of AI models.
The second part of my keynote looked at another important shift: AI assistants can give people a new way to work with Drupal.
In one demo, an editor simply asked an AI assistant to unpublish a page. They didn't need to know where to click or understand Drupal's revisions, moderation workflows, or permissions. The assistant translated their intent into action, but Drupal remained in control: it checked whether the editor was allowed to unpublish the page and applied the site's publishing rules, just as it would if they had done it by hand.
If you want to see the demo in more detail, Scott Falconer, who worked on it, recorded a behind-the-scenes walkthrough showing how to set it up yourself, what happens under the hood, and how to get involved.
That demo was built on the Tool module, which I believe is one of the most important modules for Drupal developers to watch. Drupal modules already contain thousands of useful capabilities: publishing content, managing users, processing media, changing configuration, and much more. The Tool module gives developers a standard way to expose those capabilities so AI assistants and other software can discover and use them.
Today, exposing existing capabilities as tools can still require too much code. My own album module didn't expose tools, and making its existing capabilities available to an AI assistant took about 1,000 additional lines of code.
But once those tools were available, the value became obvious. Adding MCP support has already changed how I manage the more than 10,000 photos on my site. Tasks that used to take a lot of time can now be done much faster and more accurately with an AI assistant, while Drupal still manages the content, permissions, and workflows underneath.
That experience reinforced something I wrote about in AI and the great CMS unbundling: AI can take on more of the execution work while Drupal remains the control layer. I expect more organizations will want to manage parts of their sites through AI assistants. AI can make complex tasks much faster and easier without giving up the structure, governance, and safeguards that Drupal provides.
I believe thousands of module developers will eventually want to expose their capabilities in the same way, so I've been working with Matt Glaman to make it much easier. Matt has been developing a change to the Tool API that lets developers expose existing PHP methods as tools using attributes.
The idea is simple: add PHP attributes to an existing method to describe its name, purpose, inputs and outputs. In my album module, roughly 1,000 lines of integration code became about 20 attributes. My site already uses the experimental branch, and we're working to get it merged into the Tool module proper.
And this isn't only about AI. The same tools can be called by AI assistants over MCP, by other applications over HTTP, or used to generate schemas for JavaScript components and connect Drupal modules to workflow systems like ECA, FlowDrop, and Maestro. The video below shows FlowDrop using capabilities exposed by my album module:
In the last part of my keynote, I came back to Drupal's reputation gap. We can make enormous progress with Drupal, but that doesn't automatically change what people or AI agents think of it. For example, an AI coding agent I tested in June didn't even mention Drupal CMS or Site Templates when it evaluated Drupal.
Over the past few years, much of my personal focus has been on accelerating innovation in Drupal. That work is paying off, and we have real product momentum. I'm now shifting more of my attention to the other side of the equation: making sure people see what we've built, understand what has changed, and know why it matters.
So I announced the Drupal Advocacy Program, led by the Drupal Association.
Drupal already has a contribution credit system. It recognizes the people who contribute to Drupal and the organizations that support their work. For businesses, those credits also help determine visibility in the Drupal marketplace. Until now, we've been much better at recognizing technical contributions and financial support than advocacy work.
The new Drupal Advocacy Program will change that. Advocacy work can now earn contribution credit, and work that reaches people outside the existing Drupal community can earn more weight.
If we want to close Drupal's reputation gap, we can't only talk to people who already know Drupal well. We need more talks at external events, articles in broader publications, customer stories, demos, tutorials, and other work that helps people see what Drupal can do today.
Blue Drop Labs is a good example of what I mean. The day after the DriesNote, they published a post on building a website with Drupal CMS and Canvas Headless. The project itself was already live, but they quickly turned that work into a story others could learn from, with demos showing how editors and developers work with Drupal today.
That is exactly what I mean by "talking louder". There is already a lot of impressive Drupal work happening. We need to do a better job of showing it to the world.
I was a little nervous about announcing the Advocacy Program. We've wrestled with Drupal's reputation gap for a long time, and I felt we needed to do more than acknowledge it. Using contribution credit to reward advocacy was a concrete way to change the incentives, but I wasn't sure how the community would react.
It turned out to be one of the best-received announcements of the keynote. That response gave me confidence that people were ready to act on the reputation gap, not just recognize it.
You can learn how to earn Drupal advocacy credit and submit your advocacy work.
My ask is simple: talk louder about Drupal, especially to people outside our community. Drupal doesn't need hype, but we do need a better public record. We need more people showing, with real examples, what Drupal can do today.
I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Bálint Kléri, Christoph Breidert, Gábor Hojtsy, Lauri Timmanee, Matt Glaman, Michael Lander, Pamela Barone, Shibin Das, and the Drupal AI partners. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.
read moreDuring the Driesnote at DrupalCon Rotterdam, one of the closing points was that Drupal has evolved light years beyond its reputation. And that's true. But it's also true that there is a whole world of people out there who've never heard of Drupal, and we need to talk about it differently to them than we do when talking amongst the Drupal-aware.
Enter The October "Off the Drupal Island" challenge.
The gist: During this, the spoooookiest month, go out to a local event (meetup, hackathon, etc.) where Drupal isn't, and no one has ever heard of "Drush" or a render array. ;) And ideally, where their local community presence is larger than ours.
For example:
NOT to pitch Drupal! To learn, quickly, and at scale. Be curious. Talk to people. Find out more about what they're building, where they're struggling, and what they wish was better.
Then, post a mini "field report" about your journey to this issue (there's a handy template there if you like).
We'll circle back on these learnings in a November AI Learners Club meeting, and strategize what kind of demo(s) we think would resonate best with these audiences, reflecting back their words and their use cases and pain points.
Then, we get louder about Drupal to them. ;) #DevRel at global scale.
Note: If you need extra incentive, perhaps because the idea of talking to strangers is slightly terrifying to you ;) note that this community research work qualifies you for credits under the new Drupal Advocacy program. \m/
For discussion, see LinkedIn: https://www.linkedin.com/feed/update/urn:li:activity:7513498359781826560/
So, last week was quite a big week, really. Both for me personally, more of that in a moment, and for the Drupal project as a whole, I think.
Drupal Views exposed filters tend to accumulate controls.
A basic search form may start with a keyword field and a few filters. Add sorting and an items-per-page selector, and Drupal naturally renders everything as part of the same exposed form.
That makes sense structurally. It does not always make sense visually.
Sorting often belongs above the results. Items per page may belong next to pagination. Filters might live in a sidebar or drawer.
The HTML form attribute gives us a simple way to separate those concerns.
Most of the time, an input belongs to the <form> that contains it.
But HTML allows controls to explicitly reference a form by ID:
<form id="search-form"> <input name="keywords"> <button type="submit">Search</button> </form> <select name="sort" form="search-form"> <option value="date">Date</option> <option value="title">Title</option> </select>
The <select> can live anywhere in the document and will still participate in search-form when it is submitted.
That is particularly useful with Drupal Views exposed filters.
Instead of forcing every exposed control into one visual group, Twig can put them where they make sense:
{{ exposed|without('sort_by', 'items_per_page') }} <div class="results-sort"> {{ exposed.sort_by }} </div> {{ rows }} <div class="results-footer"> {{ pager }} {{ exposed.items_per_page }} </div>
Then a form alter can associate those controls with the original exposed form:
/** * Implements hook_form_views_exposed_form_alter(). */ function example_form_views_exposed_form_alter( array &$form, FormStateInterface $form_state, string $form_id, ): void { foreach (['sort_by', 'items_per_page'] as $key) { if (isset($form[$key])) { $form[$key]['#attributes']['form'] = $form['#id']; } } }
Drupal still owns the form. The browser still understands which controls belong to it. The template gets considerably more freedom.
The same technique can help with controls in sticky toolbars, dialog footers, complex search layouts, or other interfaces where form controls need to appear outside their natural DOM container.
Moving controls outside the form changes more than layout.
JavaScript that relies on closest('form') will no longer work. CSS such as form select will not match detached controls. Events from those controls also do not bubble through the form element because the form is no longer their DOM ancestor.
The form ID also becomes part of the implementation contract, which matters when multiple Views or exposed forms appear on the same page.
These are manageable constraints, but they are worth documenting.
The form attribute gives us form ownership, not DOM nesting.
There is also a small but interesting Drupal contrib opportunity here.
A module could allow site builders to configure which exposed Views elements should receive a form attribute and which should autosubmit.
The theme would remain responsible for placement. The module would simply provide the form association and optional behavior.
That could eliminate a recurring bit of project-specific PHP and JavaScript while relying primarily on native browser behavior.
For a relatively obscure HTML attribute, form opens up a useful amount of flexibility in Drupal Views. It lets the markup follow the interface instead of forcing the interface to follow the form.
For additional information on the form attribute, checkout the docs.
Most AI writing tools live in another browser tab. You copy text out, write a prompt, copy the answer back and fix the formatting. We wanted to get rid of that loop for people who write online. Gutenberg AI is the product we are building to fix that. It brings AI into the Gutenberg block editor, right next to the content it works on.
It is built on the Drupal AI framework, so it works with the chat provider you already use, whether that is OpenAI, Anthropic or a model running locally through Ollama. Everything it produces is standard Gutenberg blocks, so there is no lock-in.
A quick note before the tour: this is not a finished service yet. Gutenberg AI is under heavy development, features change from week to week and some of what you see here is still being tuned. We are sharing it now because we want to shape it together with the people who will use it. Here is a first look at what already works in our development builds.
In this post
Select a text block and the AI menu covers the everyday jobs: improve writing, summarize, expand, fix spelling and grammar, change the tone or translate. Highlight a single sentence and a small bar appears under it, so you can rewrite just that passage and keep or discard the result on the spot. Links and emphasis survive the round trip.
A few details we are especially happy with:
It comes with tones like Formal, Friendly and Plain language, and admins can swap them for the readers your site actually writes for, such as prospective students or the press.
Press Ctrl/Cmd+J and the next sentences appear as grey ghost text at your cursor. Tab accepts, Esc dismisses.
Paste from Word or Google Docs and Gutenberg AI offers to rebuild it as real headings, paragraphs and lists, keeping every sentence.
Found an instruction that works? Save it under your own name and reuse it from your AI menu.
Real time one paragraph or all the page translation, with image alt text as well.
Keep typing while the AI works and it will not overwrite you. The result is offered for review instead.
The AI Assistant sidebar is where Gutenberg AI goes beyond a single block. Ask it to “add a pricing section with three columns” or “remove the last paragraph” and it changes the page for you, using the blocks your site already has, including custom and third-party ones.
It can also do the heavy lifting on a blank page:
Paste your notes, approve an outline and the page is written section by section. Stop whenever you like.
Drop in a document and get a structured page back, with the images from the PDF placed on the page.
Regroup existing content into sections, rows and columns using your theme's own colors and spacing, without touching the text or images.
With the AI Agents module, ask it to “summarize our About page into this intro” and it looks up the real page and suggests internal links, limited to what you are allowed to see.
Every change is accountable. Applied changes are highlighted on the page, and each one has a before and after view and its own Revert button. Prefer to approve first? Turn on review mode and proposed edits show up as tracked changes, with added words in green and removed words in red, ready to accept or reject block by block.
Sometimes you just need a chunk of content with a specific layout. Use the AI block within the editor or the right sidebar AI assistant, describe what you want and watch it stream in as standard Gutenberg blocks: columns, groups, buttons and tables. Maybe use some of your custom blocks too? One-click presets cover pricing tables, FAQs, calls to action and a lot more.
Content clarity checks run live in the browser, with no AI call and no cost. Colored underlines flag long sentences, repeated words, your site's banned terms, vague link text like “click here” (Norwegian phrases included), images without alt text and skipped heading levels. Hedging words, complex words and passive voice are checked in both English and Norwegian, and adverbs in English. Most issues come with a one-click fix.
A live LIX readability score works well for Norwegian, and each content type can have its own target. The score turns red when a draft goes over it. When you want a deeper review, one click checks the whole draft against your own style guide and terminology and underlines the exact phrases that break a rule.
For newsrooms and communication teams, the Editorial Desk adds a review layer powered by TypeSafe. It reviews the draft as you write and checks claims against your reference notes, marking each one as supported, contradicted or unverified. It also flags headlines that overpromise or miss the story, checks the text against up to five editorial policies and scores how well it serves different types of readers.
Any finding can be shown in the draft or handed to the assistant for a proposed fix. Full transparency is built in: you see which model ran each check, how confident it was and what it cost. The Editorial Desk requires a TypeSafe subscription.
Generate an image straight from an empty Image block and keep writing while it works in the background. It is saved to the media library with the prompt as starting alt text. For existing images, a vision model writes the missing alt text, one image at a time or in bulk from a dedicated screen, and a Drush command handles large sites.
AI in a CMS has to answer to more than the editor, so we are building the controls in from the start:
Decide the most the assistant may send: the full document, the structure only, the selection, or nothing at all. Editors can narrow it further, and an optional preview shows exactly what leaves the site.
A dashboard shows requests, tokens, latency and cost by provider and model. Monthly budgets per role and per operation stop requests before they reach the provider.
The site's style guide and terminology apply to every action, the assistant and every review.
Broken or unsafe AI output, including unsafe markup and links, is rejected before it touches the page.
Each action can be switched on or off and given its own model and prompt, with separate permissions for text actions, the assistant, images and the Editorial Desk.
The best way to make Gutenberg AI good is to put it in front of real editors early. We are looking for a small group of organizations that want to test it on their own content and in their own workflows.
As a tester you get early access and a direct line to the people building it, and your feedback goes straight into what we build next.
In return we ask for honest feedback on what works, what does not and what is missing.
It is a good fit if you run Drupal with the Gutenberg editor, or are open to trying it, and your editors publish regularly. Universities, the public sector and newsrooms are especially welcome.
Contact us at Ramsalt and mention “Gutenberg AI testing” in your message. Tell us a little about your site and your editors, and we will set up a meeting to walk you through it and see if it is a good match.
A buyer asks an AI assistant about your product, but the answer sits behind a click or an outdated page. A Drupal AI-readability audit checks whether intended services can reach your content, whether HTML delivers useful answers, and whether facts stay consistent across outputs.
Maciej Lukianski walks through five layers beyond classic SEO: access, delivered HTML, buyer questions, JSON-LD alignment, and multilingual consistency, plus what actionable findings should look like.
read moreChoosing a CMS for catalogues, multilingual pages, and integrations means comparing how each platform handles relationships, editorial work, and delivery—not just content types on a slide.
Drupal vs Contentful, Sanity, and Storyblok take different paths: integrated application vs managed headless services, core translation and moderation vs SaaS localization, and visual editing vs configurable Drupal workflows. Maciej Lukianski walks through content models, permissions, JSON:API options, AI boundaries, and what growth costs look like on each stack.
read moreOn September 29, Dries Buytaert showed a multilingual food magazine demo in his DrupalCon Rotterdam Driesnote. That was Dashi, the culmination of our work to give Drupal CMS 2.2 standout multilingual features. Here is what it is, how you can try it and how it came to be.
Introduction
Adopting AI can feel overwhelming, so I am sharing a few tales from my experience creating, maintaining, and assisting with contributed Drupal modules. AI can do a decent job building a "greenfield" Drupal module from scratch, so my first tale is about using AI to build and contribute a module. For my next tale, I want to talk about using AI to maintain an existing "brownfield" Drupal module.
Growing up in NYC, I found brownfields often intimidating, with some so toxic that it can take years for backhoes and dump trucks to remove the contaminated topsoil before construction can begin. With code, a brownfield can contain technical debt, orphaned code, missing tests, etc. Simply put, a brownfield contains unknowns, which means more things can go wrong while working on it. Sometimes a brownfield is so big you need heavy machinery to maintain it, and that is exactly how I felt about using AI on the Schema.org Blueprints module.
Maintaining a large module using AI
Gradually, I have been experimenting with AI to help maintain the Schema.org Blueprints. At first, I would just throw a one-shot prompt at the AI to address a single issue, and it would do a decent job diagnosing and resolving the problem. As I became more confident steering the AI, I started asking it to create issue forks, commits, pushes, and even MRs. As I previously stated in my AGENTS.md I always have "Require me to review all changes before committing and pushing code." and most models respect this rule.
My comfort level reached a point where I am creating {module}-issue-maintenance agent skills that extend my drupalorg-issue-maintenance skills. These maintenance skills have agents to track remote issues in...Read More
read more
Just last month, a prospective client came to Joshi Consultancy Services asking for a cheap cron script to fix a runaway disk usage issue. The reality? They were bleeding money on a deep architectural flaw in their Drupal ingestion pipeline. We see this constantly. For years, the enterprise software industry tolerated a quietly expensive habit: carrying technical debt forward.
Historically, major CMS upgrades were treated as little more than UI refreshes. Agencies seamlessly dragged deprecated code, outdated PHP environments, and fragile database structures from one major version to the next. The result? Senior engineers stuck acting as caretakers for legacy code, while CXOs bled budget on endless maintenance retainers just to keep the lights on.
With the December rollout of Drupal 12, that loophole permanently closes.
The platform is fundamentally altering the rules of engagement. Instead of merely suggesting best practices, Drupal 12 enforces strict architectural modernization right at the server level. Here is why this shift is a massive win for both engineering teams and business leadership.
Spaghetti code. We all hate it. But until now, deprecated code could linger in a system for years, propped up by complex workarounds.
Drupal 12 changes this by aggressively stripping out all deprecated core APIs. The system physically rejects structural laziness. If an agency attempts to stack new logic on top of a legacy foundation, the application simply will not run. You build within clean, modern boundaries from day one. Period.
Previously, organizations delayed server upgrades to save short-term costs, forcing modern applications to run on aging environments.
No longer. Drupal 12 introduces non-negotiable infrastructure floors: a PHP 8.5 minimum runtime alongside raised database requirements (MySQL 8.0 / PostgreSQL 18). This isn't just backend housekeeping. By enforcing these modern tiers, the core framework guarantees a baseline of performance that cannot be compromised by budget-saving shortcuts.
Enterprise security is too often treated as an expensive, opt-in audit layer applied long after development is complete.
By making Argon2id the default for password hashing, Drupal 12 integrates military-grade resistance against GPU-driven brute-force attacks directly into the core blueprint. For the C-suite, this is an immediate reduction in liability. Security transitions from an ongoing maintenance headache to a baseline structural guarantee.
The most profound impact lands directly on the balance sheet.
For CXOs, these forced architectural boundaries solve the most expensive problem in enterprise software: unpredictability. When the core framework refuses to execute legacy PHP and automatically enforces top-tier security standards, the financial drain of technical debt is cut off at the source. Organizations can finally stop paying agency retainers to manage bloated, unmaintainable code.
Drupal 12 is not just a feature upgrade. It is a forced modernization of your engineering culture.
If your organization treats this version bump as a standard IT afterthought, you are actively funding your own future liability. Stop paying for temporary bug fixes. Engineer the blueprint first.
Are your servers, and your budgets, ready for the rollout?
The National Center for Family Philanthropy worked with DevCollaborative to reimagine their website, CRM, and other communications channels to effectively manage and scale their network of over 500 philanthropic families representing more than 3,000 individuals.
read moremacOS Docker provider performance has improved significantly over the years, and now all the providers seem to be performing about equivalently. So OrbStack, Docker Desktop, Lima, Colima, and Rancher Desktop are fast and working well.
Back in November 2023 we published a hand-run comparison of macOS Docker providers. It was a snapshot: one laptop, one afternoon, one set of versions, and a Google Sheet. It answered the question people were asking, and then it started going stale the moment it was published.
That post is gone now, and this one replaces it, because the way we answer the question has changed. DDEV now runs the same benchmark battery every night, unattended, on every platform and Docker provider we support, and publishes the accumulated history.
The nightly results live at the DDEV performance history dashboard.
The easiest way to find it (and everything else the DDEV GitHub organization publishes) is to start at github.com/ddev/ddev.github.io and follow the "Performance History" link. That repo's README is the index of DDEV's GitHub Pages sites — bookmark it and you don't have to remember any of the other URLs.
The dashboard has two views. Trend over time plots one line per leg so you can see regressions and improvements as they land. Compare environments (latest) gives you a sorted bar chart of each environment's recent median, which is the view that most directly replaces the 2023 post's charts.
The harness collects six metrics per run. The one that lines up with the 2023 post is drupal_install_s: Puppeteer drives the Drupal web install wizard end-to-end, in a real browser, through the DDEV router, the web server, and PHP-FPM.
I think it's important that it uses a web-intensive install process for studying web server performance. The interactive installer deliberately breaks each batch step into its own HTTP request and page reload, so every one of those round trips exercises exactly the layer where Docker provider differences show up — bind mount vs. Mutagen, gRPC-FUSE vs. virtiofs, and so on. It's the closest thing in the suite to "what does it feel like to actually use this."
The companion metric drush_install_s runs the same install non-interactively via ddev drush si, which never touches the router or web server at all. If the two track together, filesystem I/O dominates; if they diverge, the gap isolates router/web server overhead. The perf/README.md describes all six metrics and why each one is there.
Medians of the nightly runs from 2026-08-31 through 2026-09-30, drupal_install_s in seconds, fastest first. All legs are Apple Silicon (ARM64), all with Mutagen enabled except where noted.
| Docker provider | drupal_install_s |
drush_install_s |
ddev_start_cold_s |
|---|---|---|---|
| Rancher Desktop | 12.0 | 9.8 | 16.5 |
| Lima | 12.1 | 9.9 | 15.8 |
| Podman (rootless) | 12.3 | 9.9 | 46.0 |
| Colima (vz) | 12.6 | 10.0 | 14.4 |
| OrbStack | 13.4 | 10.4 | 12.2 |
| Docker Desktop | 16.7 | 13.4 | 21.0 |
| OrbStack, no Mutagen | 16.8 | 11.2 | 9.2 |
The headline is how boring this table is. Five of the six Mutagen-enabled macOS providers land within 1.4 seconds of each other on the flagship metric, and their drush_install_s numbers are within 0.6 seconds. On macOS with Mutagen, your choice of Docker provider is mostly not a performance decision anymore. Pick based on licensing, maintenance, and how the tool fits your workflow.
That is a significant change from 2023, when OrbStack was clearly ahead and Colima and Rancher Desktop looked sluggish. Those gaps have largely closed (all are now using VZ/VirtioFS).
The 2023 test did a Drupal 10 web install with Mutagen and got OrbStack 20s, Docker Desktop 22s, Rancher Desktop 22s, Colima QEMU 33s, and Colima VZ 35s. The fastest then (OrbStack, 20s) compares with 12.0s for the fastest now (Rancher Desktop), and with 13.4s for OrbStack. The slowest providers gained the most: Rancher Desktop went from 22s to 12.0s and Colima VZ from 35s to 12.6s. The spread between providers went from 15 seconds to about 1.4 (excluding Docker Desktop).
Treat these as a rough comparison, not a like-for-like benchmark. The 2023 numbers came from one MacBook Air M1 (2020) on a single afternoon, with DDEV v1.22.5, Drupal 10.1.6, and PHP 8.1. The nightly runs use CI runner machines, and newer DDEV, Drupal, and PHP versions. Both tests drive the demo_umami install through Puppeteer. Each Docker provider has also shipped many releases since 2023, and the Colima leg now uses VZ where one of the 2023 legs used QEMU with sshfs. Some of the improvement comes from the hardware, and some from the software.
When DDEV was young, a web install with Docker Desktop took SEVEN MINUTES. You'd just watch it poke along at each section. Now you don't even see those as they flash by. Now it takes 12-17 seconds. That's progress!
The most interesting row is the last one. OrbStack with Mutagen finishes the browser install in 13.4s; the same provider without Mutagen takes 16.8s — about 25% slower. Note that the no-Mutagen leg is faster on ddev_start_cold_s (9.2s vs. 12.2s), because there's no sync session to establish, and closer on drush_install_s (11.2s vs. 10.4s), because Drush never goes through the web server. The penalty concentrates in exactly the browser-driven path, which is what you use all day.
Mutagen is on by default on macOS for this reason, and these numbers say to leave it on.
However, plenty of people are perfectly happy with turning off Mutagen. Some folks don't like the additional complexity and don't want the speed trade-off. ddev config global --performance-mode=none turns it off. (Mutagen has more benefits than just performance though; with Mutagen, the web server in the container is dealing with a Linux filesystem, more like the real deployment environment, instead of a Docker bind-mount, which is more like a network filesystem.)
:::warning[Read the hardware caveat before comparing rows] The Docker Desktop leg runs on older M1 test runner machines that have dedicated hardware. OrbStack, Rancher Desktop, Colima, Lima, and Podman share a pool of newer machines. Some of the Docker Desktop gap in the table above is that hardware difference, not the provider. We didn't normalize it — the dashboard deliberately doesn't either — so treat Docker Desktop's row as "somewhat pessimistic" rather than as a clean like-for-like comparison. :::
The dashboard also carries Linux, WSL2, and traditional Windows legs. They're useful for spotting regressions within a leg over time, but the cross-platform bar chart is misleading if you read it as a platform ranking:
Trends within a leg: meaningful. Bar-chart comparisons across legs: only meaningful when the machines are comparable, which across platforms they aren't.
Every chart on the dashboard has a Download CSV button that exports exactly the rows behind whatever is currently displayed — after your leg and metric selections, not the whole dataset. That's the quickest path to your own analysis.
If you want everything, the underlying dataset is one JSON object per line at history.ndjson, with one line per (commit, leg) benchmark run:
curl -sL https://ddev.github.io/ddev/perf/history.ndjson |
jq -r 'select(.os=="darwin") | [.timestamp, .docker_provider, .metrics.drupal_install_s] | @tsv'
The harness that replaced the old ddev-puppeteer script lives in the DDEV repository and runs locally against a standard DDEV Drupal project:
./perf/run-benchmark.sh \
--project-dir ~/workspace/d11 \
--site-url https://d11.ddev.site/ \
> result.json
It needs jq and Node.js on your PATH in addition to the usual DDEV prerequisites. If your numbers look very different from the nightly legs, we'd like to hear about it.
Three years ago the answer to "which Docker provider is fastest on macOS?" was worth a blog post with charts. Today the simple answer is that, with Mutagen on, they're close enough that the question is mostly settled, and any lingering differences are small next to the hardware you're running on.
What's better than a fresh answer is a standing one. The nightly harness means the next time performance shifts — a provider regression, a Mutagen improvement, a DDEV build-layer mistake — it shows up on the dashboard within a day, instead of waiting for somebody to run the numbers by hand and write another post.
Have questions, or numbers that look different from the dashboard? Join the conversation in our Discord, open an issue, or reach out via email.
Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.
This article was edited and refined with assistance from Claude Code.
read moreOne of the difficulty with starting a Drupal website is the lack of diversity in available themes. There has always been more choice in the WordPress world for themes. Maybe, just maybe, Drupal could use WordPress themes and get the best of both worlds?
After Rotterdam, one part of Drupal's AI story is no longer theoretical. The Northmoor University demo brought AI search, content review, translation, editing and externally connected assistants together on the same Drupal site. That made a collection of modules feel closer to a product experience, but it also exposed the next question: whether organisations can depend on the path between those pieces in production.
The stack does not yet sit at one level of maturity. Drupal AI 1.5 and Canvas are stable and covered by Drupal's security advisory policy. Context Control Center is a release candidate, while Tool API and MCP Server remain in beta. Rotterdam showed that these parts can work together. Production teams now have to decide which combinations are mature enough to trust, govern and support.
Permissions, human review and traceability are central to that decision. The demo drafts changes rather than publishing them, leaving a person to review what the AI proposes. Tool API brings access checking into executable capabilities, while MCP can expose Drupal tools to assistants outside the site. Context Control Center moves instructions and organisational knowledge toward managed, reviewed material. Taken together, those pieces point toward a production requirement that goes beyond capability: teams need to know what an agent may read, what it may change, which tools it may invoke, what context it received and who remains accountable for the result.
Provider choice and the connection between Tool API, MCP and Canvas make the remaining maturity gap visible. Drupal's provider abstraction supports different commercial and locally operated models, but workflows still need to remain testable as model behaviour, tool calling and context limits change. The Drupal AI Initiative's follow-up also draws a clear line between what Rotterdam demonstrated and what is available today: the simplified MCP approach shown on stage remains a prototype. Canvas Tools, which lets agents manipulate Canvas through Tool API, is likewise still beta and is not covered by the security advisory policy.
That does not make Drupal AI simply ready or not ready for production. Different parts of the stack already support different kinds of real use, with different levels of risk. Rotterdam instead changes what Drupal AI now has to prove: that permissions remain enforceable, context can be governed, costs and activity can be traced, providers can change without losing control, and interfaces can survive upgrades. Productisation does not mean closing the ecosystem or putting everything inside one package. It means reaching the point where an organisation can understand what an AI system will be allowed to do before deployment, and explain what it actually did afterwards.
Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.
Allen Jason wrote and curated this issue of Editor’s Pick.
read more
Author: Will Huggins
In enterprise digital experience, the conversation around generative AI has shifted dramatically. Digital leaders are no longer asking whether AI can write a paragraph or spin up a page. They are asking:
The release of Drupal AI 1.5 directly answers those questions.
Driven by 63 active contributors across 31 global organisations, Drupal AI 1.5 shifts the platform from one-shot text generation into an interactive, governed, and brand-safe digital experience engine.
For CMOs, Heads of Digital, and website owners, this release is not about backend developer plumbing - it is about practical marketing velocity, measurable ROI, and total brand sovereignty.
Here is a breakdown of what Drupal AI 1.5 unlocks for your digital roadmap.
Early AI chatbots suffered from digital amnesia: the second a visitor navigated to a new page or refreshed their session, their context vanished. For high-consideration purchases or complex self-service portals, this creates friction and frustrates users.
Drupal AI 1.5 introduces persistent, stateful conversation memory:
The Strategic Win: You transform your website from a static brochure into an intelligent, conversational destination that guides prospects smoothly through the conversion funnel.
For any marketing leader, the greatest fear with public-facing AI is reputational damage: a model hallucinating incorrect pricing, generating off-brand language, or leaking sensitive corporate information.
While traditional safety filters only check text after the entire response is completed—slowing down user experiences—Drupal AI 1.5 introduces active streaming guardrails:
The Strategic Win: Complete brand safety. Your legal, compliance, and IT teams get auditable, proactive safeguards built into the core publishing architecture.
Early CMS AI automations were rigid: an editor clicked an AI button, waited, and was forced to accept or discard whatever came back.
Drupal AI 1.5 turns AI Automators into an interactive creative partner inside the editing workspace:
The Strategic Win: High-velocity content operations. AI handles the first 80% of drafting and repetitive formatting, leaving your team with complete creative control over the final 20%.
If visitors cannot find the right product, resource, or service within seconds, they bounce. Traditional on-site search engines rely on exact keyword matches, frequently failing when visitors search using colloquial questions or conversational language.
Drupal AI 1.5 upgrades search into a semantic relevance engine:
One of the fastest ways to lose executive support for AI initiatives is unpredictability—unexpected API bills or black-box operations that IT cannot audit.
Drupal AI 1.5 builds transparency directly into the dashboard:
Proprietary digital experience platforms lock your organization into their single, closed-ecosystem AI model—charging heavy licensing premiums while limiting your flexibility. Lightweight headless tools offer AI writing widgets, but leave you without enterprise governance, multilingual depth, or data sovereignty.
Drupal AI 1.5 delivers the best of both worlds: model-agnostic freedom to choose the best AI for the job, visual campaign acceleration for marketing teams, and bulletproof architectural security.
👉 Download Drupal AI 1.5 today.
Reading about capabilities is one thing; seeing them transform your digital operations is another.
Explore our live interactive environments to test chatbots with memory, stream-level guardrails, and interactive content workflows:
Image: DriesNote, DrupalCon Rotterdam 2026 by Paul Johnson
Author: Jeremy Chinquist
At DrupalCon Rotterdam on September 29, 2026, Dries Buytaert used his keynote to show how far Drupal has come and who it can reach next. Dries framed the keynote around three pillars that bring Drupal's strengths to more people: multilingual (reach people in more languages), JavaScript and headless (bring more developers and applications to Drupal), and AI (give people new ways to work with Drupal).
This post zooms in on the AI pillar. For the full keynote, including digital sovereignty, multilingual, headless and the new Drupal Advocacy Program, read the official recap: DriesNote Rotterdam: Drupal is Light-Years Ahead of Its Reputation. To watch the six demos from the keynote, see Proof, not promises. Watch the six demos from the DriesNote Rotterdam.
Watch the full keynote on YouTube
Exclusive interview: James Hall sat down with Dries Buytaert for the Drupal AI Initiative. Watch it on LinkedIn
Image: James Hall, Everyone TV interviews Dries Buytaert following the DriesNote
Dominique De Cooman, Head of Partnerships for the Drupal AI Initiative, opened the conference with a short welcome and a clear message: the Drupal AI Initiative is strong and active. Dries later mentioned that over 100 people have contributed to the Drupal AI Initiative so far.
On stage, Dries showed off the demo that the Inside AI team, led by Christoph Breidert, had been developing over the past few months. "Drupal AI Demo: Northmoor University" is a complete university website that shows Drupal AI at work on realistic content. Anyone can try it today at drupal.org/ai/demo. To learn how the demo was built and what it can do, read Christoph's announcement: Introducing the Drupal AI Demo.
Five parts of the demo were highlighted during the talk:
Did you know?
Aidan Foster also used the demo site in the presentation "Encoding Expertise: How UX Research Powers Human-First AI" to show how AI guidelines can help review a site's content.
Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)
What this means for you: for agencies and site owners, this is the quickest way to see Drupal AI on a real site before planning a project. The guardrails matter as much as the features: the AI flags, drafts and cites, and people decide what gets published.
Dries showed AI-assisted development for Drupal Canvas. Given a prompt such as "Build a content template for my articles," the AI assistant checks its work against Canvas Workbench, ESLint and the Canvas CLI. The result is a set of simple template files, pushed to the site with the Canvas CLI.
What this means for you: front-end developers can let an AI assistant write the first draft while Canvas' own tooling validates the result.
Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)
Today, exposing a Drupal module's features to AI assistants via MCP takes around 1,000 lines of code. Dries showed a prototype that brings this down to around 20 PHP attributes, using a recipe that combines the Simple OAuth, MCP Server and Tool API modules. The principle is "describe once, use in multiple places": one description of a capability serves AI assistants, workflow tools and JavaScript components alike.
In the demo, a FindImages tool lets an AI assistant look up images on the site, with FlowDrop connecting the pieces.
What this means for you: this is a prototype, not a release. For module maintainers, it points to a future where one description makes a module usable by AI assistants.
Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)
The next step is the Rosetta Sprint: a four-day sprint with key maintainers to describe Drupal's capabilities once, in a form that AI agents, other systems and humans can all read. The goal is to make Drupal's data and capabilities easier to expose to AI agents, orchestration tools, frontends and more. The date and location are still to be announced.
Did you know?
Kristen Pol used the Drupal AI Demo to record the demo clips for her session "Context Control Center: Bringing AI Context to Drupal CMS." Curious how Drupal gives AI the right context? Take a look.
Dries closed with a clear request: "Here is my ask: Talk louder about Drupal." Try the demo, share what you build with Drupal AI and join the Drupal Advocacy Program.
Image: Karl Hepworth (DriesNote, DrupalCon Rotterdam 2026)
During the keynote, Dries thanked the Drupal AI Partners, the organizations that back the Drupal AI Initiative. Want your organization to join them? Become a partner.
Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)
Author: Christoph Breidert, Product Lead, Drupal AI
Earlier this year, the Drupal AI Initiative set itself a clear goal: at DrupalCon Rotterdam, show one Drupal site where AI search, content review, chat-driven editing, and AI translation all work together on real content. Today we are delivering on that promise. The Drupal AI Demo is live, and Dries revealed it in the Driesnote.
You can open it, use it, and see for yourself what Drupal AI looks like when it is built as a complete product. The demo is the website of a fictional university, with the kind of content and structure a real organization's site would have.
The Drupal AI Demo: a realistic, multilingual university website where every AI feature runs on the same content
Until now, Drupal AI has mostly been something we described. We had roadmaps, feature lists, module pages, and conference talks. All of that was accurate, but none of it was tangible. A list of features asks people to imagine how the pieces fit together. A demo lets them see it.
That difference matters to two groups of people in particular.
If you are evaluating Drupal, the demo lets you test the AI features instead of reading about them. I believe Drupal is the most powerful AI-powered CMS available today. Until now, that was a claim you had to take on trust. Now you can check it yourself, try the features on realistic content, and plan your own website around capabilities that are already implemented and working.
If you already build with Drupal AI, the demo shows how each feature is intended to be used. You can evaluate every feature, see how it is configured, and adapt that setup to your own use case. That is a much better starting point than piecing together a feature from documentation alone.
The demo focuses on the features our Drupal AI Partners told us matter most. In May, we asked them which capabilities they most wanted to have ready to use in Drupal. They are at the heart of the demo.
AI content reviews. Check a page against criteria like brand voice, legal requirements, and reading level, and get concrete suggestions for improving it.
AI content review scores a page against brand, legal, and readability criteria and suggests concrete improvements
AI search. Ask a question and get an AI-generated answer, grounded in the site's own content and with the sources behind it.
AI search answers a question with a summary, the sources behind it, and ranked results from the site's own content
Chat-driven content editing. Describe what you want to change, and the AI edits the page for you, right inside the editing experience.
Chat-driven editing: an editor describes a change in the chat, and the AI updates the page directly
AI translation. Move content across languages, with results good enough to publish.
AI translation moves a page into another language, ready for review and publishing
Connect your own AI agents. Connect agents such as Claude, ChatGPT, and others to Drupal through MCP, and make changes to the website from the outside.
An external AI agent, connected through MCP, making a change on the demo website
What makes the demo different from trying these features one at a time is that they all run together on the same site and the same content. That is what building a real website involves, and it is where the hardest work was.
The idea of a demo was always there. We knew from the start that Drupal AI would need one, but first we needed a foundation strong enough to build it on.
The official Drupal AI sprints started in January this year. We spent the first three months refining the core AI functionality. By the second quarter, we had a stable code base to build on. In May, we ran the partner survey, and that was the moment the demo became a shared goal. The partners bought into the idea, and together we agreed on the features it should show. June went into preparation. In July, we started building.
The last eight weeks were the most intense. Between 1 August and 26 September alone:
Activity grew steadily over those weeks, from about 70 commits in the first week of August to more than 300 per week in September. And the part I am most proud of is not the size of those numbers. It is that the result simply works.
Weekly commits across the demo and the drupal.org projects it builds on, 1 August to 26 September 2026
The demo was built by contributors from across the Drupal AI Partners, the organizations that fund and staff this initiative, together with many contributors from the wider Drupal community. Working together, we could build a more advanced AI experience than any of us could have built alone, and everything we build for the demo makes Drupal AI better for everyone who uses it.
Most of the load of the demo itself was carried by four people: Marcus Johansson, Artem Dmitriiev, Aidan Foster, and myself. Marcus, Artem, and I also met in person for three days to do nothing but sprint on the demo. Some of the hardest problems got solved in that room.
Marcus Johansson, Artem Dmitriiev, and Christoph Breidert during their three-day, in-person demo sprint
Many others did substantial work on the demo itself. I want to thank Darren Oh, Kristen Pol, Abhisek Mazumdar, Dan Lemon, Eric Homanchuk, Akhil Babu, and Kiran Kadam.
Of course, a demo is only as good as the modules underneath it, and many projects were heavily developed to be ready for Rotterdam. The main contributors there include Giorgio Alfredo Pagano on AI Disclosure, Michael Lander and Matt Glaman on the Tool API, MCP Server, and Canvas tools, Kristen Pol on AI Context, Rob Loach, Scott Euser on AI Search, Ahmad Khader on AI Content Review, and Sven Decabooter on AI Translate. Much of this work also depended on review: Artem and Marcus alone merged more than 100 merge requests from other contributors in these two months.
Coordinating a distributed effort of this size, with contributors across many organizations, countries, and time zones, in such a short time is its own kind of challenge. My role was to set the direction, define the work packages, and align with key contributors and organizers to make sure we were building the right things. I also reviewed a great deal of work along the way. The day-to-day operations were led by our delivery managers, Arian Raeesi and Vidit Anjaria, who planned the work into sprints and kept it moving every day.
What I had never seen before is so many people building something together that actually works as one. Being part of that is amazing.
The demo was something I had in my head for a long time. Seeing so many people take that idea and make it real, and seeing it work, is one of the most rewarding experiences I have had in the Drupal community.
To everyone who contributed: thank you. This demo is yours.
The demo is live at drupal.org/ai/demo. Try it, test it, and tell us what you think.
If you want to help shape what comes next, join us in the #ai-initiative channel on Drupal Slack, or explore becoming a Drupal AI Partner.
Abhinav Jha, Abhisek Mazumdar, Abhishek Dhariwal, Adam G-H, Adrian McKee, Ahmad Khader, Ahmad Khalil, Aidan Foster, Akhil Babu, Alex Urevick-Ackelsberg, Andrei Mateescu, Andrii Sakhaniuk, Angela Saldaña, Anikó Viola, Ann Mary Sruthy, arne michiels, Artem Dmitriiev, Ashish Dalvi, attilatilman, Avinash jha, Bharat Kelotra, Brooke Mahoney, Bruna Emerich, Bruno Bruno, calmforce, Carlos Romero, Cesar Miquel, Chad Peppers, Christian Burk, Christoph Breidert, Craig Wood, Dan Goodwin, Dan Lemon, Daniel Rodriguez, Darren Oh, Dave Long, David Bravo, Denise Spangler, Dezső Biczó, Dimitris Spachos, Dries Buytaert, Emma Horrell, Eric Homanchuk, George Kastanis, Giorgio Alfredo Pagano, Ignacio Pérez Puertas, István Csáki, Jeff Warrington, Jeremy Cerda, Jibran Ijaz, Joonas Meriläinen, Jordan Graham, JoshHayter, Joshua Fernandes, Juan Correa, Jurriaan Roelofs, Jérôme Tchania, Jürgen Haas, Kenneth Bolívar Castro, Kieran Cott, Kiran Kadam, KJ Monahan, Konstantine Kirkitadze, Kristen Pol, Lee Rowlands, Levente Besenyei, Manuel Garcia, Marcus Johansson, Markus Kalkbrenner, Mateu Aguiló Bosch, Matt Glaman, Matthew Tift, Michael Lander, Miguel Guerreiro, Narendra Singh Rathore, Nick Opris, Nick Pasiuk, Nik LePage, Norman Kämper-Leymann, Pieter Frenssen, Prabhavathi Vanipenta, Pravesh Poonia, Punam Aseem Beedkar, Reinhold Schachner, Ricardo Castañeda, Richard Porter, Rob Loach, Rodel Duterte, scontzen, Scott Euser, Scott Falconer, Sergiu Nagailic, Shashank Rai, Shibin Das, Shivam Sen, Simon Morvan, Sven Decabooter, szato, Tamas Balog, Tekla Aivazashvili, Tormi Tabor, tribekk, Valery Lourie, Will Huggins, Wolfgang Ziegler.
The DriesNote at DrupalCon Rotterdam made one argument above all: Drupal is light-years ahead of its reputation. The strongest evidence was on screen. These six demos show a platform that speaks more languages, welcomes JavaScript developers as first-class citizens, and treats AI assistants as another interface to Drupal, with governance built in.
Everything here is open source and available today. Here are the demos, with the story behind each one.
80% of the world doesn't speak English as a first or second language, so multilingual is how Drupal reaches billions more people. Two things used to hold teams back: setup was hard, and Drupal Canvas didn't yet support multilingual content. Drupal CMS 2.2 changes both, with a language selector right in the installer, a guided Multilingual add-on, three levels of translation configurability, and full translation support in Canvas, including review workflows and optional AI translation. Watch for Dashi, a multilingual food magazine template made entirely by Drupalers.
JavaScript front ends are where many developers start their careers, and Canvas is built for them: a standalone front-end project scaffolded in one command, with React, TypeScript, and Tailwind CSS, previews via Canvas Workbench with zero configuration, and AI coding agents in the workflow. One push with the Canvas CLI and everything is ready for content teams to use visually. No Drupalisms, no trade-offs.
Organisations often compose experiences from multiple backends, and that calls for a headless front end. Canvas Headless connects yours by configuring a URL, with Canvas visual editing built in: editors see a live preview of the real application while developers build in the framework they prefer. Starter templates cover Next.js, Astro, Nuxt, and TanStack Start, and Angular support arrived the very week of the keynote, five frameworks in all.
There's been so much Drupal AI work that demoing it all would fill the keynote. Instead, there's now a demo experience anyone can try: a fictional university site where AI reviews every page against your standards, visitors get answers drawn from your own content with sources shown, and guardrails, a central knowledge hub, and full logging keep it accountable. It's working today, open source, built by leading Drupal AI companies, and pre-configured so you can also use it to show customers. Try it at drupal.org/ai/demo.
A content editor spots Dutch translations showing prices that shouldn't be live yet. From ChatGPT, connected with her own account, she asks for the previous Dutch versions back, English untouched. It happens, with every change recorded as a new revision under her name. She didn't need to know where to click or how revisions, moderation, and permissions work; Drupal handled the governance behind the scenes. You can do this today with a recipe combining Simple OAuth, MCP Server, and the Tool module, built by Michael Lander, Matt Glaman, and others: drupal.org/project/agent_access
The most surprising demo wasn't about AI at all. Dries's personal site holds more than 10,000 photos in a custom album module he tool-enabled himself, the work behind his "describe once, use everywhere" idea. The creator of FlowDrop, a visual workflow tool for Drupal, showed that module's MCP server powering a plain form, searching photos and albums with no AI anywhere, and then an agent that chooses its own tools to answer questions. When capabilities are described once and answers come back structured, AI becomes a choice, not a requirement. That idea is what the upcoming Rosetta Sprint will take forward.
Watch the DriesNote in full, or read the full recap of everything Dries announced, from digital sovereignty to the Drupal Advocacy Program.
The DriesNote at DrupalCon Rotterdam made one argument above all: Drupal is light-years ahead of its reputation. The strongest evidence was on screen. These six demos show a platform that speaks more languages, welcomes JavaScript developers as first-class citizens, and treats AI assistants as another interface to Drupal, with governance built in.
Everything here is open source and available today. Here are the demos, with the story behind each one.
80% of the world doesn't speak English as a first or second language, so multilingual is how Drupal reaches billions more people. Two things used to hold teams back: setup was hard, and Drupal Canvas didn't yet support multilingual content. Drupal CMS 2.2 changes both, with a language selector right in the installer, a guided Multilingual add-on, three levels of translation configurability, and full translation support in Canvas, including review workflows and optional AI translation. Watch for Dashi, a multilingual food magazine template made entirely by Drupalers.
JavaScript front ends are where many developers start their careers, and Canvas is built for them: a standalone front-end project scaffolded in one command, with React, TypeScript, and Tailwind CSS, previews via Canvas Workbench with zero configuration, and AI coding agents in the workflow. One push with the Canvas CLI and everything is ready for content teams to use visually. No Drupalisms, no trade-offs.
Organisations often compose experiences from multiple backends, and that calls for a headless front end. Canvas Headless connects yours by configuring a URL, with Canvas visual editing built in: editors see a live preview of the real application while developers build in the framework they prefer. Starter templates cover Next.js, Astro, Nuxt, and TanStack Start, and Angular support arrived the very week of the keynote, five frameworks in all.
There's been so much Drupal AI work that demoing it all would fill the keynote. Instead, there's now a demo experience anyone can try: a fictional university site where AI reviews every page against your standards, visitors get answers drawn from your own content with sources shown, and guardrails, a central knowledge hub, and full logging keep it accountable. It's working today, open source, built by leading Drupal AI companies, and pre-configured so you can also use it to show customers. Try it at drupal.org/ai/demo.
A content editor spots Dutch translations showing prices that shouldn't be live yet. From ChatGPT, connected with her own account, she asks for the previous Dutch versions back, English untouched. It happens, with every change recorded as a new revision under her name. She didn't need to know where to click or how revisions, moderation, and permissions work; Drupal handled the governance behind the scenes. You can do this today with a recipe combining Simple OAuth, MCP Server, and the Tool module, built by Michael Lander, Matt Glaman, and others: drupal.org/project/agent_access
The most surprising demo wasn't about AI at all. Dries's personal site holds more than 10,000 photos in a custom album module he tool-enabled himself, the work behind his "describe once, use everywhere" idea. The creator of FlowDrop, a visual workflow tool for Drupal, showed that module's MCP server powering a plain form, searching photos and albums with no AI anywhere, and then an agent that chooses its own tools to answer questions. When capabilities are described once and answers come back structured, AI becomes a choice, not a requirement. That idea is what the upcoming Rosetta Sprint will take forward.
Watch the DriesNote in full, or read the full recap of everything Dries announced, from digital sovereignty to the Drupal Advocacy Program.
Drupal is now light-years ahead of its reputation. It's time we changed that.
The Drupal Advocacy Program is a new Drupal Association pilot that awards contribution credit for work that helps people discover and understand Drupal.
Drupal is light-years ahead of its reputation. The platform has changed dramatically in recent years, but the market's picture of Drupal runs years behind. If you have ever heard "oh, is Drupal still around?", you have felt that gap first-hand — and research by major Drupal agencies confirms it. The fix is not a bigger ad budget. It is education at community scale: authentic stories from the people who build with Drupal, told in their own voices to the audiences they know best.
Our community can be uneasy with the word "marketing". But you are already advocates for Drupal, day in and day out — and that is exactly what this moment needs. If you have ever written a tutorial, recorded a demo, translated an article, or shared someone else's talk with a new audience, you have been doing advocacy. Starting today, that work earns recognition.
Tell the story. Create, share, and boost content about modern Drupal. A blog post for your market. A video for your audience. A talk at a non-Drupal conference. A customer story in your language. And amplification counts: share someone else's DrupalCon talk or case study, tell us about it, and you earn credit too.
Themes multiply your impact. Four to six times a year, we will roll out a theme — a consistent message with messaging and proof points ready to build on. Take it and make it your own: translate it for your language, reframe it for your industry, make it relevant to your network. Advocacy content on the current theme earns 2x–3x credits, because 126 certified partners and a huge global community telling one story at the same moment is what moves the market.
Credits flow back. Advocacy runs through the same contribution credit system that recognises code. It counts toward your standing in the ecosystem, including Drupal Certified Partner visibility. Credits will be awarded in bulk each month, guided by a published scale (to come), weighted by quality and reach, because we want content that travels beyond the Drupal world. Each month we will also spotlight the best advocacy content and award it extra credit.
The ground rules are simple. This is about promoting Drupal and what Drupal can do. You can mention where you work, and you can absolutely draw on case studies from your own business — as a way of showing what Drupal makes possible.
Choose something that fits you. You do not need to become a salesperson. As Dries put it in his DrupalCon Rotterdam keynote: Drupal doesn't need hype. It needs a better public record.
For now, it is a short form at drupal.org/advocacy. In the coming days you will also find a submission form across many Drupal Slack channels. Either way, telling us about your content should take a minute — because for this to work, submitting needs to be exceedingly easy.
This is very much a pilot. We will start by reviewing and crediting submissions by hand, look for ways to automate over time, and let what we learn from your submissions shape how the program grows. And we want to celebrate the people who lead the way: at next year's DrupalCons, we will present awards to Drupal's biggest advocates.
Every story you tell adds to Drupal's public record — the record that search engines, AI assistants, and agentic search increasingly draw on when people ask what to build with. More authentic voices means Drupal showing up where decisions are actually made.
Submit your advocacy work at drupal.org/advocacy. You will find the current theme, its messaging and proof points, and guidelines on attribution and what qualifies for credit.
You have done the work. Now start talking.
Drupal is now light-years ahead of its reputation. It's time we changed that.
The Drupal Advocacy Program is a new Drupal Association pilot that awards contribution credit for work that helps people discover and understand Drupal.
Drupal is light-years ahead of its reputation. The platform has changed dramatically in recent years, but the market's picture of Drupal runs years behind. If you have ever heard "oh, is Drupal still around?", you have felt that gap first-hand — and research by major Drupal agencies confirms it. The fix is not a bigger ad budget. It is education at community scale: authentic stories from the people who build with Drupal, told in their own voices to the audiences they know best.
Our community can be uneasy with the word "marketing". But you are already advocates for Drupal, day in and day out — and that is exactly what this moment needs. If you have ever written a tutorial, recorded a demo, translated an article, or shared someone else's talk with a new audience, you have been doing advocacy. Starting today, that work earns recognition.
Tell the story. Create, share, and boost content about modern Drupal. A blog post for your market. A video for your audience. A talk at a non-Drupal conference. A customer story in your language. And amplification counts: share someone else's DrupalCon talk or case study, tell us about it, and you earn credit too.
Themes multiply your impact. Four to six times a year, we will roll out a theme — a consistent message with messaging and proof points ready to build on. Take it and make it your own: translate it for your language, reframe it for your industry, make it relevant to your network. Advocacy content on the current theme earns 2x–3x credits, because 126 certified partners and a huge global community telling one story at the same moment is what moves the market.
Credits flow back. Advocacy runs through the same contribution credit system that recognises code. It counts toward your standing in the ecosystem, including Drupal Certified Partner visibility. Credits will be awarded in bulk each month, guided by a published scale (to come), weighted by quality and reach, because we want content that travels beyond the Drupal world. Each month we will also spotlight the best advocacy content and award it extra credit.
The ground rules are simple. This is about promoting Drupal and what Drupal can do. You can mention where you work, and you can absolutely draw on case studies from your own business — as a way of showing what Drupal makes possible.
Choose something that fits you. You do not need to become a salesperson. As Dries put it in his DrupalCon Rotterdam keynote: Drupal doesn't need hype. It needs a better public record.
For now, it is a short form at drupal.org/advocacy. In the coming days you will also find a submission form across many Drupal Slack channels. Either way, telling us about your content should take a minute — because for this to work, submitting needs to be exceedingly easy.
This is very much a pilot. We will start by reviewing and crediting submissions by hand, look for ways to automate over time, and let what we learn from your submissions shape how the program grows. And we want to celebrate the people who lead the way: at next year's DrupalCons, we will present awards to Drupal's biggest advocates.
Every story you tell adds to Drupal's public record — the record that search engines, AI assistants, and agentic search increasingly draw on when people ask what to build with. More authentic voices means Drupal showing up where decisions are actually made.
Submit your advocacy work at drupal.org/advocacy. You will find the current theme, its messaging and proof points, and guidelines on attribution and what qualifies for credit.
You have done the work. Now start talking.
The Women in Drupal Awards returned this year to celebrate the outstanding achievements of women making remarkable contributions to the global Drupal community. Presented during DrupalCon Rotterdam 2026, the awards recognize women whose talent, leadership, creativity, and commitment are helping strengthen the Drupal community and shape the future of open source.
Photo Credits: Dan Lemon
Now in its fifth year, the Women in Drupal Awards continue their mission of amplifying women’s voices and recognizing the many different ways they contribute to technology and the Drupal ecosystem. From technical expertise and project leadership to community building, mentoring, advocacy, and innovation, the awards celebrate women whose work creates meaningful impact across projects, organizations, and communities.
This year, the Women in Drupal Awards recognize three outstanding nominees across three distinct categories:
Together, the three nominees represent the breadth of contributions that make the Drupal ecosystem stronger: from leading projects and showcasing success stories, to developing technology, supporting regional communities, mentoring others, and fostering collaboration.
Photo Credits: Joris Vercammen
The Women in Drupal Awards were created to ensure that women’s stories and successes in technology are visible and celebrated. The awards recognize contributions in many forms, whether through building Drupal projects, leading teams and organizations, designing digital experiences, driving innovation and strategy, mentoring others, strengthening the community, advocating for inclusion, or championing open source and collaboration.
A key contributor to this year’s awards is JAKALA, the official sponsor of the Women in Drupal Awards. JAKALA created the award and has supported the initiative since its inception, helping ensure that the achievements and contributions of women across the global Drupal community are recognized and celebrated. As the awards enter their fifth year, JAKALA continues to support their mission of highlighting diverse talent, leadership, and impact within the Drupal ecosystem.
The ceremony has become a highlight of DrupalCon. Beyond the awards themselves, the wider Women in Drupal initiative fosters mentorship, networking, recognition, and greater visibility for women working in Drupal and open source. This year, the initiative also includes a dedicated Women in Drupal networking lunch, organized in collaboration with JAKALA, providing an opportunity for women and gender-diverse members of the community to connect, share experiences, and build relationships.
The Women in Drupal Awards are supported by the Drupal Association and organizations across the industry. The 2026 jury brings together members of the Drupal Association, previous award winners, and JAKALA, combining perspectives from across the Drupal community to recognize this year's outstanding contributors.
Women in Drupal is a community-driven initiative dedicated to celebrating, supporting, and empowering women in the Drupal ecosystem. Through recognition, networking, mentorship, and community events, the initiative fosters inclusion and encourages greater participation and leadership in open source.
The Women in Drupal Awards recognize women from across the Drupal community, regardless of role or area of expertise, celebrating the talent, leadership, creativity, and commitment that help strengthen Drupal and shape its future.
