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.
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.
[IMAGE 8: sprint photo]
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 official Drupal AI Demo is live. Explore how Drupal AI features work together in one real-world demo!
read moreThe 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.
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.
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.
How Tag1 Reviews Code with AI covered the tools Tag1 built to put AI into the PR review process. This post shows the pattern: AI drafts your whole review into GitHub pending reviews or GitLab draft notes, and you decide, line by line, what gets published under your name.
AI is good at the unglamorous parts of review: actually reading every line of a large diff, knowing the obscure API pitfalls no single reviewer carries in their head, checking the change against the rest of the codebase for consistency, and asking every "what if this input is empty" question without getting bored. What it can't tell you is which of its twenty comments actually matter.
There are two ways to put that to work, and they're not in competition. The first is the one most people have seen: a bot that reads the pull request and posts its review straight to it. That's a good fit for CI and merge gating. Tag1's own ai-pr-review runs on every push, combining deterministic scanners with AI reviewers, and can gate merges on what it finds: a leaked credential, a known CVE, a phpstan error, or a logic bug an agent caught.
The second way is quieter, and easy to overlook. Both GitHub and GitLab have a staging layer for reviews: comments you write that nobody else can see until you press submit. GitHub calls it a pending review; GitLab calls them draft notes ("Start a review"). Point your AI at that layer instead of at the publish button and you get the machine's thoroughness with a person still accountable for every published word. That's what this post is about, and it's what you want when the review goes out under your name, especially when you're the gate a client is paying to stand between their code and their production site. There, the reviewer of record should be someone who read the change and chose to sign it.
The workflow has four steps:
When you comment via "Start a review" in the Files changed tab, GitHub holds the comments in a pending review — they're "pending and only visible to you," per GitHub's docs, until you submit as Comment, Approve, or Request changes. The same states exist in the REST API: create a review without an event and it lands in PENDING; a second call to .../reviews/{review_id}/events submits it; DELETE abandons it. Each user gets one pending review per PR. GitHub doesn't seem to document this anywhere, but the API enforces it with a 422 error: "User can only have one pending review per pull request."
The detail that matters is that if the AI authenticates with your token, the pending review it creates is yours. It shows up in your browser as your own draft, fully editable.
One approach for integrating AI into human-owned reviews is the official GitHub MCP server, which wraps everything in purpose-built tools. One command connects it to Claude Code (create a Personal Access Token (PAT) with repo scope first):
claude mcp add --transport http github https://api.githubcopilot.com/mcp \
-H "Authorization: Bearer YOUR_GITHUB_PAT"
This exposes the purpose-built tools: pull_request_review_write to create, submit, or delete a review, and add_comment_to_pending_review to add inline comments to your latest pending review. Then, prompt with something like:
Review PR #123 in tag1/example. Read the full diff. Start a pending review and add inline comments only for real problems: correctness, security, performance. Prefix each with Critical/Minor/Nit. Do NOT submit the review; I'll edit and submit it myself.
Because the agent runs as you, a second round works too: "I've edited the pending review. Read it back, tell me what I misjudged, and add pending comments for anything I missed."
The gh CLI is the more dependable approach. There's currently no native pending-review command for gh pr (no gh pr review --draft), but gh api can do it in a single call with nothing extra to install, and when Claude Code prompts you to approve the call it shows the full comment text in a readable form which the MCP doesn't.
# Create a pending review with inline comments (no "event" = stays pending)
gh api repos/tag1/example/pulls/123/reviews --input - <<'EOF'
{
"body": "First pass by Claude; edited by Jeremy.",
"comments": [
{ "path": "src/Form/SettingsForm.php", "line": 87, "side": "RIGHT",
"body": "Critical: user input is concatenated into the query; use a placeholder." }
]
}
EOF
You then edit and submit in the web UI. The one thing gh api can't do is append comments to a review you've already started: the REST endpoint only accepts comments at creation time, and the append path needs GraphQL, as discussed in the GitHub community. That's the case where the MCP server has an advantage, since it does the GraphQL for you.
For those of us in the Drupal ecosystem, most contribution happens through GitLab merge requests on git.drupalcode.org. Fortunately this uses the same pattern, but with different names.
In the UI, Start a review / Add to review keeps comments unpublished and visible only to you until you submit (with Approve, Comment, or Request changes). This is a Free-tier feature, so it works on any GitLab deployment.
The GitLap API calls them draft notes. To use them, you first need to point glab at the right instance (create a personal access token with api scope in your GitLab profile settings). Swap git.drupalcode.org for your own GitLab host (gitlab.com or your self-managed instance).
glab auth login --hostname git.drupalcode.org
Inline comments need diff SHAs, which come from the merge request itself. Run these inside your clone of the project:
# Get the SHAs the position object needs
glab api projects/:id/merge_requests/42 | jq .diff_refs
# AI (or you) stages an inline comment; nobody else sees it
glab api projects/:id/merge_requests/42/draft_notes --input - <<'EOF'
{
"note": "Minor: this hook is missing a cache tag for the config entity.",
"position": {
"position_type": "text",
"new_path": "src/EventSubscriber/CacheSubscriber.php",
"new_line": 54,
"base_sha": "<diff_refs.base_sha>",
"head_sha": "<diff_refs.head_sha>",
"start_sha": "<diff_refs.start_sha>"
}
}
EOF
# Later, YOU publish, or just click "Submit review" in the UI
glab api -X POST projects/:id/merge_requests/42/draft_notes/bulk_publish
GitLab's official MCP server (beta, Premium/Ultimate) can read MR diffs and pipelines but doesn't expose draft notes yet, per its tool list, so on GitLab the dependable recipe is to let the agent read the MR however it likes, but have it stage comments through glab api .../draft_notes. Drop the commands above into your project's CLAUDE.md and Claude Code handles the SHAs and line positions itself.
Two simple rules guide the workflow. First, tell the AI explicitly, every time, that it must never submit, approve, or publish anything; staging comments is its entire job. Second, run it with your own credentials, because draft comments are only editable by their author, and the author should be you.
The AI delivers the efficiency: it reads every line of the diff in minutes and never gets bored or distracted. You deliver the quality: your judgment decides what's real, what matters, and how to say it to a colleague, and the AI's optional second pass over your edits catches what you missed. Because nobody else sees the pull request until you've read it, shaped it, and chosen to sign it, you stay in control of the review from first comment to submit button. You're not choosing between doing reviews faster and doing them well. Done this way, AI helps you achieve both.
read moreA recent post on Bluesky asked a common question: with dozens of DDEV projects, what is the fastest way to get to one? The current routine was to open Finder, dig three folders deep, drag the folder into an editor, and then run ddev start. Another post mentioned 52 projects and no idea which ones are running. Here are the techniques we use and that came up in the replies.
ddev listddev list shows every project DDEV knows about, with its status, location, URL, and type. The underlined locations and URLs are terminal hyperlinks you can click.
To see only the projects that are running, use ddev list --active-only (or ddev list -A). ddev poweroff stops every running project at once.
Hold Cmd (macOS) or Ctrl (Linux and Windows) and click a link. A location opens in your file manager, and a URL opens in your browser.
DDEV adds links only in terminals it recognizes, including iTerm2, Ghostty, WezTerm, Kitty, Alacritty, Windows Terminal, VS Code's integrated terminal, GNOME Terminal, and Konsole. The macOS Terminal app doesn't support them, so on a Mac, iTerm2 is a good choice if you want clickable links or even if you just want to live a long and happy life.
If nothing is underlined:
export FORCE_HYPERLINK=1 to your shell startup file to turn links on anyway.ddevRunning ddev or ddev tui with no arguments opens an interactive terminal dashboard that lists all of your projects and their status. You can start, stop, and restart projects, open a project's URL or Mailpit in the browser, and press Enter for a project's details. For someone with 52 projects, this may be the quickest way to see what is running.
With many projects, the most useful key is /, which filters the list as you type. The filter matches part of a project's name, type, status, or directory, ignoring case, so dr finds every Drupal project, running shows only running projects, and client finds every project under a client directory. Move to the project you want, and start it with s or open it with l. See the interactive dashboard documentation for the full list of keys.
ddevcd: Built-In Project JumpDDEV ships a shell function that changes to a project's root directory by name:
ddevcd some-project
It needs a one-time addition to your shell startup file. ddev utility cd prints the exact line for Bash, Zsh, or fish. See the utility cd documentation.
ddevcd works from any directory, and it has tab completion for project names like the rest of DDEV. Typing ddevcd pr<tab> completes to something like ddevcd pr8859-test.
autojump learns the directories you visit and lets you jump to them with j and part of the name. It works for any directory, not only DDEV projects.
brew install autojump # Or `sudo apt install autojump`, etc
# Follow the post-install instructions to source it from your shell rc file
j myproject
ddev start
If you only need to start a project, you don't have to change directories at all: ddev start <projectname> works from anywhere.
Note that autojump only knows directories you have already visited (unlike ddevcd, which knows every project DDEV has seen).
code . or phpstorm .: Open the Editor From the Project DirectoryOnce you are in the project directory, open it in your editor from the terminal.
For VS Code:
code .
For PhpStorm:
phpstorm .
Each command opens the current directory as the project, and reuses the window if that project is already open.
The commands have to be installed first:
open -a PhpStorm . also works without a launcher script.Other editors follow the same pattern, for example cursor . for Cursor.
Put it all together to get from anywhere to a running project in your editor:
ddevcd myproject && ddev start && code .
ddevcd myproject && ddev start && phpstorm .
ddev describeddev describe has a short alias, ddev st, which is easy to type and worth adopting. It prints the project's details, including the project's location on disk.
The project location (~/workspace/ddev.com in the header above) is a clickable link that opens your file manager at the project root.
ddev list -j and jqddev list -j prints the project list as JSON, and jq can answer more specific questions. The project data is under .raw. Each entry has fields including name, approot, status, type, and primary_url.
Running projects and their directories:
ddev list -j | jq -r '.raw[]
| select(.status=="running")
| "\(.name)\t\(.approot)"'
Names of all Drupal 11 projects:
ddev list -j | jq -r '.raw[]
| select(.type=="drupal11")
| .name'
The directory of one project, which you can use with cd or code:
code "$(ddev list -j | jq -r '.raw[]
| select(.name=="myproject")
| .approot')"
If you would rather click than type, the community has built several graphical front ends for DDEV. They sit on top of the DDEV command line, so your projects and .ddev configuration stay the same. The DDEV project doesn't maintain or endorse any of these, and this list comes from our newsletters and from reports by their authors. Try them and judge for yourself.
Didn't find yours? The June 2026 newsletter covers some of these tools as well. If you built a DDEV GUI, send a PR adding it here.
We know this is awkward territory, and we're always listening to you, and want to know what we can do to make it better.
Your suggestions to improve this blog are welcome. If you have a technique for getting around your projects that isn't here, you can do a PR to this blog adding it. Info and a training session on how to do a PR to anything in ddev.com is at DDEV Website For Contributors.
Follow the DDEV Newsletter for information about upcoming user and contributor training sessions.
read moreLaunching a website is a major milestone, but it does not mark the end of the investment.
Drupal, WordPress, and Backdrop are actively maintained software platforms. Core software changes. Modules and plugins release updates. Security vulnerabilities are discovered. PHP and other underlying technologies move through their own support cycles.
During a long website build, teams should be paying attention to those changes and applying updates when they make sense within the project cadence. That does not necessarily require a dedicated line item for updates. It does require recognizing that the software will continue to change while the site is being built.
The more important planning conversation is what happens after launch. Post-launch budgets often focus on new features, enhancements, and fixes specific to the site. Routine platform maintenance has to be planned alongside that work, or it is easy to defer indefinitely.
Different content management systems handle releases differently.
Drupal has a well-defined release cycle, including regular windows for bug fixes and security releases. Backdrop similarly publishes scheduled minor releases and security release windows.
WordPress is less predictable. Core releases do not follow the same kind of monthly schedule, while plugins and themes are updated independently by their maintainers. For WordPress sites, that makes proactive monitoring particularly important. Checking for updates weekly or bi-weekly can help teams identify changes before they accumulate.
The operational lesson is more important than the differences between platforms: someone needs to be responsible for keeping track of change.
For WordPress, the Site Health screen provides a useful view into outdated software and configuration issues. Drupal and Backdrop have their own tools and processes for monitoring available updates and security advisories. But knowing an update exists is only the beginning.
Updates still need to be evaluated, tested, and deployed.
Consider a site that receives routine maintenance every month.
There might be a core update and several module or plugin updates to review. The team applies them in a development or staging environment, tests critical functionality, resolves any issues, and deploys the changes.
Now consider the same site after maintenance has been deferred for two years.
There may be dozens of pending updates spanning multiple versions. Some dependencies may no longer be maintained. A newer module or plugin may require a newer version of the CMS. That version may require a newer version of PHP. Custom code written several years earlier may no longer behave as expected.
What could have been a series of small maintenance tasks has become a project.
The difficulty is not simply the number of updates. It is the number of things changing at once. When something breaks, there are more possible causes. Testing takes longer. Troubleshooting becomes less predictable.
Regular maintenance keeps those changes smaller and makes risk easier to manage.
After launch, most organizations still have a list of things they want to change. Editors need improvements to a workflow. A department wants a new feature. An integration needs adjustment. Bugs emerge once more people start using the site.
That work is visible, and its value is usually easy to understand. Routine maintenance is less visible. Updating a dozen modules and ending up with a site that looks and behaves exactly as it did before can be difficult to prioritize against a feature someone has been waiting for.
But those two kinds of work need to coexist.
For many sites, a recurring monthly maintenance allocation is a sensible baseline alongside a budget for improvements and feature development. It creates room to review available updates, apply appropriate changes in a non-production environment, test important workflows, and deploy deliberately without forcing that work to compete every month with the next feature request.
The exact cadence can vary. WordPress sites may warrant weekly or bi-weekly checks because plugins and themes release independently. Security updates on any platform may require attention outside the normal maintenance cycle.
Testing matters too. A plugin update that looks routine can conflict with WordPress core or another plugin. A Drupal module update can affect custom functionality or configuration. Updates should generally move through development or staging before reaching production.
Backups are another part of the equation, particularly for WordPress sites where application state and content are closely connected to the database. Reliable, automated backups, preferably managed at the hosting level, provide an important recovery path when an update does not behave as expected.
The goal is not simply to install updates. It is to make maintenance a normal part of operating the site rather than something that only gets attention when there is a problem.
Planning for maintenance does not mean every build needs a separate maintenance workstream.
During an active build, teams can often incorporate core, module, plugin, and dependency updates into the normal development process. What matters is that the team is paying attention. On a project that lasts six months, a year, or longer, building against a frozen snapshot of the software and waiting until launch to address updates creates unnecessary risk.
Decisions made during the build also affect how difficult future maintenance will be.
Every module, plugin, theme, integration, and piece of custom code becomes part of the site's long-term maintenance surface. Before adding a dependency, teams should consider whether it is actively maintained, how important it will be to the site, and what replacing it would involve if support ends.
Architecture matters as well. Clear separation between custom code, contributed software, configuration, and content makes future changes easier to understand and test. Automated tests around critical functionality can make routine updates considerably safer.
The same thinking applies beyond code. Structured content, consistent components, and well-defined editorial workflows reduce the number of exceptions teams have to account for when the platform changes.
Maintainability is not a separate phase of the build. It is one of the considerations that should inform how the platform is built.
Skipping maintenance can look like a savings because nothing happens immediately. It can also create more room in the budget for improvements that stakeholders can see and use right away.
But the maintenance work has not disappeared.
Updates continue to accumulate, dependencies continue to change, and older versions eventually stop receiving support. When the organization finally has to act, the work is usually larger and the options are more constrained.
A recurring maintenance budget helps turn that unpredictable future project into routine digital operations. It gives teams a chance to make smaller changes, test them carefully, and identify larger lifecycle issues before they become urgent.
That does not mean maintenance should consume the entire post-launch budget. Websites need to improve as organizational needs change. The goal is to make room for both: maintaining the platform you have while continuing to make it better.
The cost of waiting is not just more updates later. It is giving up control over when and how those updates happen.
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.
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.
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.
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.
Today at DrupalCon Rotterdam, Dries Buytaert presented the future of Drupal CMS and Drupal AI. The key message: Working with content is becoming dramatically easier, more flexible, and more intelligent for editors, marketing teams, and organizations.
read moreRotterdam, Netherlands, 28 September 2026. The International Splash Awards 2026 concluded today during DrupalCon Europe in Rotterdam, celebrating the world’s most outstanding Drupal projects, agencies, and developers. The annual awards recognize excellence in design, innovation, technical achievement, and community impact across a range of categories.
The range of entries shows how powerful Drupal as an Open Source system truly is. From municipal websites to apps that connect parents in developing nations to expert childcare advice, the competition this year was fierce.
— Hilmar Kári Hallbjörnsson, head of jurors, International Splash Awards
Photo Credits: Joris Vercammen
Following the successful return of the International Splash Awards in 2025, this year’s competition saw an even greater participation from across the global Drupal community, receiving 40% more submissions than the previous year. A distinguished jury of independent experts in web design, user experience, open source development, and digital strategy evaluated entries across criteria including concept, execution, emotional appeal, accessibility, performance, innovation, and social relevance.
Photo Credits: Joris Vercammen
The International Splash Awards serve not only to honor outstanding work but also to inspire collaboration, share best practices, and elevate the broader Drupal ecosystem. The projects recognized this year demonstrate the diversity of ways Drupal can be used to create meaningful, accessible, innovative, and high-performing digital experiences.
From ambitious public platforms and global corporate ecosystems to innovative applications and community-focused initiatives, the 2026 winners showcase the scale and maturity of Drupal as an open source digital experience platform.
Beyond the projects themselves, the Awards celebrate the people and organizations behind them. Many participants contribute to the Drupal community through open source development, modules and distributions, conference talks, training, mentoring, and knowledge sharing.
Thank you to eSepia for sponsoring the International Splash Awards this year. And also thank you to Acquia for doing the interviews.
With the 2026 edition now behind us, the International Splash Awards will continue to evolve alongside Drupal and the wider digital landscape. As organizations face increasingly complex challenges around AI, accessibility, privacy, sustainability, digital sovereignty, and user experience, the Awards will continue to recognize projects that demonstrate how open source technology can meet these challenges with creativity and purpose.
Photo Credits: Joris Vercammen
The International Splash Awards will return in 2027, continuing its mission to bring the global Drupal community together and celebrate the people, ideas, and projects shaping the future of the open web.
The International Splash Awards is an independent, global awards program that highlights exceptional Drupal-powered websites, applications, and digital solutions. Its mission is to recognize creativity, technical excellence, and social impact within the Drupal and open-source communities.
The Splash Awards have been organized as regional competitions in Drupal communities around the world for many years. In 2018, the Splash Awards went international, giving outstanding projects from across the globe the opportunity to compete on a global stage. Following a break, the International Splash Awards returned in 2025 and are now an annual fixture at DrupalCon Europe.
For more information about categories, submission guidelines, jury members, and past winners, visit https://splashawards.org/.
Dries Buytaert opened DrupalCon Rotterdam with a tour of a platform moving at remarkable speed. Multilingual sites that take a fraction of the effort to build. Components written in React. Headless delivery across five frameworks. AI assistants that connect directly to your content. A pipeline of innovation that has Europe's push for digital sovereignty looking closely at Drupal.
Then he named the problem: hardly anyone outside this community knows. The market's picture of Drupal runs years behind what the platform can do today.
Rotterdam has a saying: "Niet lullen maar poetsen." Stop talking, start working. Dries argued we have taken that advice almost too well, and he flipped it. The work is done. Now it's time to talk louder about what is working, and for the first time, that work earns contribution credit.
Here is what he covered.
Dries opened with a challenge facing Europe: reducing its dependence on technology it does not control. When the European Commission asked for feedback on digital sovereignty, Dries submitted his thinking, and his writing was referenced in the official policy recommendation that followed.
His point: open source projects like Drupal offer more than software. They offer ongoing maintenance, security releases, and a global community of care. He gave it a name he hopes will catch on: Stewarded Open Source.
For governments and organisations that need control over their digital infrastructure, Drupal is exactly that: open source with a steward, proven at scale, and owned by no single vendor. As Dries put it: "Europe needs Drupal. And Drupal needs Europe too."
Two years after launching the Starshot initiative, Dries reflected on what it delivered: Drupal CMS, recipes, site templates, Canvas, and a wave of AI tools. Then he showed four ways Drupal is bringing its strengths to more people:
You can already connect an AI assistant to a Drupal site using a recipe that combines Simple OAuth, MCP Server, and the Tool module. Dries demonstrated it on his own photo album module, built to answer questions like "Do you have that photo of Oma wearing her sunglasses?"
Fully exposing his module's capabilities took around 1,000 lines of code. A research prototype built with Matt Glaman reduced that to roughly 20 PHP attributes. Describe a capability once, and it becomes available everywhere: to AI assistants, to workflow tools like ECA, to JavaScript components, and to humans who never touch AI at all.
To turn the prototype into a shared roadmap, Dries announced the Rosetta Sprint. Like the Rosetta Stone, which carried one decree in three scripts, the goal is for Drupal to describe its capabilities once, in a way that AI agents, other systems, and humans can all read.
The sprint will bring key maintainers together for four days of focused work.
Dries named Drupal's reputation gap as the project's number one challenge. Too many people are judging the Drupal of ten years ago, and AI systems trained on old information repeat that outdated story.
His answer is not hype. "Drupal doesn't need hype. It needs a better public record."
So the Drupal Association is launching the Drupal Advocacy Program, a pilot that awards contribution credit for work that helps people discover and understand Drupal: writing tutorials, recording demos, translating articles, amplifying someone else's talk. Each quarter, a focus theme with a ready-made source kit earns double credits.
Submissions open today at drupal.org/advocacy.
Dries closed with the Rotterdam Pilot: a challenge to everyone at DrupalCon to turn the buzz in the room into buzz outside it. Share a takeaway. Clip a talk. Write about someone else's session and credit them.
"Drupal is now light-years ahead of its reputation," he said. Closing that gap is work we can all do, starting this week.
Slides will be posted at dri.es.
Dries Buytaert opened DrupalCon Rotterdam with a tour of a platform moving at remarkable speed. Multilingual sites that take a fraction of the effort to build. Components written in React. Headless delivery across five frameworks. AI assistants that connect directly to your content. A pipeline of innovation that has Europe's push for digital sovereignty looking closely at Drupal.
Then he named the problem: hardly anyone outside this community knows. The market's picture of Drupal runs years behind what the platform can do today.
Rotterdam has a saying: "Niet lullen maar poetsen." Stop talking, start working. Dries argued we have taken that advice almost too well, and he flipped it. The work is done. Now it's time to talk louder about what is working, and for the first time, that work earns contribution credit.
Here is what he covered.
Dries opened with a challenge facing Europe: reducing its dependence on technology it does not control. When the European Commission asked for feedback on digital sovereignty, Dries submitted his thinking, and his writing was referenced in the official policy recommendation that followed.
His point: open source projects like Drupal offer more than software. They offer ongoing maintenance, security releases, and a global community of care. He gave it a name he hopes will catch on: Stewarded Open Source.
For governments and organisations that need control over their digital infrastructure, Drupal is exactly that: open source with a steward, proven at scale, and owned by no single vendor. As Dries put it: "Europe needs Drupal. And Drupal needs Europe too."
Two years after launching the Starshot initiative, Dries reflected on what it delivered: Drupal CMS, recipes, site templates, Canvas, and a wave of AI tools. Then he showed four ways Drupal is bringing its strengths to more people:
You can already connect an AI assistant to a Drupal site using a recipe that combines Simple OAuth, MCP Server, and the Tool module. Dries demonstrated it on his own photo album module, built to answer questions like "Do you have that photo of Oma wearing her sunglasses?"
Fully exposing his module's capabilities took around 1,000 lines of code. A research prototype built with Matt Glaman reduced that to roughly 20 PHP attributes. Describe a capability once, and it becomes available everywhere: to AI assistants, to workflow tools like ECA, to JavaScript components, and to humans who never touch AI at all.
To turn the prototype into a shared roadmap, Dries announced the Rosetta Sprint. Like the Rosetta Stone, which carried one decree in three scripts, the goal is for Drupal to describe its capabilities once, in a way that AI agents, other systems, and humans can all read.
The sprint will bring key maintainers together for four days of focused work.
Dries named Drupal's reputation gap as the project's number one challenge. Too many people are judging the Drupal of ten years ago, and AI systems trained on old information repeat that outdated story.
His answer is not hype. "Drupal doesn't need hype. It needs a better public record."
So the Drupal Association is launching the Drupal Advocacy Program, a pilot that awards contribution credit for work that helps people discover and understand Drupal: writing tutorials, recording demos, translating articles, amplifying someone else's talk. Each quarter, a focus theme with a ready-made source kit earns double credits.
Submissions open today at drupal.org/advocacy.
Dries closed with the Rotterdam Pilot: a challenge to everyone at DrupalCon to turn the buzz in the room into buzz outside it. Share a takeaway. Clip a talk. Write about someone else's session and credit them.
"Drupal is now light-years ahead of its reputation," he said. Closing that gap is work we can all do, starting this week.
Slides will be posted at dri.es.
Introduction
I use AI every day to accomplish a variety of tasks. I'd like to share three tales about building, maintaining, and contributing to different Drupal modules. My goal is to discuss how I use AI and what I use it for.
At the same time, I am not trying to teach you how to use AI because I've noticed a nuance: AI can teach you how to use AI. For example, you can point an AI at this post and ask it to read the post, follow the links, and explain how things are being done. For me, open source and Drupal have always been more about sharing ideas, experiences, and stories, as well as code, allowing humans and their AIs to learn from or be inspired by each other's experiences.
My three tales are meant to be told in a specific order: building a greenfield project, maintaining a brownfield project, and contributing to someone else's project. Because of how AI works and the increased use of spec-driven development, people are discussing projects in terms of greenfield vs. brownfield. Ironically, I don't think of Drupal as greenfield or brownfield, but as infrastructure that fields and projects sit on top of. The most fundamental greenfield project in Drupal is building a new site for an organization, and for contributions to Drupal, building a new module.
Building a module using AI
Building a Drupal module with AI isn't new. I've written several posts that range from learning to build a Drupal module using AI to having AI build a module. The most recent module I've "built" with AI and contributed back to Drupal has a unique nuance: the initial code and solution came from an existing client project we are modernizing, and I had AI...Read More
read morePerhaps the most revealing thing about DrupalCon Rotterdam is that its programme does not tell one tidy story. Drupal is preparing to discuss its transformation into a production-ready Agentic CMS while another session asks, quite directly, why developers still do not choose Drupal. Canvas has become central to Drupal CMS, yet Rotterdam will also put it against Display Builder in a real-world project. Those collisions matter because Drupal’s next phase depends less on any one initiative succeeding than on whether these different bets can reinforce one another without carrying old friction forward.
Connecting Drupal to models and agents is no longer the difficult part of the AI story. Rotterdam moves quickly into hallucination, reviewer trust, orchestration, governed workflows and human control because production use raises harder questions about what an agent may do once it can act rather than merely answer. Permissions, auditability, validation and human approval are becoming part of the product itself. If the Agentic CMS idea is going to mean more than a collection of AI capabilities, those boundaries have to become as deliberate as the capabilities they constrain.
Adoption tests another part of the same argument. Drupal CMS 2.0, Canvas, Recipes and AI-assisted tooling have changed the product presented to builders, but improved technology does not automatically change how Drupal is perceived beyond its existing community. “Why Developers Don’t Choose Drupal” puts that gap unusually plainly. The useful evidence from Rotterdam will not be another inventory of features, but signs that newcomers can enter the system more easily, that organisations are choosing Drupal CMS rather than only inheriting or upgrading Drupal, and that the new experience removes barriers people outside the community can actually feel.
Digital sovereignty makes the question more demanding because Drupal is also being asked to apply its values inward. A Rotterdam discussion on FAIR asks whether sovereignty, governance and cost problems in Drupal’s own software distribution could be addressed differently, starting from Drupal.org’s role as the ecosystem’s central distribution point. That turns openness from something Drupal offers its users into something its own infrastructure may need to demonstrate. Arguments about control become more credible when the project is willing to examine where dependence, responsibility and operational burden sit inside its own systems.
Discovery may be where all of these threads become visible from outside. A Rotterdam discussion on Drupal’s representation in ChatGPT, Gemini and Claude starts from the recognition that developers and decision-makers increasingly encounter technologies through AI-generated answers as well as conventional search. Drupal therefore has to become easier to understand, evaluate and trust not only for people already inside the ecosystem, but also for the systems mediating their choices. Rotterdam will not settle all of that in four days. What it can reveal is whether Drupal’s current direction is beginning to cohere: a product easier to adopt, agents with clearer limits, infrastructure consistent with its sovereignty claims, and a project that can explain its relevance wherever technology choices now begin.
Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.
Kazima Abbas wrote and curated this issue of Editor’s Pick.
read moreDrupal's configuration system has at its heart a key concept: the site owns the configuration. What that means is that after a module has provided install configuration, it no longer has any control over it. You, the site admin, can change that config or even delete it. The module is no longer involved.
This kept the configuration system simple (up to a point); after all, the development of this system was one of the harder parts of the lengthy and difficult Drupal 8 cycle ("The ConfigImporter class was written with a get this done and working attitude" wrote @alexpott on a core issue, and I think the same could be said of the configuration system as a whole).
Since then, the config transformation API was added, and various modules have been created that take advantage of this, such as Configuration Split and Config Merge. These still work in the paradigm of the site owning the configuration. But what if we could turn the clock back, just partially, to when modules could own config too?
If you were around in the days of Drupal 7, you may remember the various default hooks. Modules such as Views and Flag exposed a hook which allowed modules to define configuration items. (These were not configuration in the modern sense, because there wasn't that concept at the time, but referring to them as such makes things simpler.)
These were thus a code-defined instance of a type of thing that could also be defined in the UI by site admins. A module could supply a default view, and rely on it always existing. A new release of a module could come with enhancements to a that view, and they would exist on the site as soon as the module code was updated to the new version.
Because these hooks were PHP code, it was also possible for configuration to dynamically depend on other aspects of the site. You could do something such as define a default flag for every node type.
For a long time, I've wondered if something similar could be possible with Drupal's configuration system: put simply, defining configuration in code. Or, as I'm calling it, fixed config.
Many modules, such as Drupal Commerce and LocalGov Drupal rely on configuration items which are essential to their functionality (what I call machinery). Drupal's paradigm of configuration being owned by the site means that a site admin can break or outright delete key parts of the module's functionality: a commerce system missing its cart view, or a directory system missing its node types and vocabularies.
There's a case for admins being able to enhance and tweak a module's machinery, but that leads to the problem of how to reconcile a site's changes with changes that come in a new version of a module. There are modules that aim to help with this, but configuration entities are complex data structures, and without in-depth knowledge of that structure, this is a difficult and painstaking task. Some modules take care of this in update hooks each time they want to change their machinery, but that also requires complicated work each time.
The final push to get me to work on this was the use case of Entity Pager: the maintainer of the Flippy module suggested merging the two modules. But while Entity Pager provides the means for site admins to create any pager for any entity type, Flippy's functionality is to automatically provide a pager for each node type on the site. It seemed to me that the way to achieve this feature on top of Entity Pager was to have a way for the Flippy module to define an entity pager view automatically for each node type. The same way that Drupal 7 default hooks could.
Could this be done within the modern Drupal config system? The module would be in charge, not the site. If the module's code updated and changed the definition of the config, then the site would pick up on that.
The basic requirement is to add config entity definitions that are coming from code.
I could see two ways of doing this: intercept the entity storage handlers, or intercept the config transformation API. I opted for the latter. Partly because working at the entity storage level would require decorating every config entity type storage handler, which seemed heavy-handed, and because working within the config system has its advantages, and finally because one general principle I have found over the years is that complexity should generally be pushed down in a system. The config system is beneath the entity system, so working there would mean that this would be completely invisible to the entity system which would just see some additional entities.
So, I experimented with the config storage transformation API. Could I make it see, for example,
a hardcoded node type? The answer was yes: it's simple to add an additional
config entity in the STORAGE_TRANSFORM_IMPORT event, and the site sees it just as if
it were some other piece of config.
Then the real development work started: making the config system read the fixed config, but also ignore it when necessary. I decided on this simple rule:
On Drupal 7, some (but not all) default hooks had a concept of overriding. The site admin could choose to edit a default object, such as a view, and deviate from the version in code. From that point on, the site owned that object, not the module.
I've decided, for now at least, not to support overriding. I think a better, and simpler, pattern is to allow selection of config: the module provides machinery, but also provides a setting to select it as being in use. For our example of the commerce cart view, there would be the fixed config view, and also a config setting where you select which view is used for the cart. This means that the default view remains under the control of the commerce module, but a site admin can duplicate it, change the duplicate, and then use that one instead. The site then owns the duplicate view, but the default view remains available and functional at all times.
Having got a proof-of-concept, the next step was to design an API too. Rather than use hooks or an event, I decided fixed
config should look the same as install config: YAML files. The big advantage here
being that while developing it, you can move YAML files from sync or install folders to become fixed
config. And it provides a system that is already familiar to developers: fixed config is simply a YAML file in a module's config/fixed folder instead of config/install. (I made a small change and a
new release of Config Devel so that its module config export feature works with this folder too.)
But static YAML files doesn't cover all the use cases that the Drupal 7 era hooks used to satisfy. So I added the concept of derivers. We already have plugin derivers in Drupal (and maybe I should have tried to think of a different name); but these are config deriver plugins: they create multiple config items from a single template.
So while a static fixed config file looks identical to an install config file, a derived fixed config file has these additions:
third_party_settings:
fixed_config:
deriver: deriver_plugin_id
dependee_config_patterns:
- node.type.*
What this means is that when config whose name matches node.type.* is created or updated,
the fixed config deriver plugin deriver_plugin_id reacts, and maintains the fixed config based on the YAML file
that holds these properties.
The node type config entity is the dependee config; the fixed config that gets defined in response to that is the dependent fixed config.
This is how the Flippy module could then work: it defines a single fixed config YAML file for a view, and a deriver plugin which alters these config values:
I find that you never fully realise what an API needs to do or how it needs to work and how to best make it usable until you actually try to use it, and that therefore it's best to do that early on.
I started making the Entity Pager view, and I was soon struck with several things about what I'd made:
That reusability feature could be solved by using PHP traits, and requiring developers to composite them into their plugin classes. Or it could be solved by making the plugins themselves smaller, and allowing the deriving process to specify more than one. A pipeline, basically.
And the many-to-one feature could be solved by letting code alter the fixed config YAML file values, rather than deriving from them: the same config values get processed by the PHP code for every config entity it listens for, rather than making a new copy each time.
To me, this suggests a new type of plugin, fixed config alterers, which can do the work in both of these scenarios.
So what I am pondering now would look like this:
Am I over-engineering, I wonder? Also, the pipeline of alterers seems very much like the Migrate API's pipeline of processors, but I don't see how to reuse those as they operate on different sorts of values: entire config entity values for my case, and single content entity field values for Migrate.
I'd be interested in hearing ideas and use cases for the fixed config module. It would help me with the process of refining my initial ideas for the API.
I've made an alpha release, try it out and let me know what you think, either in the issue queue or on mastodon.
Do you have potential uses for fixed configuration? I'd love to work on this module with some real-world use cases, and I'm available for hire - contact me!
Since September, advertisers in Europe can buy ads inside ChatGPT, and the Ads Manager asks for two things before it can tell you whether they work: a measurement pixel in the browser and, ideally, conversions sent from your server. On a Drupal site that usually means pasting a snippet into the theme, writing the order_created call by hand in a template, and trying to hide the whole thing behind the cookie banner. Then the order paid by bank transfer or payment reference hours later, confirmed by a webhook, never shows up, because no browser was there to see it.
Even when a browser is there, the pixel loses part of the picture. Ad blockers stop it outright, Safari caps cookies written by scripts at seven days, and iOS removes tracking parameters from links shared in Messages and Mail and from links opened in private browsing. OpenAI's own documentation calls the Conversions API "a more reliable tracking source than the pixel alone".
We have released a module for this on drupal.org: ChatGPT Ads, free software under the GPL, for Drupal 10.3 and 11, covered by Drupal's security advisory policy. It plugs into Drupal Commerce, Webform and the Klaro consent manager through sub-modules, and sends events through both OpenAI's Measurement Pixel and the Conversions API. It is a community module, not affiliated with OpenAI.
Drupal.chatgptAds.measure() from your own script.The pixel goes only on the pages you choose, using the same visibility conditions blocks use: paths, roles, content types, language.
Nothing is requested from OpenAI, and no cookie is set, until the visitor has decided. OpenAI's documentation suggests loading the pixel with consent withheld and granting it later, but the script sets cookies as soon as it loads, so the module does not load it at all until there is an answer.
A visitor who has not answered yet is neither a yes nor a no. Their events wait in memory and go out if they accept, so the landing page is not lost; if they refuse, they are dropped. The Klaro integration reads only decisions the visitor has confirmed, because Klaro reports a service's default from the moment the page loads, which would otherwise be read as a refusal while the banner is still on screen.
The same rule applies on the server. Hashed email, phone, IP address and user agent go to the Conversions API only for a visitor whose consent was recorded at the time of the event. For everyone else the conversion still goes, carrying the click identifier and nothing about the person.
The module never saves an order. Saving inside a Commerce transition can fire that transition twice, which on a live store means duplicate receipts and an error at checkout; the click identifiers are stored on the order when the checkout flow saves it anyway.
The pixel and the settings that are the same for everyone are cached with the page. What belongs to one visitor, the events collected for that page and, with advanced matching on, their hashed account data, arrives through a placeholder rendered on every request. A page carrying the pixel stays in Drupal's Dynamic Page Cache, instead of turning every page on the site uncacheable to deliver one visitor's identity.
It was built for one of the e-commerce stores we develop in Portugal, where many orders are paid by Multibanco or MB WAY, Portuguese payment methods whose confirmation often arrives hours after checkout. Bank transfers and payment references behave the same way in any country, and that pattern is why the Conversions API is in the first release rather than a later one: without it, those sales are invisible to the ad platform. The pixel, the Klaro gate and the cart events have been running on that store since mid September.
Klaro gets a ready-made sub-module: install it and a ChatGPT Ads service appears in the banner, off by default. Any other consent manager reports the decision through a small JavaScript contract, and the README carries a working recipe for EU Cookie Compliance:
Drupal.chatgptAds.consent(true); // granted, now or on a later page
Drupal.chatgptAds.consent(false); // refused or withdrawn
To see what else on your site reaches third parties before the visitor decides, Consent Audit records it from real visits.
composer require drupal/chatgpt_ads
You need a ChatGPT Ads Manager account and the pixel id from its Conversions tab. The Conversions API sub-module stores its key through the Key module, so the secret can live in an environment variable instead of your exported configuration. The project page, the documentation and the issue queue are on drupal.org. Bug reports, questions and merge requests are welcome.
The inaugural DrupalCon Talent Show is happening at DrupalCon Orlando on the evening of Tuesday, March 23, 2027 as part of the community party!
We’re planning about two hours of entertainment and looking for roughly 10 acts to take the stage (5–7 minutes for the act, plus up to 3 minutes for stage setup).
This is DrupalCon. The goal is to learn, network, and have fun. Expect jokes, friendly razzing, questionable decisions, and plenty of laughs. You don’t need to be a professional. You just need to be willing to get up there and attempt to entertain your fellow Drupalers (within our Code of Conduct https://events.drupal.org/code-conduct, of course!)
Pretty much anything entertaining:
Got something that doesn’t fit on the list? Even better. Solo acts, groups, first-timers, seasoned performers, and wonderfully questionable ideas are all welcome.
Think you’ve got something? Sign up here and show us what you’ve got!
The absolute last deadline to sign up is Friday, February 19th. However, submissions are reviewed on a rolling basis as they come in. Once all ~10 spots are filled, sign-ups will close early. We strongly encourage you to submit as soon as possible.
Likely, but this hasn’t yet been determined. Suffice it to say that the primary prize will be bragging rights!.
Performances will be chosen to ensure a wide variety of performance types, geographical regions, companies, diverse performers, etc. You can increase your chances of being selected by submitting earlier rather than later.
5-7 minutes is ideal
We will provide microphones for your band (up to four). If needed by multiple performers, we may be able to supply basic instruments. Details will be provided ahead of the performance if you are accepted to perform.
A cash (and credit card) bar will be available.
The inaugural DrupalCon Talent Show is happening at DrupalCon Orlando on the evening of Tuesday, March 23, 2027 as part of the community party!
We’re planning about two hours of entertainment and looking for roughly 10 acts to take the stage (5–7 minutes for the act, plus up to 3 minutes for stage setup).
This is DrupalCon. The goal is to learn, network, and have fun. Expect jokes, friendly razzing, questionable decisions, and plenty of laughs. You don’t need to be a professional. You just need to be willing to get up there and attempt to entertain your fellow Drupalers (within our Code of Conduct https://events.drupal.org/code-conduct, of course!)
Pretty much anything entertaining:
Got something that doesn’t fit on the list? Even better. Solo acts, groups, first-timers, seasoned performers, and wonderfully questionable ideas are all welcome.
Think you’ve got something? Sign up here and show us what you’ve got!
The absolute last deadline to sign up is Friday, February 19th. However, submissions are reviewed on a rolling basis as they come in. Once all ~10 spots are filled, sign-ups will close early. We strongly encourage you to submit as soon as possible.
Likely, but this hasn’t yet been determined. Suffice it to say that the primary prize will be bragging rights!.
Performances will be chosen to ensure a wide variety of performance types, geographical regions, companies, diverse performers, etc. You can increase your chances of being selected by submitting earlier rather than later.
5-7 minutes is ideal
We will provide microphones for your band (up to four). If needed by multiple performers, we may be able to supply basic instruments. Details will be provided ahead of the performance if you are accepted to perform.
A cash (and credit card) bar will be available.
This is the fourth article in a series looking at migrating from Jadu into LocalGov Drupal (LGD) for the Central Bedfordshire site. In the first article we looked at the Jadu API itself and setting things up so that we could make calls to the API and parse the XML data using the migration systems available.
In the second article we looked at reproducing Jadu URLs to create redirects for migrated content, even though the Jadu API doesn't contain any URL information.
In the third article we looked at a more complex example of migration, taking documents and pages from Jadu and creating a guide pages from that data.
Now it is time to move onto what became the most complex part of the Central Bedfordshire migration, which was moving directories data from Jadu to LGD. Directories were used on the Jadu site to store all sorts of information, which included schools, the location of car parks, contact information of homecare providers, and even an a-to-z glossary of recycling. This data served different purposes on the site, but it was all hand created and important to bring across during the migration work.
In this article we will look at the Jadu data we needed to fetch to find directory information, and how that data was injected into the LGD structure available.
First, let's look at how we get directory information out of Jadu.
Directories in Jadu can be fetched using the directories index at the following endpoint.
philipnorton42 read moreThe prototype works. Taking it to production quality is more than evenings. Whether it should is a question, not a pitch.
One thing before the rest. I am not pushing this. The series is a question to the world: is this work worth more of my time? We are not in the Federation yet, so more time means money, and money means backers. Any answer is fine with me, including no.
read moreDrupal CMS 2.2.0 is out, and this release is all about multilingual. Setting up a site to publish in multiple languages has always been possible in Drupal, but it was not easy. With 2.2, we've tackled the biggest pain points from the installer through to translating your Canvas pages.
The first thing you'll notice is the language selector in the installer. Instead of scrolling through a long select list, you can now start typing and search for your language.
It's a small change, but makes for a much better first impression.
Previously, if you installed Drupal CMS in another language, any configuration provided by recipes (such as content types, fields, views, even the dashboard) would still show up in English.
Recipes can include translatable configuration and that is now translated along with the rest of the site.
Adding a second language to a Drupal site involves a lot of steps: installing the right modules, configuring language detection, enabling translation for each content type and field, and making sure you haven't missed anything along the way. Most people figure this out through trial and error (and a fair amount of searching).
The new multilingual recipe takes care of most of this for you:
Canvas now fully supports translation and we're using Canvas Translate to provide the translation management within the canvas editor. You can translate any component on a page, and use the Canvas preview to see how the translated version will look before you publish it.
Using the bundled Canvas Translate AI module, you can also get AI-generated translations with one click: either for all components, or individually.
Drupal core has long shipped with the Umami multilingual demo, which has community contributed, cooked and photographed recipes. Umami will not be included in Drupal 12 anymore and it was in need of a design rethink and retooling with our new easy to use page building capabilities. This resulted in the new Dashi demo, which brings the same multilingual content to a customizable setup with Canvas page and content templates.
Try it out by installing Drupal CMS 2.2.0!
mkdir my-drupal-site && cd my-drupal-site
ddev config --project-type=drupal11 --docroot=web
ddev composer create-project drupal/cms
ddev launchDrupalCon Rotterdam 2026 is almost here. The Drupal Association staff and board are heading to the Netherlands next week, and we'd love to see you there!
Photo Credits: Ryan Witcombe
Here's where you'll find us during DrupalCon Rotterdam 2026:
Join the DA engineering team for an open and honest look at the current state and future of Drupal.org (the platform the entire community relies on every day). From nearly 10,000 projects migrated to GitLab, plans to support a brand new Drupal.org marketing site, and initiative support for Drupal CMS + Canvas and the AI Initiative, there's a lot to cover. The session closes with an open Q&A, so bring your questions
Day & Date: Wednesday, September 30, 2026
Time: 11:40 to 12:25 CEST
Location: Goudriaan Room I&II
Building on the momentum of the Drupal AI initiative, the Drupal Association is growing coordinated advocacy and marketing efforts in new areas, opening the door for more people to get involved and make a visible contribution.
Join the panel to understand how the initiative is taking shape, why they’re gaining traction, and what makes them different. The panelists will discuss how marketing in Drupal is becoming one of the most accessible and high-impact ways to contribute, where individuals and organizations alike can raise their profile, earn recognition, and help shape Drupal’s future.
Day & Date: Tuesday, September 29, 2026
Time: 16:40 to 17:25 CEST
Location: Goudriaan Room I&II
The DA Public Board Meeting is open to all DrupalCon attendees and is your opportunity to hear directly from the Drupal Association board. Come with your questions, your feedback, and your ideas. This is your chance to engage with the people shaping the future of the Drupal Association.
Day & Date: Tuesday, September 29, 2026
Time: 14:25 – 15:10 CEST
Location: Rotterdam Room I&II
An exclusive afternoon gathering for agency leaders and partners to connect with Dries and DA leadership over a seated lunch. A unique opportunity to share strategies, discuss the Drupal business ecosystem, and build meaningful relationships with peers from around the world.
Tickets are required, register here.
Day & Date: Tuesday, September 29, 2026
Time: 12:00 – 13:30 CEST
Location: Postillion Hotel & Convention Centre WTC Rotterdam
Cap off Wednesday evening with the Drupal Business Dinner, an intimate gathering of Drupal agency executives for a seated 3-course dinner, a presentation, and meaningful conversations in a beautiful Rotterdam venue.
Tickets are required, register here.
Day & Date: Wednesday, September 30, 2026
Time: 19:00 – 22:30 CEST
Location: De Harmonie, Rotterdam
Photo credits: Matthew Saunders
Whether you're joining us for a session, an exclusive event, or just stopping by our booth to say hello, the Drupal Association team can't wait to connect with you.
The last few days are left to secure your ticket to DrupalCon Rotterdam 2026, if you already haven’t. See You in Rotterdam!