Missed the Driesnote? You can watch it here.
Drupal, the open source content management platform that runs some of the most demanding websites on the planet, turned 25 in January. But while the community is celebrating what is a remarkable milestone for any open source project, it is actively strengthening its foundations to lead in the AI era and looking ahead to a future it intends to shape.
This week at DrupalCon Chicago, Drupal's creator Dries Buytaert delivered his annual keynote, the DriesNote, and it was one of the more honest talks you'll hear at a tech conference. A clear-eyed look at what's working, what's under pressure, and what the plan actually is.
For more than two decades, the Drupal ecosystem has rested on three things: the platform itself, the agencies that build with it, and the community that maintains it. That triangle has survived waves of new technology and constant change. It's been remarkably resilient.
But what happens when AI disrupts all three sides at once? When anyone can spin up a decent-looking site in fifteen minutes, what does that do to the people who've spent years building something better? That’s what is happening at the moment, as the world is being flooded with AI-generated “average”. Average content, average code, average websites - average is easier to attain than ever.
What it means is that the only thing that will actually matter, to customers, to organisations, to the people trying to build something lasting on the open web, is genuine, hard-won, deep expertise.
Here's something worth understanding, because it gets lost in the noise.
AI can generate a beautiful website in about fifteen minutes. Tools like Lovable and Replit are genuinely impressive. You give them a prompt, they give you something that looks polished and professional. It feels like magic.
But a prototype is not a production system.
The moment you need structured content that editors can actually update, workflows that a real team can follow, permissions, governance, security, accessibility, multilingual support, compliance... you're not building a website anymore. You're building a system. And building systems is exactly what Drupal has excelled at for 25 years.
The demo at DrupalCon made this tangible. A beautiful event site built in Lovable in minutes, then migrated into Drupal CMS using AI coding tools, where the hard-coded layout became structured, reusable, editable content. Same visual ambition. Completely different foundation.
The pitch is simple: AI gets you to visual ambition fast. Drupal makes that ambition durable.
This isn't a vision talk. Things are being built and released.
DrupalCMS 2.1 landed at DrupalCon, built on top of Drupal Core 11.3. Over the last 18 months, core database and cache utilization have roughly halved, meaning every Drupal site in the world gets faster when it upgrades. That's not a minor thing. That's the compounding benefit of a serious engineering community.
Site templates and a marketplace are now live at marketplace.drupal.org, with more than ten purpose-built templates covering nonprofits, education, healthcare, events, government, and SaaS, built by agencies that understand those sectors. Free and premium options, with direct access to the people who made them if you need help.
Canvas, Drupal's new page-building layer, lets teams create and customise pages at speed without sacrificing the structured content underneath.
The Context Control Centre is a system for storing and managing your organisation's institutional knowledge (brand guidelines, content strategy, audience personas, live analytics) and it's moving from prototype to production. The idea is that AI tools are only as good as the context they're given. Without it, you get the average of the internet. With it, you get something that actually knows your brand.
And in the AI layer itself, a demo showed what it looks like when a marketer can drop a raw content brief into Drupal, have the system read it, load the right brand and strategy context, ask clarifying questions, and generate a production-ready page, with proper cross-linking, structured data for AI search engines, and an accessibility check built in.
That's not a concept. That's a demo running on real code.
The most striking moment of the keynote was a contribution from Jurgen Haas, one of the Drupal community's most experienced developers. He builds ECA, Drupal's automation engine, running on thousands of production sites.
Three years ago, he knew what ECA needed. He knew how to build it. He never had the time.
Six weeks ago, he started. With AI as a collaborator, handling scaffolding, generating tests, refactoring code, he shipped a completely rebuilt workflow editor: a new visual interface, built-in debugging and replay, in-context automation for non-technical users. 90,000 lines of code. Full test coverage. One person.
"This is what one Drupal developer can build in six weeks," he said. "Imagine what all of us can build next."
The key detail: Jurgen could explain every line. He could defend the architecture. He owned what he built. AI removed friction. It didn't replace expertise.
Not everything in the keynote was product news.
Dries was honest about the pressure on Drupal agencies. When AI commoditises production, and it is, the business models that agencies have built over years start to look shaky. An agency leader named Aidan Foster, seventeen years into running a Drupal shop, described the feeling plainly: "AI had converted making things into a commodity. That shook the foundations I had spent 17 years building."
But Aidan's conclusion was interesting. The bottleneck isn't production anymore. It's creativity, strategy, and judgement. If you use AI without asking the hard questions, who are we, who are our audience, what makes us different, you get the boring average. The agencies that will win are the ones that get good at encoding expertise, not just delivering outputs.
There's also a challenge for the community itself. AI lowers the barrier to contribute code, which sounds good, until you realise the burden of reviewing that code falls on the same small group of maintainers. And when people use AI to skip the deep learning that used to come from contributing, the community gets shallower. A shallow community can't maintain what's been built.
Dries' response was a new mantra:never submit code you don't understand. It doesn't matter what tools you used to write it. If you submit it, you own it.
Twenty years ago, Dries was a bedroom inventor who collapsed from stress on a street in Belgium. He had a choice: take a safe job, walk away from the thing he'd built, or ask for help and become a deliberate leader.
He made the harder choice. The community that grew up around that choice is why Drupal is still here, still relevant, still running critical infrastructure for organisations around the world.
Now there's another crossroads. AI is both the flood and the drainage system. It destabilises the foundations and it can help rebuild them stronger.
Twenty-five years of Drupal is twenty-five years of expertise built patch by patch, merge request by merge request. A community that showed up not because it had to, but because it cared. That's not a liability in the age of AI. That's exactly what this moment needs.
DrupalCon Chicago runs through this week. The marketplace is live at marketplace.drupal.org. The Context Control Centre is approaching production. The Drupal AI initiative is moving fast.
Missed the Driesnote? You can watch it here.
Drupal, the open source content management platform that runs some of the most demanding websites on the planet, turned 25 in January. But while the community is celebrating what is a remarkable milestone for any open source project, it is actively strengthening its foundations to lead in the AI era and looking ahead to a future it intends to shape.
This week at DrupalCon Chicago, Drupal's creator Dries Buytaert delivered his annual keynote, the DriesNote, and it was one of the more honest talks you'll hear at a tech conference. A clear-eyed look at what's working, what's under pressure, and what the plan actually is.
For more than two decades, the Drupal ecosystem has rested on three things: the platform itself, the agencies that build with it, and the community that maintains it. That triangle has survived waves of new technology and constant change. It's been remarkably resilient.
But what happens when AI disrupts all three sides at once? When anyone can spin up a decent-looking site in fifteen minutes, what does that do to the people who've spent years building something better? That’s what is happening at the moment, as the world is being flooded with AI-generated “average”. Average content, average code, average websites - average is easier to attain than ever.
What it means is that the only thing that will actually matter, to customers, to organisations, to the people trying to build something lasting on the open web, is genuine, hard-won, deep expertise.
Here's something worth understanding, because it gets lost in the noise.
AI can generate a beautiful website in about fifteen minutes. Tools like Lovable and Replit are genuinely impressive. You give them a prompt, they give you something that looks polished and professional. It feels like magic.
But a prototype is not a production system.
The moment you need structured content that editors can actually update, workflows that a real team can follow, permissions, governance, security, accessibility, multilingual support, compliance... you're not building a website anymore. You're building a system. And building systems is exactly what Drupal has excelled at for 25 years.
The demo at DrupalCon made this tangible. A beautiful event site built in Lovable in minutes, then migrated into Drupal CMS using AI coding tools, where the hard-coded layout became structured, reusable, editable content. Same visual ambition. Completely different foundation.
The pitch is simple: AI gets you to visual ambition fast. Drupal makes that ambition durable.
This isn't a vision talk. Things are being built and released.
DrupalCMS 2.1 landed at DrupalCon, built on top of Drupal Core 11.3. Over the last 18 months, core database and cache utilization have roughly halved, meaning every Drupal site in the world gets faster when it upgrades. That's not a minor thing. That's the compounding benefit of a serious engineering community.
Site templates and a marketplace are now live at marketplace.drupal.org, with more than ten purpose-built templates covering nonprofits, education, healthcare, events, government, and SaaS, built by agencies that understand those sectors. Free and premium options, with direct access to the people who made them if you need help.
Canvas, Drupal's new page-building layer, lets teams create and customise pages at speed without sacrificing the structured content underneath.
The Context Control Centre is a system for storing and managing your organisation's institutional knowledge (brand guidelines, content strategy, audience personas, live analytics) and it's moving from prototype to production. The idea is that AI tools are only as good as the context they're given. Without it, you get the average of the internet. With it, you get something that actually knows your brand.
And in the AI layer itself, a demo showed what it looks like when a marketer can drop a raw content brief into Drupal, have the system read it, load the right brand and strategy context, ask clarifying questions, and generate a production-ready page, with proper cross-linking, structured data for AI search engines, and an accessibility check built in.
That's not a concept. That's a demo running on real code.
The most striking moment of the keynote was a contribution from Jurgen Haas, one of the Drupal community's most experienced developers. He builds ECA, Drupal's automation engine, running on thousands of production sites.
Three years ago, he knew what ECA needed. He knew how to build it. He never had the time.
Six weeks ago, he started. With AI as a collaborator, handling scaffolding, generating tests, refactoring code, he shipped a completely rebuilt workflow editor: a new visual interface, built-in debugging and replay, in-context automation for non-technical users. 90,000 lines of code. Full test coverage. One person.
"This is what one Drupal developer can build in six weeks," he said. "Imagine what all of us can build next."
The key detail: Jurgen could explain every line. He could defend the architecture. He owned what he built. AI removed friction. It didn't replace expertise.
Not everything in the keynote was product news.
Dries was honest about the pressure on Drupal agencies. When AI commoditises production, and it is, the business models that agencies have built over years start to look shaky. An agency leader named Aidan Foster, seventeen years into running a Drupal shop, described the feeling plainly: "AI had converted making things into a commodity. That shook the foundations I had spent 17 years building."
But Aidan's conclusion was interesting. The bottleneck isn't production anymore. It's creativity, strategy, and judgement. If you use AI without asking the hard questions, who are we, who are our audience, what makes us different, you get the boring average. The agencies that will win are the ones that get good at encoding expertise, not just delivering outputs.
There's also a challenge for the community itself. AI lowers the barrier to contribute code, which sounds good, until you realise the burden of reviewing that code falls on the same small group of maintainers. And when people use AI to skip the deep learning that used to come from contributing, the community gets shallower. A shallow community can't maintain what's been built.
Dries' response was a new mantra:never submit code you don't understand. It doesn't matter what tools you used to write it. If you submit it, you own it.
Twenty years ago, Dries was a bedroom inventor who collapsed from stress on a street in Belgium. He had a choice: take a safe job, walk away from the thing he'd built, or ask for help and become a deliberate leader.
He made the harder choice. The community that grew up around that choice is why Drupal is still here, still relevant, still running critical infrastructure for organisations around the world.
Now there's another crossroads. AI is both the flood and the drainage system. It destabilises the foundations and it can help rebuild them stronger.
Twenty-five years of Drupal is twenty-five years of expertise built patch by patch, merge request by merge request. A community that showed up not because it had to, but because it cared. That's not a liability in the age of AI. That's exactly what this moment needs.
DrupalCon Chicago runs through this week. The marketplace is live at marketplace.drupal.org. The Context Control Centre is approaching production. The Drupal AI initiative is moving fast.
Missed the Driesnote? You can watch it here.
Drupal, the open source content management platform that runs some of the most demanding websites on the planet, turned 25 in January. But while the community is celebrating what is a remarkable milestone for any open source project, it is actively strengthening its foundations to lead in the AI era and looking ahead to a future it intends to shape.
This week at DrupalCon Chicago, Drupal's creator Dries Buytaert delivered his annual keynote, the DriesNote, and it was one of the more honest talks you'll hear at a tech conference. A clear-eyed look at what's working, what's under pressure, and what the plan actually is.
For more than two decades, the Drupal ecosystem has rested on three things: the platform itself, the agencies that build with it, and the community that maintains it. That triangle has survived waves of new technology and constant change. It's been remarkably resilient.
But what happens when AI disrupts all three sides at once? When anyone can spin up a decent-looking site in fifteen minutes, what does that do to the people who've spent years building something better? That’s what is happening at the moment, as the world is being flooded with AI-generated “average”. Average content, average code, average websites - average is easier to attain than ever.
What it means is that the only thing that will actually matter, to customers, to organisations, to the people trying to build something lasting on the open web, is genuine, hard-won, deep expertise.
Here's something worth understanding, because it gets lost in the noise.
AI can generate a beautiful website in about fifteen minutes. Tools like Lovable and Replit are genuinely impressive. You give them a prompt, they give you something that looks polished and professional. It feels like magic.
But a prototype is not a production system.
The moment you need structured content that editors can actually update, workflows that a real team can follow, permissions, governance, security, accessibility, multilingual support, compliance... you're not building a website anymore. You're building a system. And building systems is exactly what Drupal has excelled at for 25 years.
The demo at DrupalCon made this tangible. A beautiful event site built in Lovable in minutes, then migrated into Drupal CMS using AI coding tools, where the hard-coded layout became structured, reusable, editable content. Same visual ambition. Completely different foundation.
The pitch is simple: AI gets you to visual ambition fast. Drupal makes that ambition durable.
This isn't a vision talk. Things are being built and released.
DrupalCMS 2.1 landed at DrupalCon, built on top of Drupal Core 11.3. Over the last 18 months, core database and cache utilization have roughly halved, meaning every Drupal site in the world gets faster when it upgrades. That's not a minor thing. That's the compounding benefit of a serious engineering community.
Site templates and a marketplace are now live at marketplace.drupal.org, with more than ten purpose-built templates covering nonprofits, education, healthcare, events, government, and SaaS, built by agencies that understand those sectors. Free and premium options, with direct access to the people who made them if you need help.
Canvas, Drupal's new page-building layer, lets teams create and customise pages at speed without sacrificing the structured content underneath.
The Context Control Centre is a system for storing and managing your organisation's institutional knowledge (brand guidelines, content strategy, audience personas, live analytics) and it's moving from prototype to production. The idea is that AI tools are only as good as the context they're given. Without it, you get the average of the internet. With it, you get something that actually knows your brand.
And in the AI layer itself, a demo showed what it looks like when a marketer can drop a raw content brief into Drupal, have the system read it, load the right brand and strategy context, ask clarifying questions, and generate a production-ready page, with proper cross-linking, structured data for AI search engines, and an accessibility check built in.
That's not a concept. That's a demo running on real code.
The most striking moment of the keynote was a contribution from Jurgen Haas, one of the Drupal community's most experienced developers. He builds ECA, Drupal's automation engine, running on thousands of production sites.
Three years ago, he knew what ECA needed. He knew how to build it. He never had the time.
Six weeks ago, he started. With AI as a collaborator, handling scaffolding, generating tests, refactoring code, he shipped a completely rebuilt workflow editor: a new visual interface, built-in debugging and replay, in-context automation for non-technical users. 90,000 lines of code. Full test coverage. One person.
"This is what one Drupal developer can build in six weeks," he said. "Imagine what all of us can build next."
The key detail: Jurgen could explain every line. He could defend the architecture. He owned what he built. AI removed friction. It didn't replace expertise.
Not everything in the keynote was product news.
Dries was honest about the pressure on Drupal agencies. When AI commoditises production, and it is, the business models that agencies have built over years start to look shaky. An agency leader named Aidan Foster, seventeen years into running a Drupal shop, described the feeling plainly: "AI had converted making things into a commodity. That shook the foundations I had spent 17 years building."
But Aidan's conclusion was interesting. The bottleneck isn't production anymore. It's creativity, strategy, and judgement. If you use AI without asking the hard questions, who are we, who are our audience, what makes us different, you get the boring average. The agencies that will win are the ones that get good at encoding expertise, not just delivering outputs.
There's also a challenge for the community itself. AI lowers the barrier to contribute code, which sounds good, until you realise the burden of reviewing that code falls on the same small group of maintainers. And when people use AI to skip the deep learning that used to come from contributing, the community gets shallower. A shallow community can't maintain what's been built.
Dries' response was a new mantra:never submit code you don't understand. It doesn't matter what tools you used to write it. If you submit it, you own it.
Twenty years ago, Dries was a bedroom inventor who collapsed from stress on a street in Belgium. He had a choice: take a safe job, walk away from the thing he'd built, or ask for help and become a deliberate leader.
He made the harder choice. The community that grew up around that choice is why Drupal is still here, still relevant, still running critical infrastructure for organisations around the world.
Now there's another crossroads. AI is both the flood and the drainage system. It destabilises the foundations and it can help rebuild them stronger.
Twenty-five years of Drupal is twenty-five years of expertise built patch by patch, merge request by merge request. A community that showed up not because it had to, but because it cared. That's not a liability in the age of AI. That's exactly what this moment needs.
DrupalCon Chicago runs through this week. The marketplace is live at marketplace.drupal.org. The Context Control Centre is approaching production. The Drupal AI initiative is moving fast.
Great digital experiences don't happen by accident, they're built with intention, inclusion, and users at the heart of every decision. At DrupalCon Rotterdam 2026, the UX, Accessibility and Usability track is bringing together designers, developers, content strategists, and decision-makers to explore how Drupal powers truly user-centred digital products.
We're looking for speakers with real stories to tell. Whether you've transformed an accessibility audit into lasting organisational change, built a design system that scaled beautifully across channels, or used user research to completely reshape a development roadmap — we want to hear from you.
Foto by Matthew Saunders
We're particularly interested in sessions covering:
· Accessibility beyond compliance - embedding WCAG and ATAG into everyday workflows
· User research that drives real development decisions
· Design systems and collaborative design-development workflows
· Usability improvements backed by evidence and data
· Content design and strategy, including practical uses of AI
· Digital sustainability - designing for efficiency and longevity
This track is for anyone who believes that inclusion, usability, and good design aren't nice-to-haves — they're essential. Whether you're sharing a case study, a practical toolkit, or a freshperspective, your session could help Drupal practitioners everywhere build better, more inclusive digital experiences.
Submissions close 13 April.
Submmit your session: https://events.drupal.org/rotterdam2026/program-glance
Don't wait! Share your expertise and help shape the conversation at DrupalCon Rotterdam 2026.
When making code changes or fixing issues, it's easy to leave @todo comments behind. Sometimes they mark areas waiting on an upstream fix, sometimes they're reminders that never got revisited. Either way, they accumulate — and the ones tied to the specific issue you're working on should be resolved before the MR merges.
phpstan-drupal 2.0.12 adds TodoCommentWithIssueUrlRule to catch this in the GitLab CI jobs on Drupal.org.
This rule is inspired by staabm/phpstan-todo-by, which handles expiring todos by date, version constraint, and issue tracker status. It doesn't currently support custom issue fetchers or alternative detection mechanisms, such as matching ticket IDs to branch names — but that flexibility could make its way there someday.
As autonomous agents increasingly interact with technical documentation, traditional HTML can introduce challenges by filling limited context windows with layout elements, navigation, and scripts. This structural cluttering not only drains computing resources but directly causes context pollution and AI hallucinations.
Discover how you can reduce this “token tax” and create cleaner, more AI-friendly documentation experiences.
read moreWhen I wrote my last post one year and one day ago, “vibe coding” was new. In fact, I heard about it for the first time while walking to some DrupalCon Atlanta social event — Bálint and Lauri were talking about it after a long conference day. By the end of 2025, it was in the dictionary. Three months into 2026 and it’s everywhere — for better or worse.1
Also at the end of 2025, Bálint did a very impressive demo for the Canvas team: AI tools that knew nothing about Canvas were able to successfully generate Canvas code components. During his demo he called out something unexpected (for 2024 Wim): the demo worked with minimal prompting thanks to Canvas’ code components’ detailed validation. 😮
How did we get here?!
I started advocating for validating Drupal’s configuration in 2022–2023. I argued Drupal’s config (schema) system was powerful but unreliable, that we should add validation to Drupal core’s config entity types.
The intended use cases for config validation that I mentioned in my DrupalCon talks: make Recipes reliable, allow decoupled admin UIs, make writing config via JSON:API a reality, improve automatic updates’ reliability and increase the reliability of Drupal deployments (especially ones doing advanced things with config management).
In my assessment, superficial config validation was a risk for the Drupal ecosystem. Thorough (or often any) config validation would enable more use cases, and would allow the entire ecosystem to move faster and with more confidence — end users, developers, Drupal businesses but also automated tools such as scripts.
Not on my bingo card in 2023: AI.
Later I found myself to be the (back-end) tech lead for Drupal Canvas. Product Manager Lauri had made it a clear requirement that all existing Drupal best practices for config management/syncing should result in perfectly reliable syncs when it comes to Canvas’ config entities. Hence aiming for thorough validation2 was one of the few crystal-clear things when we started Canvas.
Canvas’ config is 100% validatable, has thorough test coverage and detailed config schema, with many custom validation constraints.
The thinking:
The result is a quote of the inimitable phènaproxima3:
Canvas is the most goddamn validated piece of code in all of Drupal
Back to Bálint’s demo of ~3 months ago. In his demo, the human doesn’t need to keep re-prompting the AI to try changing X or Y for things to work: Canvas’ validation errors tell the AI, so the human doesn’t need to deal with mundane details!
The same reasons that reduce human frustration are also the ones that accelerate the use of AI tools. Humans benefit hugely, but as a bonus, LLMs can use the same precise guidance with actionable validation error messages (strictness alone is not enough); bringing not only more reliable results, but also less energy waste and faster results.4
Conclusion: the value of precise validation has multiplied. It now also guides AI/LLMs to generate something valid. Investment in validation now pays off multiple times. For some, “important because it enables AI” may be the most convincing argument.
Dries wrote about how AI flattens [user] interfaces. To use the terminology in his post: validation is something that supports both the visible and invisible layers! Without it, both humans and AIs need to either guess/retry or become experts in the underlying code.
Thanks to Bálint for reviewing this.
0% written by AI.
I bet you were thinking about that em-dash. “Did he write that using AI?” Proper typography is now an AI tell!
For those of you working on the Canvas codebase, I bet you’d use the word “impose” 🙈
Must be read whilst waving fist.
Ethical concerns are still present and unresolved. Economic realities sadly are unfortunately no longer a future concern, but a present one.
Today we are talking about the open data platform DKAN, what it's used for, and how it applies to Drupal with guests Liz Tupper & Dan Feder. We'll also cover Modern Drupal Dashboard as our module of the week.
For show notes visit: https://www.talkingDrupal.com/545
TopicsLiz Tupper - civicactions.com etupper Dan Feder - getdkan.org dafeder
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Steve Wirt - civicactions.com Swirt
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
Our release schedule includes three potential release dates for Drupal 12.0.0, depending on when critical requirements are completed:
Many great improvements landed recently. The main branch is on Symfony 8 and most deprecated modules are removed already. With only a few days remaining until the March deadline of the first release option though, we are confident that not all critical requirements will be completed by March 27. Therefore, we are officially announcing that our new target release date for Drupal 12.0.0 is August 10, 2026, and the beta deadline for critical requirements is May 15, 2026.
While there are other pending improvements that are not hard requirements for Drupal 12's release, these are the most urgent needs:
While our ultimate goal is to support PHPUnit 13 in Drupal 12, there are significant API changes in PHPUnit 12 that we first need to adopt. See #3527936: Introduce support for PHPUnit 12
CKEditor 5 is changing their installation method in the near future. See #3527914: [PP-1] Use New installation methods for CKEditor5
To support this, we need a JavaScript import maps API in core. See #3398525: Add an API for importmaps
To test update paths from Drupal 11.3.0, we need to generate new database dumps. See #3569127: Add new 11.3.x database dump fixtures, without modules deprecated for removal in 12.x
Remove older upgrade paths. See #3580877: [PP-1] Remove updates added prior to 11.3.0 from 12.x
To reduce the size of core, we are excluding tests from core release packages, and offering them via a different namespace. This is a disruptive change and should only be done in a major release.
See #3067979: Exclude test files from release packages.
The Toolbar Module needs to be removed from core now that the Navigation module is stable and in the standard profile. See #3484850: [PP-1] [meta] Deprecate Toolbar module
There are more dependencies, modules and themes that are still possible to remove. See #3466088: [meta] Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 12 core
Gin is in core as an alpha experimental extension. Help make it stable and so it can replace Claro.
See #3576488: [meta] Admin theme: path to stable.
The coding standard checks are using the unsupported ESLint 8. We need to update to version 9. See #3440225: Update to ESLint v9 with standard rules.
See #3440225: Update to ESLint v9 with standard rules.
The above list are the current highest priorities. We'll keep identifying and tagging Drupal 12 release priority issues. The up to date list can be found using the Drupal 12.0.0 release priority tag.
Our release schedule includes three potential release dates for Drupal 12.0.0, depending on when critical requirements are completed:
Many great improvements landed recently. The main branch is on Symfony 8 and most deprecated modules are removed already. With only a few days remaining until the March deadline of the first release option though, we are confident that not all critical requirements will be completed by March 27. Therefore, we are officially announcing that our new target release date for Drupal 12.0.0 is August 10, 2026, and the beta deadline for critical requirements is May 15, 2026.
While there are other pending improvements that are not hard requirements for Drupal 12's release, these are the most urgent needs:
While our ultimate goal is to support PHPUnit 13 in Drupal 12, there are significant API changes in PHPUnit 12 that we first need to adopt. See #3527936: Introduce support for PHPUnit 12
CKEditor 5 is changing their installation method in the near future. See #3527914: [PP-1] Use New installation methods for CKEditor5
To support this, we need a JavaScript import maps API in core. See #3398525: Add an API for importmaps
To test update paths from Drupal 11.3.0, we need to generate new database dumps. See #3569127: Add new 11.3.x database dump fixtures, without modules deprecated for removal in 12.x
Remove older upgrade paths. See #3580877: [PP-1] Remove updates added prior to 11.3.0 from 12.x
To reduce the size of core, we are excluding tests from core release packages, and offering them via a different namespace. This is a disruptive change and should only be done in a major release.
See #3067979: Exclude test files from release packages.
The Toolbar Module needs to be removed from core now that the Navigation module is stable and in the standard profile. See #3484850: [PP-1] [meta] Deprecate Toolbar module
There are more dependencies, modules and themes that are still possible to remove. See #3466088: [meta] Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 12 core
Gin is in core as an alpha experimental extension. Help make it stable and so it can replace Claro.
See #3576488: [meta] Admin theme: path to stable.
The coding standard checks are using the unsupported ESLint 8. We need to update to version 9. See #3440225: Update to ESLint v9 with standard rules.
See #3440225: Update to ESLint v9 with standard rules.
The above list are the current highest priorities. We'll keep identifying and tagging Drupal 12 release priority issues. The up to date list can be found using the Drupal 12.0.0 release priority tag.
DrupalCon Chicago 2026 has begun, bringing together the global Drupal community from March 23 to 26 at the Hilton Chicago. As the event kicks off, attention is turning to the sessions scheduled over the coming days, many of which focus on accessibility, inclusion, and how Drupal teams are responding to evolving real-world requirements.
In the lead-up to the event, The DropTimes published a series of articles previewing selected sessions from the program. These included Palak Agarwal’s coverage of accessibility audits on Drupal websites, highlighting recurring issues such as missing alt text, poor contrast, and structural inconsistencies that continue to affect many Drupal projects.
Among the upcoming sessions is “Future-Proofing Accessibility: Strategies for Government & University Platforms,” featuring M. Nikki Flores, Javier Reartes, and Kat Shaw, scheduled for March 24. The session will focus on moving accessibility earlier into the workflow, drawing from large-scale public sector and university implementations.
Another session featured in our coverage, “Designing for Difference: Practical Strategies for Building a Neuroinclusive Organization” by J. Matthew Saunders, will explore how workplace systems can be redesigned to reduce friction and support neurodivergent teams.
As DrupalCon Chicago gets underway, these sessions point to the conversations that will shape the week ahead. The focus is not only on what Drupal can do, but how it can be built and used in ways that are more accessible, inclusive, and effective in practice.
Additional developments from across the Drupal ecosystem were published during the week. Readers may follow The DropTimes on LinkedIn, Twitter, Bluesky, and Facebook for continuing updates. The publication also maintains a presence on Drupal Slack in the #thedroptimes channel.
Thank you.
Alka Elizabeth
Sub-editor
The DropTimes
Links help shape the experience of discovery: they are like little portals that transfer readers to a different place on the web with a single click. For search engines, they act more like pathways that reveal how your content connects to everything else. The practical importance of both internal and external links deserves special coverage, which we’ll explore in this post.
read moreCome Monday, March 23rd, for a day devoted to Drupal in healthcare— a relaxed and friendly opening to DrupalCon with information-packed presentations plus two "table talk" sessions which will give everybody a chance to dive deeply into key topics, including privacy and overall takeaways. Whether you are in a state department of health, a non-profit hospital, a public health organization, or anyplace else in the broad healthcare space, there are unique needs in ensuring security, accessibility, compliance, and availability of important information and tools.
Online communication and emerging technologies promise improved access and capabilities for patients and professionals. Useful and inspiring digital experiences, however, must be built on a foundation of privacy, accessibility, and legal compliance. Come listen to healthcare technology practitioners share their experience solving these and more challenges in healthcare.
Get tickets to go to DrupalCon and the Healthcare Summit!
Ticket includes lunch, and we will be all wrapped up by 4pm.
Everybody interested in hearing and discussing how companies and the community are creating rich digital experiences in the healthcare space. All levels of colleagues in the pharma, medical, clinical, hospital, payers, caregivers, advocates, and healthcare professional space should go to DrupalCon and the Healthcare Summit!
Bring your needs to the table talks and we will embark on facilitated peer-to-peer problem solving with others who are affected and tech and healthcare industry experts.
We will have a sensor in the room to monitor CO₂ levels and if they remain between at 800–1000 ppm.
Agaric will also have high-quality N95 masks available to anyone who wants them, and may bring our own MERV-13 Corsi-Rosenthal box fan filter, which provides appropriate filtration for reducing the spread COVID-19.
The Healthcare Industry Summit brings together professionals and innovators to explore how Drupal can drive impact in healthcare. Through expert-led sessions, you’ll gain insights into topics such as the responsible use of AI, personalization, content marketing, and streamlining migrations.
In addition to presentations, roundtable discussions will provide opportunities to share experiences, exchange ideas, and build connections with peers tackling similar challenges. Join us to discover innovative approaches and collaborative strategies that are shaping the future of healthcare with Drupal.
The Healthcare Summit at the 2025 Chicago, Illinois, DrupalCon is organized by Jeanne Cost, Laura Chaparro, and myself. I am glad to be playing a part in coordinating this summit, especially given Agaric's involvement in and commitment to health and science communities.
Read more and discuss at agaric.coop.
read moreCreating some rules for my playground
I'm setting up my Drupal Playground to experiment with AI coding agents. My previous post was about using Claude Code to establish a Drupal environment, and it felt a bit like crawling, but now I am ready to pick up the pace.
I've experimented and found that, in addition to sending effective code-generation prompts to an AI, providing metadata about the targeted codebase is equally important. The standard way to give this context is AGENTS.md. My initial experiments with Amazee.io's AGENTS.md produced much better results with PHPStorm's Junie. I'm inclined to think that Drupal core should include an AGENTS.md file or template.
Meanwhile, I've been experimenting with Claude's Chat UI without any context beyond knowing I am a Drupal developer. Despite this, Claude, with no background information, shows an impressive understanding of Drupal's API and developer workflow. For example, Claude can plan and develop an entire module, including automated tests. I look forward to seeing Claude attempt to build a Telephone Filter module, based on the one I created with ChatGPT a year ago. For now, I plan to continue setting up my environment to give Claude Code the necessary context to produce the most reliable results.
Adding context via CLAUDE.md (aka AGENTS.md)
Currently, Claude Code uses CLAUDE.md files for context, but it will likely support AGENTS.md. In short, CLAUDE.md and AGENTS.md are the same. I haven't extensively experimented with other AIs yet, but the fact that Claude Code has an...Read More
read moreIf you study computer science or web development, you’ll take an introductory JavaScript course. Everyone starts in a similar place: variables, let and const (or var if you’re old enough), maybe even a conversation about the difference. You write a few functions, do some math, and concatenate some strings. It feels like learning a language in the abstract — technically correct, but removed from real work.
Before long, you are manipulating a web page. You grab an element, change its content, add a class, and attach a click handler. The browser responds. The page changes. It finally feels tangible.
But even then, JavaScript can feel like a layer you add on top rather than the foundation of the experience itself. And almost inevitably, you move to a library or framework. For many of us, that once meant jQuery.
jQuery did not become dominant because developers were lazy. It solved real problems. Browsers were fragmented. There was no consistent way to select elements from the DOM. Event handling varied. AJAX required wrestling with verbose XMLHttpRequest code and awkward callback patterns. jQuery unified those concerns behind a clean, approachable interface: the dollar sign selector, the on method, simple get and post helpers, animations like fadeIn and slideUp.
It was a necessary abstraction at the time.
Over the years, though, the platform evolved. Browsers standardized. APIs matured. ES6 modernized the language. CSS grew far more capable. Many of the problems jQuery once addressed were absorbed directly into the browser.
The platform changed.
We may be living through a similar moment with modern frameworks. React and other tools solve meaningful problems. They help teams move quickly and provide structure, especially for developers early in their careers. In many cases, they are exactly the right choice.
But over time, thoughtful decisions can quietly become defaults. A subtle assumption can creep in: if something feels modern or interactive, it probably requires a framework.
The shift is not dramatic. It is behavioral. Instead of beginning with the problem, we sometimes begin with the stack. If an interaction feels dynamic or app-like, we assume it needs something larger.
Frameworks offer guardrails and shared patterns, and that consistency is valuable. But when the tool becomes the starting point for every conversation, it can narrow the range of options we consider. We stop asking what the browser already provides. We begin to treat complexity as the baseline for modern work.
This is not bad architecture.It is often just unexamined architecture.
It shows up in small ways: adding a dependency before exploring a native API, reaching for a heavy client-side solution when progressive enhancement might be enough, and introducing new tooling because that is what modern projects tend to do. Each decision is understandable on its own. Over time, though, they expand the surface area of a project: more dependencies, more upgrades, more maintenance. Fewer dependencies can mean fewer upgrades to manage, fewer compatibility conflicts, and a smaller maintenance surface over time.
While we have been refining our build pipelines and debating frameworks, the browser has continued to evolve. Quietly and steadily. Modern JavaScript is not what it was 10 or even five years ago. Today’s browsers ship with stable, well-documented APIs that address many of the use cases we once handled with libraries.
Need to know when something enters the viewport? There is Intersection Observer.
Need to react to changes in the DOM without polling? Mutation Observer is built in.
Need to respond to screen size changes? MatchMedia handles that cleanly.
Need to persist data between sessions? Local storage is there.
Need to integrate with a device’s native share dialog? There is an API for that.
CSS has evolved as well. Layout systems, transitions, scroll behaviors, and positioning features eliminate entire categories of JavaScript we once considered unavoidable.
And the language itself has matured. Modules, promises, async and await, richer array methods, cleaner syntax. These are no longer experimental features. They are part of the platform.
None of this is particularly flashy. It is simply what the browser now provides.
The important point is not that every project should avoid frameworks. It is that many of the problems we once solved with external libraries now have first-class support in the browser itself. So, what does that mean in practice?
Add one small pause to your workflow. Before installing a dependency, check the platform. Search MDN. Look up “browser API for…” and see what comes back. You might discover that Intersection Observer replaces the scroll library you were about to add. Or that CSS handles the animation without JavaScript at all.
It means reframing how you evaluate tradeoffs. When a feature request comes in, write down the requirement in plain language before you write down the stack. What actually needs to happen? A modal opens. Content animates on scroll. State persists between visits. Once the behavior is clear, ask whether the browser can already do it.
It means keeping a short list of native capabilities in your mental toolkit: MatchMedia. Local storage. Native form validation. ResizeObserver. The goal is not to memorize every API. It is important to remember that vanilla JavaScript is an option.
It also means normalizing this conversation on your team. When someone suggests a new library, ask a simple question: is there a native way to do this? Not as a challenge. As due diligence.
None of this requires abandoning modern tooling. It simply widens your decision tree. And it costs almost nothing but attention.
In our session, “Elevating Drupal Experiences with Vanilla JavaScript,” we’ll share how we’ve used modern browser capabilities to build rich, interactive experiences within Drupal — not by rejecting frameworks, but by pairing Drupal’s strengths with what the browser already does well.
We’ll walk through:
More than anything, we hope it sparks a conversation.
If you’re going to DrupalCon Chicago 2026, please make sure to attend the session with Mari and Andrés.
Where: Hilton Chicago, 720 S. Michigan Ave., Chicago, IL 60605, Salon A-2 (LL)
When: Tuesday, March 24, 2026, 4:10–5:00pm
The post The browser has grown up. Have we? appeared first on Four Kitchens.
read moreModule Builder now has its own documentation site.
This covers the many options it offers developers for fine-tuning their module code, from dependency injection to plugin inheritance, entity base fields, form elements, permissions, library asset files, and more.
Meanwhile, the latest release of Module Builder adds a feature I've wanted to implement for a very long time: when a new form section is added to add a new component (such as a plugin, hook class, or entity type), the form scrolls up to the new section that's just been added with AJAX. This makes it much clearer to understand what's just been changed, and helps with navigating around Module Builder's forms.
I needed to test a Drupal module I was working on in a Docker container. The code was not in a location accessible to Docker. I tried to use Composer to copy it over. This would have worked if the code contained a composer.json file. I could have used a Composer path repository with symlink set to false. But it did not contain a composer.json file, so I had to use a Composer package repository. Composer kept symlinking instead of copying.
Join us THURSDAY, March 19 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)
We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!
All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.
This free call is sponsored by NTEN.org and open to everyone.
Information on joining the meeting can be found in our collaborative Google document.
Join us THURSDAY, March 19 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)
We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!
All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.
This free call is sponsored by NTEN.org and open to everyone.
Information on joining the meeting can be found in our collaborative Google document.
At Tag1, we believe in proving AI within our own work before recommending it to clients. This post is part of our AI Applied content series, where team members share real stories of how they're using Artificial Intelligence and the insights and lessons they learn along the way. Here, Stefanos Petrakis, maintainer of the File Upload Secure Validator module, shows how he used AI to modernize a small but widely used Drupal security module and prepare it for Drupal 12.
I’ve been meaning to clean up the File Upload Secure Validator project and get it ready for Drupal 12 for a while now. This small, focused module has been around for nearly a decade. Despite its simplicity, it continues to serve more than 10,000 reported sites, and adoption has only accelerated with the introduction of Drupal AI. With the help of Cline and Claude, I finally did a full overhaul of the codebase: switching to Drupal 11-only support, expanding the automated test suite, and positioning the project for Drupal 12.
This was the kind of maintenance work I kept putting off, the same feeling I get when I need to sit down and do my taxes. I knew the project needed cleanup and modernization, but I wanted a little push and some company in doing the work. The missing motivation and sense of camaraderie were, in many ways, the biggest challenges.
On top of that, I had a clear vision for how I wanted to extend the test suite, and I knew it would be time-consuming. Time, or the lack of it, was a major factor, especially for this kind of detailed, behind-the-scenes work on an open source module.
To move things forward, I turned to Cline and Claude to help plan the future of the module. I started by writing down a list of "wishes" for the project: the improvements I wanted to see in the code, tests, and overall quality.
Cline turned that list into a detailed execution plan. It also generated questions about the approach, which led us into a few iterations before we settled on the final course of action. That planning process gave structure to the work and made it much easier to tackle in focused sessions.
All of the changes happened in the project's repository on the 2.2.x branch, with the final result released as version 2.2.1 on Drupal.org.
Before this overhaul, the project had accumulated a number of issues:
TranslatableMarkup issues)After the overhaul, the picture looks very different:
This overhaul gave me the "manpower" and momentum I was missing to push the project forward. Just as importantly, it gave me confidence that I can continue supporting this module in the future.
Maintaining and supporting open source libraries can often become demanding because of limited time and resources. In client projects, dependencies on under-maintained open source projects can increase the effort required to maintain or upgrade the client's own platform.
Partners like Cline and Claude can change the game in an advantageous way. Such a change can help teams keep critical open source dependencies up to date, improve quality, and reduce risk without requiring a huge amount of extra human capacity.
This post is part of Tag1’s AI Applied content series, where we share how we're using AI inside our own work before bringing it to clients. Our goal is to be transparent about what works, what doesn’t, and what we are still figuring out, so that together, we can build a more practical, responsible path for AI adoption.
Bring practical, proven AI adoption strategies to your organization, let's start a conversation! We'd love to hear from you.
read moreA dashboard isn’t just a summary page. It’s a statement of priorities. Every item that appears, and everything that doesn’t, tells editors what the organization believes actually matters.
That’s worth thinking carefully about, because most dashboards aren’t designed that way. They’re assembled. A few shortcuts here, some default widgets there. The result is a starting screen that reflects what was easy to build rather than what editors actually need.
We help manage a Drupal platform that supports 500 editors across 130 sites. Getting a dashboard right for that kind of scale required us to ask some uncomfortable questions about what we actually valued, and what we’d been ignoring.
Before we built our dashboard, someone on our platform team was manually generating reports for each of the 130 sites every quarter. Accessibility problems. Broken links. Duplicate content. All compiled, formatted, and sent out as a PDF.
It was better than nothing. But it had two serious problems.
First, people were unlikely to act on it. A PDF that arrives by email, detached from the website itself, is easy to file away and forget. Second, even the editors who did read it had no way of knowing whether they were improving until the next quarter’s report showed up. The feedback loop was three months long.
This is a pattern that’s common across organizations: the information that would most help editors do better work exists somewhere, but it’s separated from the moment when they’re actually ready to act on it. Updates get coordinated in chat threads. Content issues arrive by email. Broken link reports live in spreadsheets.
Editors are expected to carry all of that context across multiple tools and respond when something surfaces. For people whose primary job isn’t web publishing, that’s a lot to ask.
A dashboard brings that context back into the CMS, the place where the work actually happens.
Editors don’t log into a CMS at random. They arrive with a purpose: fixing a typo, publishing a new story, or checking whether a content import ran correctly. Whatever the task, they’re already in the right mindset. They’re thinking about the website and are ready to make changes.
That makes login the ideal moment to surface what needs attention.
On our dashboard, we highlight the pages with the most accessibility errors. We show a list of broken links. We surface draft content that never got published. These aren’t things editors have to go hunting for. They appear right when editors are ready to do something about them.
We also use the dashboard to answer questions editors commonly ask us. One recurring one: how does content get into the site from other university systems? Faculty profiles, events, and course data. All of it comes in through automated imports. Drupal has robust tools for this, but its default interface exposes every option and setting, which is overwhelming for a content editor. So we’d never exposed it to them at all. Editors had no visibility into something that was working fine. They just didn’t know it.
The dashboard gave us a place to show a simplified view of those imports: here’s when faculty profiles last synced, here’s the kinds of courses that are imported to this site. Just enough to answer the question and build confidence. Support requests about content imports dropped significantly after we added that.
Information alone doesn’t change much. The problem usually isn’t awareness. It’s timing.
When a broken link shows up in a quarterly report, the path from seeing it to fixing it is long and uncertain. Someone reads the report, makes a mental note, hopes they remember. Most of the time, they don’t. By integrating that same information into the dashboard, the cycle changes:
Quarterly report → read → maybe remember → maybe act later
becomes
Login → see issue → click → fix
The feedback loop collapses from months to minutes. A broken link becomes a clickable item. A page stuck in draft becomes a quick decision. A list of accessibility errors becomes something an editor can start working through today.
One practical note from experience: some data sources introduce delays. Our broken link list comes from Siteimprove via API, which means that when an editor fixes a broken link, it won’t disappear from the dashboard immediately. We didn’t think about that until after we launched. It’s not a dealbreaker, but it’s worth designing around. At minimum, set expectations with editors so a fixed link that still appears on the list doesn’t feel like a bug.
Dashboards aren’t neutral. They’re curated.
Every item that appears is there because someone, explicitly or quietly, decided it mattered. Looking at our current dashboard, I can tell you what it says about our priorities: we value accessible content (pages with the most accessibility errors are one of the most prominent blocks), and we value simplicity and iteration over comprehensiveness.
What’s not on the dashboard is equally revealing. We don’t have traffic metrics or analytics. For this particular higher ed institution, that’s a deliberate choice. The focus is on content quality and editor success, not marketing outcomes. For other clients we work with, traffic data would need to be front and center. The dashboard has to reflect what that organization actually cares about.
The conversations that happen while building a dashboard are often more valuable than the dashboard itself. When you ask your team what should appear on it, you surface competing priorities that usually haven’t been written down anywhere:
Those questions don’t always have obvious answers. But asking them is how you build something useful rather than something that just looks like a dashboard.
And don’t let perfect be the enemy of good. Our first dashboard was basic: simple tables, in a single column, nothing animated or interactive. If you get a dozen useful things on a dashboard, the organization as a whole is going to be better for it. Start there, then build up.
There’s a real risk that a dashboard drifts into feeling like a compliance tool, a place that exists primarily to point out what’s wrong. If the only things editors see when they log in are warnings and error counts, the dashboard starts to feel like surveillance.
The same information can be framed very differently. A list of pages with accessibility errors isn’t a punishment; it’s a prioritized to-do list. A reminder about draft content that was never published helps an editor finish work that might otherwise be abandoned. A note that a component has recently changed gives editors a heads-up to check their pages before finding out something looks broken.
That last one is something we’ve gotten real value from. Our platform has 130 sites, which means making a breaking change to a component has a wide impact. Before we had the dashboard, that kind of communication was difficult. We still do targeted communications about breaking changes. But now we also use a simple announcements block (it pulls from a Google spreadsheet where each row is an announcement) to reach editors right where they’re working. It’s low-tech, but it means we can flag an upcoming change and tell editors exactly what to check. That’s made us more comfortable shipping improvements we might otherwise have sat on.
The goal isn’t to catch mistakes. It’s to help editors succeed.
When your platform supports hundreds of editors across dozens of sites, traditional support breaks down fast. You can’t train everyone personally. You can’t answer every Slack message. And the editors who log in only a few times a year don’t have the context that frequent users build up over time.
The platform itself has to take on more of that responsibility.
One thing that helped clarify our thinking: on the back end, your audience is actually more focused than it might seem. On the front end of a university website, you’re trying to serve prospective students, current students, faculty, staff, donors, and more. But in the CMS, your primary audience is your content editors. There might be a few other users (stakeholders who log in occasionally to get a lay of the land, or interns assigned to clean up a single page), but by and large, you’re designing for a pretty clear group.
For us, that meant focusing our first version on the editors who log in regularly and need to take action. We can add more guidance for infrequent users in later iterations. Starting with the core use case meant we shipped something useful without trying to solve everything at once.
A well-designed dashboard becomes a quiet guide embedded in the platform, helping editors move forward without needing someone from the platform team to step in. At scale, that kind of built-in guidance isn’t just helpful. It’s essential.
In our session, “A Dashboard that Works: Giving Editors What They Want, But Focusing on What They Need,” we’ll share the story behind a dashboard built for 500 editors across 130 sites — the decisions we made, the things we got wrong, and how we figured out what actually belongs on a dashboard and what doesn’t.
We’ll walk through:
Whether you manage one site or one hundred, we hope you leave with something you can use.
If you’re going to DrupalCon Chicago 2026, please make sure to attend the session with Dave Hansen-Lange and Albert Hughes.
Where: Hilton Chicago, 720 S Michigan Ave, Chicago, IL 60605, Williford B (3rd Floor)
When: Tuesday, March 24, 2026, 9:00–9:50am
The post When the people who run the platform aren’t the people who run the content appeared first on Four Kitchens.
read moreAuthors: Will Huggins, Jeremy Chinquist
Drupal AI 1.3.0 is now available, delivering the largest feature update since the module's initial release. This version focuses on three areas that organisations told us matter most:
And because Drupal AI is open source, you stay in control of your models, your data, and your infrastructure.
Trust is the foundation of responsible AI adoption. Drupal AI 1.3.0 introduces AI Guardrails, configurable checks that run before or after any AI request.
Teams can define rules to control how AI interacts with their content and data. For example, they can block sensitive data from leaving their organisation, filter harmful responses, or enforce compliance policies. All of this can be configured without writing code.
Guardrails work across all AI operations in Drupal. This gives security and compliance teams a single place to oversee how AI is used across the site.
In practice, this means AI governance becomes part of the platform itself, rather than something teams must manage separately.
One-click AI for editors, right where they work
AI should meet editors in their workflow, not force them into a separate tool.
Drupal AI 1.3.0 introduces Field Widget Actions, one-click AI workflows attached directly to content fields.
Editors can now:
Each action is backed by a customisable workflow allowing site builders to tailor AI behaviour to their organisation’s needs and editorial standards without writing code.
Editors often need quick assistance while working on content. The built-in Drupal AI chatbot has been expanded to support this directly within the editing experience.
Open the chatbot via slide-in or full-screen mode, allowing the editor to choose the interface that best fits their workflow.
The chatbot receives page context, meaning it understands the content currently being viewed or edited.
Editors can ask questions such as:
Because the chatbot receives the current page context, its responses relate directly to the content on the screen.
Custom loading messages replace generic spinners, allowing site builders to provide clearer feedback while AI requests are processed.
As organisations begin building AI-powered features in Drupal, developers need tools that simplify configuration and reduce boilerplate.
Drupal AI 1.3.0 includes a set of reusable form elements designed specifically for AI workflows.
These components provide consistent interfaces for working with AI providers, prompts, and structured outputs.
The new elements include:
Configuration files have also been improved. Prompts are stored in a human-readable format rather than single-line strings, making code reviews easier and reducing merge conflicts when teams collaborate on AI workflows.
Drupal AI’s provider-agnostic architecture continues to expand with three additional operation types.
Rerank reorders search results or document lists based on relevance to a query. This is particularly useful in retrieval-augmented generation workflows.
Summarize uses lightweight summarization models instead of full language models, reducing cost and processing time.
Object Detection identifies objects in images using traditional machine learning models. The AI Validations module already uses this to verify image content automatically.
All operation types work with compatible providers, allowing organisations to change models without rewriting integration code.
Running AI in production requires visibility into how systems behave. Drupal AI’s observability module exports spans, traces, and metrics through OpenTelemetry, the industry standard for application monitoring.
Teams are able to connect this data to platforms such as Datadog, Grafana, Sentry, or any OpenTelemetry-compatible system.
This allows engineering teams to monitor AI agent decisions, track usage and cost, and audit AI interactions across their sites.
Combined with the exclude-tags feature for logging, organisations also gain fine-grained control over what information is recorded and what remains private.
Drupal AI 1.3.0 also simplifies parts of the platform.
AI Translate gives way to TMGMT (Translation Management Tool), aligning AI-assisted translation with Drupal’s standard translation workflow.
Field Widget Actions now provide a flexible framework for AI-assisted editorial tasks. AI Content Suggestions remains available as a contrib module for teams that want to continue building on that approach.
AI Validations will use the Object Detection operation type going forward, while still allowing different validation modules to build on the same abstraction.
These changes simplify the core architecture while leaving room for contrib modules and alternative implementations.
AI in a CMS brings practical challenges around governance, editorial workflows, and production visibility.
Drupal AI 1.3.0 shows that these problems can be handled directly within Drupal.
AI can be governed, integrated into everyday publishing workflows, and monitored in production as part of the platform.
Drupal AI remains open source and provider-agnostic, allowing organisations to integrate AI capabilities while maintaining control over their infrastructure, data, and model choices.
This post highlights the major additions. For the complete list of changes, bug fixes, and improvements in 1.3.0, see the full release notes on drupal.org.
Every year, the global campaign organised by the Union for International Cancer Control invites people affected by cancer to share their personal experiences as part of World Cancer Day. These stories provide an important human perspective on the realities of cancer. They help build solidarity, encourage early diagnosis, and ensure the voices of patients, survivors, families and carers are heard around the world.
However, when a global campaign encourages participation at scale, the practical challenges quickly become clear. Hundreds of deeply personal stories can arrive from many different countries in a short period of time. Each submission needs to be reviewed carefully, handled with sensitivity, and prepared for publication. For a small team responsible for managing the campaign, this can create significant pressure during the peak period around World Cancer Day.
To address this challenge, the World Cancer Day team partnered with 1xINTERNET to explore how artificial intelligence could support their existing editorial workflow within Drupal.
Rather than attempting to automate the process entirely, the approach focused on supporting human decision making. AI was introduced to assist moderators by helping them review incoming submissions more efficiently. This allowed the team to process stories more quickly while ensuring that personal experiences remained at the centre of the review process.
The result is a practical example of how AI can be applied responsibly. Technology is used to assist people rather than replace them, helping organisations manage growing volumes of content while maintaining appropriate oversight and care.
In this upcoming webinar we will explore the approach taken by the World Cancer Day team and the lessons it offers for other organisations facing similar challenges.
Participants will hear about:
The session is designed for organisational leaders, communications teams, and others exploring how artificial intelligence can be introduced in a considered and practical way. Using a real global campaign as its foundation, it offers a practical example of how AI can support teams managing large volumes of user generated content.
Title: Helping people tell their cancer stories using AI: Lessons from World Cancer Day
Date: 16 March 2026
Time: 2:00 PM GMT*
Format: Live webinar
Register now to secure your place.
*If the timing is not convenient, the session will be recorded and shared with everyone who registers so it can be watched afterwards.
Communications professional working on the World Cancer Day campaign at the Union for International Cancer Control (UICC). Charles leads global storytelling efforts that amplify the voices of people affected by cancer around the world.
Chief Operating Officer at 1xINTERNET. Diego works with organisations to design and deliver complex digital platforms using open-source technologies including Drupal.
AI Ambassador at amazee.io and long-time member of the Drupal community. Matthew works on initiatives that help organisations adopt AI in ways that respect privacy, transparency, and human decision-making.
This is part of a series of webinars and global events organised by Drupal AI. For full details visit our events calendar.
Written by guest blogger María Fernanda Silva
Something is shifting in how organizations think about AI. The early excitement around what it could do is giving way to a harder, more important question: how do you build AI that actually holds up — at scale, under pressure, and over time?
On 14 May 2026, New York City becomes the place where that question gets answered. The Drupal AI Summit brings together enterprise leaders, digital decision-makers, and senior practitioners from across the US and Europe — not to explore AI in theory, but to share what responsible, durable AI looks like in practice.
Thirteen focused sessions. Real case studies. The Summit is built around the strategic and organizational questions that determine whether AI delivers real value or stays stuck in pilot mode: governance, investment, long-term architecture, and what it actually takes to scale. If you are responsible for those decisions, this is where you belong.
Most AI implementations fail quietly — locked into black boxes, disconnected from the workflows where real work happens, impossible to adjust without starting over.
There is a different path. When AI is embedded directly into content, data, and workflow systems (where enterprise work actually happens), teams maintain transparency, organisations retain control, and the architecture evolves alongside the business without the cost of replatforming. This is not a niche concern. It speaks to every enterprise leader navigating AI in environments where trust, regulation, and scale are not optional considerations — they are the entire challenge.
The Summit explores what this looks like in practice, with sessions grounded in the architectural and organizational choices that make responsible AI adoption real, not just possible.
From 9:00 am to 5:45 pm at 360 Madison Avenue in the heart of Midtown Manhattan, you will have access to thirteen sessions built entirely around case studies from peers who are applying AI in production environments. No theoretical frameworks. No technical deep-dives. Just honest, grounded conversations about what works, what doesn't, and what it takes to build AI your organization can trust for the long term.
Practitioners and leaders are flying in from across the US and Europe to share first-hand experience and to learn from each other. Your pass also grants access to the wider apidays New York event running across both days, connecting you with communities exploring APIs, AI agents, cybersecurity, and modern digital infrastructure — all under the same roof.
Want to learn more? Explore our dedicated AI Summit New York City hub where you can learn more about the format, who the event is designed for. This will also be where the agenda is published once finalised in mid March.
Secure your place at the Drupal AI Summit NYC for $150 USD before 13 April 2026. After that, tickets are $200 USD.
The Paris edition sold out. If you're planning to join us in New York, early is the right call.
The foundations for enterprise-grade AI already exist. Come and see how they're being built — openly, responsibly, and together.
Secure your Early Bird ticket today!
Photos by Paul Johnson
If you’ve been following the rapid rise of AI‑driven chatbots and ‘assistant‑as‑a‑service’ platforms, you know one of the biggest pain points is trustworthy, privacy‑preserving web search. AI assistants need access to current information to be useful, yet traditional search engines track every query, building detailed user profiles.
Enter SearXNG - an open‑source metasearch engine that aggregates results from dozens of public search back‑ends while never storing personal data. The new Drupal module lets any Drupal‑based AI assistant (ChatGPT, LLM‑powered bots, custom agents) invoke SearXNG directly from the Drupal site, bringing privacy‑first searching in‑process with your content.
SearXNG aggregates results from up to 247 search services without tracking or profiling users. Unlike Google, Bing or other mainstream search engines, SearXNG removes private data from search requests and doesn't forward anything from third-party services.
Think of it as a privacy-preserving intermediary: your query goes to SearXNG, which then queries multiple search engines on your behalf and aggregates the results, all while keeping your identity completely anonymous.
The Drupal SearXNG module brings this privacy-focused search capability directly into the Drupal ecosystem. It connects Drupal with your preferred SearXNG server (local or remote), includes a demonstration block, and provides an additional submodule that integrates SearXNG with Drupal AI by offering an AI Agent Tool.
This integration is particularly powerful when combined with Drupal's growing AI ecosystem, including the AI module framework, AI Agents and AI Assistants API.
The most compelling benefit is complete privacy protection. When your Drupal AI assistant uses SearXNG to search the web:
This makes it ideal for organisations in healthcare, government, education and any sector where data privacy is paramount.
By aggregating results from up to 247 search services, SearXNG provides more diverse and comprehensive search results than relying on a single search engine. Your AI assistant gets a broader perspective, potentially finding information that might be missed by individual search engines.
Organisations can run their own SearXNG instance, giving them complete control over:
Getting started is remarkably straightforward thanks to SearXNG's official Docker image, which makes launching a local server as simple as running a single command. This means organisations can have their own private search instance running in minutes, without complex server configuration or dependencies.
The module's AI Agent Tool integration means that Drupal AI assistants can seamlessly incorporate web search into their workflows. Whether it's a chatbot helping users navigate your site or an AI assistant helping content creators research topics, web search becomes just another capability in the assistant's toolkit.
Imagine a corporate intranet where employees use an AI assistant to find both internal documentation and external resources. The assistant can search your internal Drupal content while using SearXNG to find external information, all while maintaining complete privacy about what employees are researching.
Universities and schools increasingly need to protect student privacy. A Drupal-powered learning management system with an AI tutor can use SearXNG to help students research topics without creating profiles of their academic interests and struggles.
Government organisations can leverage AI assistants to help citizens find information and services. Using SearXNG ensures that citizen queries remain private and aren't used for commercial purposes.
The SearXNG Drupal module represents an important step forward in building AI systems that respect user privacy. As AI assistants become more prevalent in web applications, the ability to access current information without compromising privacy will become increasingly valuable.
Drupal's AI framework supports over 48 AI platforms, providing flexibility in choosing AI providers. By combining this with privacy-respecting search through SearXNG, organisations can build powerful, intelligent applications that align with growing privacy expectations and regulations.
Privacy and powerful AI don't have to be mutually exclusive. The SearXNG Drupal module proves that organisations can build intelligent, helpful AI assistants that respect user privacy. Whether you're building internal tools, public-facing applications, or specialised platforms, this module provides a foundation for privacy-first AI that can search the web without compromising user trust.
As data privacy regulations continue to evolve and users become more aware of digital privacy issues, tools like the SearXNG module will become increasingly essential. By adopting privacy-first approaches now, organisations can build user trust while delivering the intelligent, helpful experiences that modern web applications demand.
Find out more and download on the dedicated SearXNG Drupal project page.
Join us THURSDAY, February 19 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)
We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!
All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.
This free call is sponsored by NTEN.org and open to everyone.
Information on joining the meeting can be found in our collaborative Google document.
While Artificial Intelligence is evolving rapidly, many applications remain experimental and difficult to implement in professional production environments. The Drupal AI Initiative addresses this directly, driving responsible AI innovation by channelling the community's creative energy into a clear, coordinated product vision for Drupal.
In this article, the third in a series, we highlight the outcomes of the latest development sprints of the Drupal AI Initiative. Part one outlines the 2026 roadmap presented by Dries Buytaert. Part two addresses the organisation and new working model for the delivery of AI functionality.
Authors: Arian, Christoph, Piyuesh, Rakhi (alphabetical)
Dries Buytaert presenting the status of Drupal AI Initiative at DrupalCon Vienna 2025
To turn the potential of AI into a reliable reality for the Drupal ecosystem, we have developed a repeatable, high-velocity production model that has already delivered significant results in its first four weeks.
To maximize efficiency and scale, development is organized into two closely collaborating workstreams. Together, they form a clear pipeline from exploration and prototyping to stable functionality:
This structure is powered by a Request for Proposal (RFP) model, sponsored by 28 organizations partnering with the Drupal AI Initiative.
The management of these workstreams is designed to rotate every six months via a new RFP process. Currently, 1xINTERNET provides the Product Owner for Product Development and QED42 provides the Product Owner for Innovation, while FreelyGive provides core technical architecture. This model ensures the initiative remains sustainable and neutral, while benefiting from the consistent professional expertise provided by the partners of the Drupal AI Initiative.
The professional delivery of the initiative is driven by our AI Partners, who provide the specialized resources required for implementation. To maintain high development velocity, we operate in two-week sprint iterations. This predictable cadence allows our partners to effectively plan their staff allocations and ensures consistent momentum.
The Product Owners for each workstream work closely with the AI Initiative Leadership to deliver on the one-year roadmap. They maintain well-prepared backlogs, ensuring that participating organizations can contribute where their specific technical strengths are most impactful.
By managing the complete development lifecycle, including software engineering, UX design, quality assurance, and peer reviews, the sprint teams ensure the delivery of stable and well-architected solutions that are ready for production environments.
The work of the AI Initiative provides important functionality to the recently launched Drupal CMS 2.0. This release represents one of the most significant evolutions in Drupal’s 25-year history, introducing Drupal Canvas and a suite of AI-powered tools within a visual-first platform designed for marketing teams and site builders alike.
The strategic cooperation between the Drupal AI Initiative and the Drupal CMS team ensures that our professional-grade AI framework delivers critical functionality while aligning with the goals of Drupal CMS.
The initial sprints demonstrate the high productivity of this dual-workstream approach, driven directly by the specialized staff of our partnering organizations. In the first two weeks, the sprint teams resolved 143 issues, creating significant momentum right from the first sprint.
Screenshot Drupal AI Dashboard
This surge of activity resulted in the largest regular patch release in the history of the Drupal AI module. This achievement was made possible by the intensive collaboration between several expert companies working in sync. Increased contribution from our partners will allow us to further accelerate development velocity, improving the capacity to deliver more advanced technical features in the coming months.
Screen recording Agents Debugger
While the volume of work is significant, some new features stand out. Here are a few highlights from our recent sprint reviews:
Our success so far is thanks to the companies who have stepped up as Drupal AI Partners. These organizations are leading the way in defining how AI and the Open Web intersect.
A huge thank you to our main contributors of the first two sprints (alphabetical order):
We invite further participation from the community. If your organization is interested in contributing expert resources to the forefront of AI development, we encourage you to join the initiative.