This post is adapted from the DA Insider, the Drupal Association's monthly newsletter. Subscribe here to get it in your inbox each month.
The Drupal Association team is incredibly grateful to have spent time with our community at DrupalCon Rotterdam. Dries Buytaert made one thing clear: Drupal is light-years ahead of its reputation. Our keynotes proved it, and stories from brands like Mars and World Cancer Day showcased Drupal's global power and ability to scale for good, both with cutting edge page building and AI integrations.
We were thrilled to celebrate our International Splash award winners, and the winners of the Women in Drupal award. It's our mission moving forward to expand our recognition for Makers, Patrons, and Advocates across the Drupal ecosystem, and to share Drupal's story beyond our own community.
Thank you to every attendee, speaker, sponsor, volunteer, and contributor who made Rotterdam absolutely unforgettable. We're excited to share what's next.
Tim Lehnen, CTO
This year's event welcomed 876 participants across 46 countries for four days of sessions, summits, workshops, and contribution activities at the Postillion Hotel & Convention Centre WTC Rotterdam.
The Driesnote was remarkable. Key highlights included the launch of the Drupal Advocacy Program, which awards contribution credit for writing, recording, and sharing about Drupal; the announcement of the Rosetta Sprint, aimed at making Drupal's capabilities readable by AI agents, systems, and humans alike; and a new public AI demo site showcasing Drupal's growing AI capabilities — watch the six demos here.
Dries also introduced the concept of Stewarded Open Source, positioning Drupal as the ideal platform for Europe's push for digital sovereignty. Read the full Driesnote recap here.
The International Splash Awards 2026 celebrated outstanding Drupal projects from across the globe, with a 40% increase in submissions this year. Congratulations to all the winners and runner-ups.
The Women in Drupal Awards, now in their fifth year, recognized three outstanding contributors: Antonella Severo, Nikita Aswani and Rachel Lawson. Congratulations to all three for their remarkable contributions to the Drupal community.
A huge thank you to every attendee, speaker, sponsor, volunteer and contributor who made DrupalCon Rotterdam unforgettable. Relive the memories through the official photo pool from the event.
The Drupal community doesn't stop. Next stop: Orlando (March 22-25) and Edinburgh (October 25-28) in 2027! See you there!
Drupal is light-years ahead of its reputation. We can change that together.
We've launched the Drupal Advocacy Program: a new Drupal Association pilot that awards contribution credit for content that helps the world discover modern Drupal.
Write a blog post for your market. Record a demo. Speak at a non-Drupal event. Translate a case study for your language. Appear on a podcast. Even boosting someone else's talk or story counts.
Throughout the year, we'll roll out themes with ready-made messaging and proof points for you to make your own — and themed content earns 2x–3x credits.
The Drupal Association engineering team was just on-site at DrupalCon Rotterdam, presenting the latest updates and working with the community in the contrib room on everything from the future of Drupal.org, to reducing friction with our GitLab contribution tools.
One of the major highlights of DrupalCon was the release of a brand-new Drupal AI demo experience. This new demo showcases the incredible breadth and depth of AI capabilities in Drupal, including page building capabilities and extremely powerful tools for context and governance.
If you attended Rotterdam but missed the session, keep an eye out in your inbox for a link to the private playlist. For the public at large, the DrupalCon session recordings will be available to everyone after a 30 day embargo from the end of the event.
The Drupal community thrives on the knowledge and experiences its members bring to the stage. Submit your session proposal for DrupalCon Orlando 2027 and share your expertise with the global Drupal community. The Call for Speakers closes October 20, 2026.
Early Bird registration is open, register by January 30, 2027 to save on your ticket. Consider adding a Summit or training to connect with industry peers and deepen your Drupal knowledge.
A variety of sponsorship packages are available, from exhibitor booths and high-visibility branding to smaller events like the Business Leaders Dinner, Summits, and training. Explore sponsorship opportunities and find your right fit.
Want to give back to the Drupal community while making DrupalCon Orlando 2027 an unforgettable experience? Volunteer applications are open for a new set of committees. Explore volunteer opportunities. Apply by October 30, 2026.
If you need financial assistance to attend DrupalCon Orlando 2027, this is your chance! The Inclusion and Community Scholarships are now open. Apply by October 30, 2026.
Can't make it to a Drupal event? You can still enter the Mascot Contest featuring an alligator. Be it a plushy, a photo, or a friend in a gator costume! If you prefer to stay off social media, let us know and we’ll post it anonymously for you.
This roundup is adapted from the DA Insider, the Drupal Association's monthly newsletter. Want it in your inbox? Subscribe to email communications and browse previous editions.
This post is adapted from the DA Insider, the Drupal Association's monthly newsletter. Subscribe here to get it in your inbox each month.
The Drupal Association team is incredibly grateful to have spent time with our community at DrupalCon Rotterdam. Dries Buytaert made one thing clear: Drupal is light-years ahead of its reputation. Our keynotes proved it, and stories from brands like Mars and World Cancer Day showcased Drupal's global power and ability to scale for good, both with cutting edge page building and AI integrations.
We were thrilled to celebrate our International Splash award winners, and the winners of the Women in Drupal award. It's our mission moving forward to expand our recognition for Makers, Patrons, and Advocates across the Drupal ecosystem, and to share Drupal's story beyond our own community.
Thank you to every attendee, speaker, sponsor, volunteer, and contributor who made Rotterdam absolutely unforgettable. We're excited to share what's next.
Tim Lehnen, CTO
This year's event welcomed 876 participants across 46 countries for four days of sessions, summits, workshops, and contribution activities at the Postillion Hotel & Convention Centre WTC Rotterdam.
The Driesnote was remarkable. Key highlights included the launch of the Drupal Advocacy Program, which awards contribution credit for writing, recording, and sharing about Drupal; the announcement of the Rosetta Sprint, aimed at making Drupal's capabilities readable by AI agents, systems, and humans alike; and a new public AI demo site showcasing Drupal's growing AI capabilities — watch the six demos here.
Dries also introduced the concept of Stewarded Open Source, positioning Drupal as the ideal platform for Europe's push for digital sovereignty. Read the full Driesnote recap here.
The International Splash Awards 2026 celebrated outstanding Drupal projects from across the globe, with a 40% increase in submissions this year. Congratulations to all the winners and runner-ups.
The Women in Drupal Awards, now in their fifth year, recognized three outstanding contributors: Antonella Severo, Nikita Aswani and Rachel Lawson. Congratulations to all three for their remarkable contributions to the Drupal community.
A huge thank you to every attendee, speaker, sponsor, volunteer and contributor who made DrupalCon Rotterdam unforgettable. Relive the memories through the official photo pool from the event.
The Drupal community doesn't stop. Next stop: Orlando (March 22-25) and Edinburgh (October 25-28) in 2027! See you there!
Drupal is light-years ahead of its reputation. We can change that together.
We've launched the Drupal Advocacy Program: a new Drupal Association pilot that awards contribution credit for content that helps the world discover modern Drupal.
Write a blog post for your market. Record a demo. Speak at a non-Drupal event. Translate a case study for your language. Appear on a podcast. Even boosting someone else's talk or story counts.
Throughout the year, we'll roll out themes with ready-made messaging and proof points for you to make your own — and themed content earns 2x–3x credits.
The Drupal Association engineering team was just on-site at DrupalCon Rotterdam, presenting the latest updates and working with the community in the contrib room on everything from the future of Drupal.org, to reducing friction with our GitLab contribution tools.
One of the major highlights of DrupalCon was the release of a brand-new Drupal AI demo experience. This new demo showcases the incredible breadth and depth of AI capabilities in Drupal, including page building capabilities and extremely powerful tools for context and governance.
If you attended Rotterdam but missed the session, keep an eye out in your inbox for a link to the private playlist. For the public at large, the DrupalCon session recordings will be available to everyone after a 30 day embargo from the end of the event.
The Drupal community thrives on the knowledge and experiences its members bring to the stage. Submit your session proposal for DrupalCon Orlando 2027 and share your expertise with the global Drupal community. The Call for Speakers closes October 20, 2026.
Early Bird registration is open, register by January 30, 2027 to save on your ticket. Consider adding a Summit or training to connect with industry peers and deepen your Drupal knowledge.
A variety of sponsorship packages are available, from exhibitor booths and high-visibility branding to smaller events like the Business Leaders Dinner, Summits, and training. Explore sponsorship opportunities and find your right fit.
Want to give back to the Drupal community while making DrupalCon Orlando 2027 an unforgettable experience? Volunteer applications are open for a new set of committees. Explore volunteer opportunities. Apply by October 30, 2026.
If you need financial assistance to attend DrupalCon Orlando 2027, this is your chance! The Inclusion and Community Scholarships are now open. Apply by October 30, 2026.
Can't make it to a Drupal event? You can still enter the Mascot Contest featuring an alligator. Be it a plushy, a photo, or a friend in a gator costume! If you prefer to stay off social media, let us know and we’ll post it anonymously for you.
This roundup is adapted from the DA Insider, the Drupal Association's monthly newsletter. Want it in your inbox? Subscribe to email communications and browse previous editions.
An AI-generated image can reach a Drupal site with a digital signature attached, and leave it with another one. Three modules sit in between, and each does one job. Here I follow them one by one on a real image, the cover of this article made with ChatGPT, and I say what held up on my test site and where it broke. What an AI image carries and how AI Disclosure, the module I created on drupal.org within the Drupal AI Initiative, labels it is covered in the article on metadata and labels for AI images. Content Credentials reads: it opens the signature of the files an editor uploads and, if it says the file was made with AI, proposes the grade in AI Disclosure. AI Disclosure declares: it keeps the grade the editor confirms, shows the label to readers where the law asks for it and writes the metadata into the copies.
read moreIn May 2025, the Drupal Association proposed an International Drupal Federation under Belgian law. It could unlock European public funding, give Drupal's assets a neutral legal home, and reduce dependence on a single legal system. At its public board meeting in Rotterdam, the DA said it supports the idea but won't drive it. Somebody else has to pull the strings. Jürgen, watching from the outside, sees one trap: every stakeholder starting with "what's in it for us?" and "how much is it?". He suggests two phases. First, write a charter that defines the Federation's objectives, responsibilities, decision-making, legal framework, membership and conflict resolution, with everyone's own stakes left out. Then let each prospective member decide whether to join.
We've spent the last year building an AI-assisted development pipeline for daily use on client projects. Here's what that looks like in practice, and where humans stay firmly in control.
Whether you're a technical lead at another Drupal agency or a government team new to AI, here's what accountable adoption looks like in practice.
We ask Claude to review the ticket—Jira or the relevant Drupal.org issue queue—and ask clarifying questions before proposing a plan. We iterate until the developer and AI share the same understanding of what's required.
We draw on approximately 30 reusable skills during implementation. Among them is a profiling skill for Drupal performance bottlenecks.
We also connect 2-3 MCP servers depending on the task—typically PHPStorm, Chrome DevTools, and Xdebug for runtime debugging instead of dump statements. A simple grep is often faster than routing a search through an IDE's MCP server, so we default to whichever tool is cheapest and still gets the job done.
Before anything nears a pull request, Claude reviews its own code and tests for scope creep and duplication. It also tests whether a slower browser test could be a faster kernel test.
We run PHPCS, PHPStan, and relevant PHPUnit tests. Claude Code's built-in security-review skill flags vulnerabilities before code goes anywhere near a pull request.
One more pass for optimisations. A human creates and pushes the commits and creates the pull request.
Lastly, a team member gets assigned for manual review. Every pull request receives a human sign-off before merge, regardless of how it was produced.
Beyond the skills above, we're building custom Symfony commands to bootstrap repetitive parts of our own code, currently living in github.com/previousnext/commands. We plan to move them into a Drupal contrib project, and are weighing whether a version belongs in core.
We're also watching the new dr command that landed in Drupal 11.4.0. It’s an experimental native CLI in core, built on Symfony Console, that lets modules register their own commands directly. It's also a natural home for this kind of tooling as it matures.
For government readers, "how do you control this" usually matters more than "how much faster is it."
We're trialling AWS Kiro alongside Claude Code, comparing its spec-driven approach on the same kind of tickets. We're also evaluating other models, looking for anything that matches our output more efficiently than our current default.
On the guardrails side, we're extending the Docker sandbox trial into a locked-down local development environment for the whole team, not just the agent. And we're building out more front-end-driven tooling to match the depth we already have on the PHP side.
One result is already paying off after using AI to reverse-engineer our Mixtape design system from Storybook into Figma. New designs now start from accurate Figma components and export directly to Mixtape code. This has closed a loop that previously required manual translation between design and code.
We're also aligning with the Drupal AI Initiative's Outside AI workstream. This focuses on how external agents connect to, inspect, and safely act on a Drupal site.
Drupal's structured content, permissions, and governance model are what make agent-driven changes safe in the first place. Our pipeline is a working example of that.
We’ve shared our approach to demonstrate that AI can be integrated responsibly and to encourage others to adopt best-practice approaches.
For other Drupal agencies, the biggest gains aren't "AI writes code faster". The efficiencies lie in the steps teams skip when moving fast, like clarifying tickets before planning and keeping test coverage lean.
For government teams, this doesn't require removing human accountability. In fact, we view human oversight as non-negotiable.
AI changes what a senior developer spends time on, such as planning, architecture design, refinement and review. It doesn’t change who's responsible for the outcome.
For our clients, nothing changes regarding who's accountable for what ships. Every change still goes through the same human review it always did. A senior developer signs off on every pull request, regardless of how it was produced.
What does change is where the time goes. Less of it sits in boilerplate, repetitive setup, and chasing down under-specified tickets. Instead, more of it goes into the actual problem you're asking us to solve.
Turnaround on well-scoped work is faster, without lowering the bar on what gets reviewed before it ships.
We don't have a rigorous study to back this up, but our estimate is a 20-30% efficiency gain across the board.
The gains vary by task type: boilerplate work like scaffolding new content types is up to 80% faster. Debugging, both backend and frontend, has improved dramatically.
While we've always been thorough in our reviews, we’ve still seen review time increase. This is because we're being extra cautious (rather than having previously waved through reviews).
AI in Drupal development moves fast. What we're using today will likely look different in six months.
New techniques will emerge, model costs will shift, and the community will settle on what actually works. We expect to keep adapting, and we'll keep sharing what we learn as we go.
We're genuinely curious about how other Drupal agencies are using AI in development and the efficiency gains you're seeing. Let's talk.
Build a reliable local Drupal environment with DDEV. Follow the steps to start a new site, import an existing project, and export the code, database, and uploaded files needed to recreate it elsewhere.
read moreWorking with AI, developer Brandon Thomas says he has recreated seven Adobe applications as open-source alternatives through ArtCraft. His pitch promises familiar tools without subscriptions, with code people can inspect, modify and keep. For users frustrated by proprietary terms, the attraction is a credible alternative they can make their own.
Credibility takes time to establish. PhotoCraft’s documentation describes an early alpha that is not yet a Photoshop replacement for daily professional work. Its future usefulness will depend on continuing improvements, compatibility and support, alongside the freedom its licence provides.
Drupal founder Dries Buytaert explains that distinction in his essay on licence-only and stewarded open source. Both are open source, but stewardship adds an ongoing commitment to the software and the people who depend on it. Maintainers fix failures, coordinate releases and respond to security issues, while organisations help fund the infrastructure and continuity that adoption requires.
Drupal illustrates why that continuing care matters. Its community and supporting organisations sustain a shared platform that users can retain while choosing different providers to host, extend or support it. The opportunity for new AI-built alternatives is to develop comparable continuity around their code. Established projects, including Drupal, must keep demonstrating that their stewardship delivers dependable software and meaningful choice.
A plausible outcome is more freely available alternatives, with lasting adoption concentrated around projects that sustain that care. Proprietary vendors may respond through better services or greater dependence on hosted features, while open projects can offer independence backed by accountable maintenance. Funding security, compatibility, documentation and long-term support would help make those alternatives viable. The strongest challenge to proprietary control could come from communities that give people both the freedom to leave and confidence in what comes next.
Follow The DropTimes on LinkedIn and Bluesky, or join #thedroptimes on Drupal Slack.
Allen Jason wrote and curated this issue of Editor’s Pick.
read moreThe image above shows me holding a plant that represents a small piece of code or an idea I want to share with someone else. To me, sharing code feels like planting something in someone else's garden. The analogy of open-source code and projects as plants and gardens appeals to me because plants are organic and essential to sustaining life, and the gardens we plant require significant planning and care. Open-source contributions come in all shapes and sizes, like gardens and the plants they hold, and both need maintenance. Some gardens require more maintenance than others.
My past two posts/tales focused on building and maintaining a Drupal module using AI, and now I want to discuss contributing to a module using AI. To continue my garden analogy, the projects I maintain are like my personal gardens.
Personal garden
By building and maintaining a Drupal module, I have control over my personal garden, but it exists within a community of gardens. I can decide which code/plants stay or go. Ultimately, I am responsible for the health of the project/garden. My project/garden is part of the Drupal gardens community (pun/irony intended). I am hyper-aware of the Drupal community where my Drupal garden lives.
Early on, when I took over building and maintaining the Webform module, I realized I was responsible for more than code; I was responsible for the entire experience of building Webforms for site builders and for supporting the module's extensibility for developers. To assist site builders and developers, I continually created videos and code examples as I built out the module. My blog explored and shared all aspects of the Webform module, including
read moreAn AI-generated video that looks real has to be declared to the people watching it, and on a site the declaration has to be both on the page and inside the file. Here I follow how AI Disclosure, the module I created on drupal.org within the Drupal AI Initiative, does it. Images have an article of their own, and so does audio. A video needs a label when it is a deep fake: when it credibly shows a person, a place, an object or an event that exists or could exist, and whoever watches it would take it as real. A synthetic avatar presenting a company's results falls within it, if the viewer mistakes it for a real person. A cartoon or a clearly fictional video keeps the label in a lighter form, next to the video rather than on it. The obligation falls on the publisher, under Article 50(4) of the AI Act, and it applies from 2 August 2026.
read moreWhen AI design tools started reading codebases to learn a design system, we wanted to know what Mixtape looked like through that lens.
It turned out "well documented for humans" and "legible to an agent" are two different things. Closing the gap surfaced bugs that had been shipping silently for months.
Three years ago we modernised Mixtape's CSS for the browser: cascade layers, container queries, modern selectors. Since then, we've also converted to Web Components, full Typescript and integrated some more modern CSS. The system got easier for developers to read and extend. What we didn't anticipate was that the next reader wouldn't be a developer at all.
In April 2026, Anthropic launched Claude Design. This tool reads a codebase during onboarding to build a model of its design system, then uses that model for every prototype it generates afterward. The same would apply to v0, Bolt, and anything else that learns a design system by reading it rather than receiving human guidance. We wanted Mixtape to onboard well.
We did a full pass over the codebase in March. We worked on the assumption that AI tools generally would need something more literal than what we had before Claude Design existed as a specific thing to test against. What came out of that work was a central /docs folder covering everything from Component Architecture, Memory Management and Security to Code Quality and Troubleshooting.
Then in April, Claude Design launched so we naturally pointed it at Mixtape. The assumption held up, but not completely. A developer who hits an ambiguous instruction asks a question in Slack. An AI tool infers an answer and bakes it into every design it generates from that point on. Our docs folder was solid for a human reading it top to bottom. It wasn't quite literal enough for a tool that takes every sentence at face value.
So in May we went back and wrote a structured reference file, plus richer per-component READMEs.
The main outcome is a structured DESIGN.md reference file, read as instruction rather than advice. It resolves every design token to its actual value rather than pointing at the source and assuming the tool will resolve it: colour.primary.colour maps to --colour-primary, which is hsl(223 100% 50%), not just a path in tokens.js.
It also says explicitly what to read and what to ignore. Read src/, docs/, and mockups/. Skip notes/, lockfiles, and build config. Specifying irrelevant files matters for resource usage as well as the quality of the output.
The full-page mockups turned out to be essential too. We point the tool at a real page composition, like a search results page built from real classes, before it generates anything from scratch. Components in isolation don't show how they're meant to sit together.
Component and class inventories with explicit "Nothing else exists - don't invent stuff" instructions, composition guidance, anti-patterns and documentation for the public token API (for example font-size: var(--button-font-size, var(--font-size)) where --button-font-size has no defined value and exists only as a public token, which Claude Design can use—once it knows about it—all feature in this file.
The result is a Mixtape that Claude Design can accurately work with. Developers aren't the only ones prototyping there now. A designer can test a layout idea, or sketch a full page composition, before it ever touches Figma, using real components and tokens instead of an approximation of them. That's the use case we're aiming for. A faster way to explore an idea, not a replacement for the judgement that goes into an actual design.
Writing that reference meant checking, component by component, whether the documented class actually matched the shipped code. It mostly did. Where it didn't, the gap had been sitting there for a while.
Breadcrumb was one. React was rendering a class that didn't exist anywhere in the stylesheet:
- className={classNames("mx-nav", "mx-nav--breadcrumb", "mx-nav--inline", className)}
+ className={classNames("mx-nav", "mx-nav--breadcrumbs", "mx-nav--inline", className)}Singular in React, plural in CSS and Twig. The React breadcrumb had been shipping un-styled, and nothing caught it because our snapshot tests only check that output hasn't changed, not that it's connected to anything. Also luckily no projects are actually using the Breadcrumb component in React yet.
Sticky had a similar issue, just inverted. The web component was querying for an older un-prefixed class that used to exist but no longer did:
- let trigger: HTMLDivElement | null = this.querySelector(".sticky__trigger")
+ let trigger: HTMLDivElement | null = this.querySelector(".mx-sticky__trigger")The web component never found the trigger element it needed to observe, so the "is sticky" check silently never activated. Nobody had flagged it, because the stickyness still worked. The is-sticky state change is just a small, optional progressive enhancement (until scroll-state container queries have better support).
Neither bug was hard to fix. Both had been invisible for the same reason: three output formats (React, Twig, Web Components) from one source, and nothing checking that a class emitted in one place was actually targeted anywhere else. It took writing documentation an AI would take literally to notice.
We're not leaving this as a one-off audit. The next step is a lint rule that cross-references every mx-* class against the CSS that's meant to style it, so this kind of drift gets caught at merge time instead of during the next big documentation sweep. More on that and some other tooling additions soon, in a follow up post.
Tagged
Most of the year my six hats take turns. At DrupalCon they all show up at once, and I end up wearing a "hat tower". Rotterdam last month was an absolute whirlwind again, and I came home tired but buzzing with energy. Here is the view from under each hat.
There’s an incredible amount of things happening in the world of Drupal and AI. It’s very exciting, but almost impossible to keep up with. I’d been planning for a while to seriously dive into agentic coding. I feel a little late to the party, but at the same time, I get the impression that many organizations haven’t got the faintest idea that this revolution is happening.
Until now, I’d mainly been experimenting with frontier models like ChatGPT and Claude through their AI chat interfaces. But I’ve finally found the time to take the plunge into agentic coding myself.
BigCommerce is a SaaS platform that has earned its reputation with B2B sellers. Its B2B Edition handles selling with quotes, its catalog supports far more product options than most SaaS platforms, and its open APIs make it friendlier to integrations than many of its competitors. If your business fits neatly inside its walls, it's a legitimate choice. Many distributors and manufacturers have found success on the platform.
The trouble starts when your requirements don't match the platform's assumptions. Its best B2B features sit behind the top-tier plan. Gross Merchandise Value (GMV) caps force automatic upgrades as you grow. A new fee introduced in June 2026 charges a percentage on orders processed through non-embedded gateways, including offline payments like purchase orders. And when your order workflows, product types, or integrations go beyond what the platform anticipated, you're forced to work around BigCommerce rather than with it.
Drupal Commerce is an open-source alternative built on Drupal. You own the code and the data, there are no license or transaction fees, and every part of the platform, from checkout to order workflows to the product data model, can be shaped to fit how your company already works.
Read more read moreToday we are talking about the UN, Open Source, and Drupal with guests Tim Lehnen & Henry Poole. We'll also cover Live Update as our module of the week.
For show notes visit: https://www.talkingDrupal.com/574
TopicsHenry Poole - civicactions.com henry-poole Tim Lehnen - drupal.org hestenet
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Tim Sharp - tea-sharp
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
Join us THURSDAY, October 15 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, October 15 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.
My website has a custom photo album module that I've maintained for about twenty years. It helps me manage more than ten thousand photos. In my DrupalCon Rotterdam keynote, I talked about making that module work with AI assistants. You can watch that part of the keynote. I didn't have time on stage to go into the details, so I'm doing that in this post.
To let assistants find and edit my photos, I used the contributed Tool module, which provides Tool API, to expose my module's operations as tools. These include finding photos and updating a photo's caption or alt text.
Most of these tools are public methods on Drupal services I already had, like the one that searches my photos. A few PHP attributes are usually enough for Tool API to expose an existing method, so AI assistants can call it over MCP, the Model Context Protocol.
To describe a tool to other software, Tool API needs to know what data it accepts and returns: what each value is called, what type it is and what it means.
My album module doesn't store photos as Drupal entities (I know, I know), so Drupal has no field definitions for them. Instead, it keeps them in its own database table and loads each photo into an instance of Image, a plain PHP class. I added PHP attributes to the getters for the properties I wanted to expose, like this one for the alt text:
#[ToolProperty(description: 'Plain text describing the image for screen readers.', media_type: 'text/plain')]
public function getAlt(): string {
...
}
From attributes like this one, Tool API generates JSON Schema, a format for describing JSON data. MCP and OpenAPI, a standard for describing HTTP APIs, both use this format. So do Drupal's Single Directory Components, which use it to describe the data passed to reusable interface components.
In my album module, I use the same descriptions of my photo data to tell AI assistants what my tools return, generate TypeScript types for a React app that searches my photos, and define the inputs for my Drupal components.
The same tools also connect my site to various workflow systems. A workflow built with ECA, FlowDrop, Maestro, n8n or Activepieces can call the same photo-search tool an AI assistant calls, without requiring a separate integration with my album module.
A module maintainer exposes an operation once, and several kinds of software can use it.
This is why I said in my keynote that I believe the Tool module, built by Michael Lander and team, is one of the most important modules in Drupal right now. A module's capabilities can become available to assistants, front ends and workflows without its maintainer having to build for each one separately.
I think every Drupal module should work this way, which is why I featured it in my keynote and why I launched a broader effort around this called Rosetta.
The goal is for Drupal's own systems and software outside Drupal to work from shared descriptions of data and operations. Below, I'll walk through what I built and tested with my album module.
More of the work on a site happens outside Drupal every year: in AI assistants, in front ends built with JavaScript frameworks, and in orchestration platforms that connect Drupal to other systems. As I explained in AI and the great CMS unbundling, those systems still need the content management, governance and observability that Drupal already provides.
Drupal has entities, fields, permissions, revisions, workflows, content moderation and tens of thousands of contributed modules. But making a module's capabilities available to an assistant, a workflow or a front end still too often requires some integration work.
Installing a Drupal module should make its capabilities available to software already connected to a site: new tools for assistants, new operations for workflows, and new capabilities for front-end developers.
In my album module, I should only have to describe a photo once and implement photo search once, not write a separate integration for every assistant, front end or workflow system.
In Drupal, we already know why shared descriptions matter. When a site builder adds a field to a content type, Drupal stores a definition for it: its type, its label and whether it's required. Content editing forms, Views and JSON:API all reuse that definition.
CCK, Drupal's Content Construction Kit, let site builders define a field once, and Drupal used that definition for the edit form, the display and the database. Views let them list, filter and sort data from any module that described its data. Rosetta is about extending that kind of reuse to more of a module's data and operations.
Shared descriptions of data and operations could be Drupal's next CCK and Views moment.
User interfaces also keep changing: web pages, then native mobile apps, then headless front ends, then chat, and now AI assistants and agents. I don't know what comes after agents. But if modules describe their data and operations, new interfaces can build on the capabilities we already have. The next interface reads the description and gets to work. That won't make Drupal immune to change, but it makes us fast to adapt, and fast to adapt helps us win.
The question then becomes how to make that practical for thousands of module maintainers. Tool API gives us a starting point, alongside years of work on Typed Data, Single Directory Components, JSON:API, Drupal Canvas Code Components, Modeler API, and more. We need the people behind that work to help shape the approach, including whether Tool API, or parts of it, belongs in Drupal Core.
That's why I'm organizing the Rosetta Sprint: a few days for the people behind these projects to get together in person to compare the existing approaches, identify what is missing and agree on next steps with the relevant maintainers and Core committers.
Tool API supports two ways to define a tool: (1) you can write a dedicated plugin class that Drupal discovers as a tool, or (2) add PHP attributes to an existing public method on a class registered as a Drupal service.
I started with a dedicated plugin class but ultimately switched to PHP attributes. Attribute support was still experimental when I started, and I helped improve Tool API as I used it (#3583030, #3583031, #3583032, #3583041, #3583085). The attribute support is now merged and available in Tool API's development version. Dedicated plugin classes remain fully supported.
I'll show the basic pieces here rather than walk through a full tutorial. Here is how the method that searches my photos becomes the find_images tool, simplified a little:
/**
* Searches the images.
*
* @param string $query
* Words to look for in the title, caption or alt text.
*
* @return \Drupal\album\Image[]
* The matching images.
*/
#[ToolMethod(
id: 'find_images',
label: 'Find images',
description: "Searches the site's images. …",
operation: ToolOperation::Read,
permission: 'access content',
)]
public function search(string $query): array {
// The search code is unchanged.
}
The method body stays the same: it takes a search query and returns the matching images. The #[ToolMethod] attribute gives the tool its ID, label and description. It also declares that the operation reads data and that the caller needs the access content permission. The search code must still enforce any restrictions on which photos the caller can see.
Tool API reads the input's name and type, query and string, from the method signature. When type information is missing, Tool API tries to infer it from the method signature and docblock. Here, the Image[] return annotation tells Tool API that the array contains Image objects.
Knowing that the result is a list of Image objects doesn't tell other software which properties a photo has. I describe those with #[ToolProperty] attributes on the Image class's getters, like getAlt() above.
The attributes also explain what each property means. In PHP, a title, a caption and a URL can all be strings, but other software needs to know which is plain text, which contains HTML and which is a URL. I illustrated that distinction in the keynote:
string type, but #[ToolProperty] attributes describe the title as plain text, the caption as HTML and the URL as a URI.Tool API only includes the photo properties I explicitly describe with #[ToolProperty]. The attribute can go on a public class property or a getter method. On getUrl(), it exposes the returned value as a photo property named url; it doesn't make the getter a callable tool.
Under the hood, Tool API uses Drupal's Typed Data API to represent these descriptions and can generate JSON Schema from them.
Drush, MCP, ECA, FlowDrop, Maestro and my album module's custom HTTP route can all call the same runner, ToolRunner::run(). That means the same permission checks and input validation apply whichever way a tool is called. The runner also distinguishes invalid input from denied access or an execution failure, so each integration doesn't have to work that out for itself.
As mentioned, PHP attributes aren't the only way to define a tool. A dedicated plugin class is a bit more verbose, but it has some advantages. For example, it doesn't have to live in the module it exposes. A separate module can define the tools and call the original module's services and APIs, with no changes to its code. Tool Belt currently takes that separate-module approach for Drupal Core operations, like creating content and updating fields. That means we can add tool support for existing modules without waiting for their maintainers to adopt Tool API.
If you maintain a module, try exposing one useful operation as a tool. If you get stuck, or Tool API can't describe the data you need, open an issue. Your feedback can help us improve Tool API before its first stable 1.x release. Tool API is still young, so you can help shape it.
I actually started with search. A while ago, I exposed my blog's search to AI agents and wrote about it several times: as an MCP tool, through an API catalog and with Agentic Resource Discovery. That code started out custom, but I've since updated it to use Tool API as well.
Later, I added the album tools. My album module provides seven. The ones I use most are find_images and get_image, which find and read photos, and update_image, which changes a photo's title, caption or alt text.
I've used these tools to write titles and alt text for whole albums. Here are a few other things I ask an assistant to do:
The album tools and find_posts often work together. If I have an album from a trip and a blog post about the same trip, an AI assistant can call find_posts while it writes alt text for the album's photos, and use the post as context. It picks up details such as where we went, who was there and what the trip was for. The alt text gets better, without me having to point the assistant at the post.
My album module's admin screens can't do any of these tasks quickly, and some tasks have no screen at all. Before these tools, I either had to run SQL queries on the database or didn't do the task at all. To fix missing alt text, I'd query for the photos without it, then open each photo's edit screen in a browser. Updating dozens of images that way gets tedious.
Now an assistant finds the photos and drafts the alt text, and I review and approve its suggestions in Claude. It's at least 10 times faster than my old workflow.
I've been writing SQL for nearly 30 years, so I could always do these jobs myself. Many site owners can't. They ask a developer for help, or the job never gets done. Tools can remove that dependency. Photos are just my example. Any operation a module exposes as a tool becomes something a site owner can ask for directly, without waiting for a developer.
When an assistant calls get_image, it gets the photo's properties and the photo itself, so it can see what it's describing. In Claude, an interface I built also displays the photo in the chat. It uses MCP Apps, an MCP extension that lets a server provide an HTML interface the client renders in the conversation.
Every module has tasks that are too rare or too specific to justify a screen of their own. A maintainer can build screens for everyday work and make rare or specialized tasks available through tools. I've already removed parts of my album module's interface, like the button that generated alt text with a language model, because an assistant now does that job. I expect to remove more.
Shared descriptions can also make it easier to tailor interfaces to the people using them. Tool API can already generate a form from a tool's inputs and apply the same validation constraints when the tool is called without a form. Michael Lander is exploring this further in his Data Surface prototype, where forms and tools use the same definitions of accepted values and validation rules.
An organization could build admin screens around its own workflow while reusing those definitions and validation rules. With the right prompting, assistants can already build interfaces around these tools. For a batch of photo updates, that could be a table of images and proposed alt text where I can review and approve the changes. Over time, I expect assistants to recognize when an interface would help with a task and build one without being asked.
Michael's work builds on Drupal's configuration validation, and it is a good example of what I mean when I say Drupal has an accidental AI advantage. Wim Leers began advocating for configuration validation in 2022. AI wasn't part of his case. Years later, Michael can reuse those validation constraints to power forms and tools from one definition, and in Validation-first, Wim describes how the same precision helps AI tools generate valid Drupal Canvas code components.
But that is not all. With my album data and operations described, I decided to make the same data and tools available to front-end developers. I wrote two pieces of connecting code: a shared HTTP route that calls read-only tools, and a generator that produces an OpenAPI document from their definitions. Together, they take under 150 lines of PHP.
The route uses the URL to identify the tool and the query string to supply its arguments. For example, a request to /api/find-images?query=ski calls find_images with ski as its query and returns the result as JSON. I didn't write another photo search or a separate route for each tool.
The auto-generated OpenAPI document, available at https://dri.es/openapi.json, describes those endpoints, their parameters and their responses. It uses the same #[ToolMethod] and #[ToolProperty] attributes the MCP tools use.
OpenAPI is a 15-year-old standard for describing HTTP APIs, so it's supported by many developer tools. Swagger UI, for example, lists my endpoints and lets you try them. This video shows the document, then Swagger UI reading it and calling the API for "driesnote":
Many front-end developers use TypeScript, which adds static types to JavaScript. A type can describe an image as an object with a string alt and a string title. The TypeScript compiler checks the code against those types before it runs, and editors like VS Code show type errors as you write.
To see what this gives a front-end developer, I asked Claude Code to build a small React app that searches my photos from the browser. The app knows nothing about Drupal, and building it didn't require any Drupal knowledge either. All Claude Code had was my site's URL and its generated OpenAPI document.
I'm not a front-end developer, so it was interesting to watch. Claude used a code generator called openapi-typescript to turn my OpenAPI document into TypeScript types in under a second. A small library called openapi-fetch then uses those types, so the compiler can check the request paths and parameters in the app's code.
The whole app is a single React component of 45 lines, and I wrote no additional Drupal code for it. In this video, it searches for "driesnote":
The HTTP route and OpenAPI generator are prototype code on my site. Nothing in them is specific to photos, so they shouldn't be something each site or module has to write. They belong in shared infrastructure that works for any module's tools. JSON-RPC is one place that could happen: if JSON-RPC supported Tool API, it could expose tools from other modules without each module writing its own JSON-RPC integration.
Inside Drupal, ECA, FlowDrop and Maestro can call tools as steps in a workflow. The ECA Tool module, for example, makes tools available as ECA actions.
In the keynote, Shibin Das showed a FlowDrop workflow he built with my album module's tools. It searches my photos and lists my albums, first without any AI, then with an agent that decides which tools to use:
Workflow systems can also expose tools of their own. ECA calls its workflows "models", and the ECA Tool module exposes each Tool event in a model as a separate tool. One model can therefore offer several tools. Maestro can expose public workflow templates as tools, using their variables as inputs.
A workflow that is also a tool can be used like any other tool. A Maestro workflow can call a tool exposed by ECA, through the same Tool API integration it uses to call my photo search. Neither system needed a direct integration with the other. I still find that a little hard to get my head around, but I love it and see the potential.
Automation platforms outside Drupal need a way to call those tools too. Last year, Jürgen Haas and I built the Orchestration module to connect Drupal with Activepieces. It lets Activepieces call tools defined through Tool API, run AI agents and trigger ECA models, while events in Drupal can trigger workflows in Activepieces. I described that setup in Connecting Drupal with Activepieces. Other platforms can call Drupal's tools over MCP, for example through n8n's MCP Client node.
Tools compose. An assistant can combine them in a single task, a workflow can chain them, and a workflow can be one of the tools in another workflow. Once a system can call Drupal's tools, it can reuse that connection for operations from different modules.
That is the orchestration shift: a stack becomes a network, and workflows coordinate work across applications. Drupal can be a node in that network, with its modules offering operations that other systems can call. For agencies building those workflows, Tool API makes Drupal's capabilities available as reusable steps.
So shared descriptions help JavaScript front ends and other applications use Drupal's data, but they can also help Drupal's own rendering system, even when no AI assistant or external application is involved.
My photos are rendered using Single Directory Components, or SDCs. Each component keeps its Twig template, CSS and metadata in one folder. Its .component.yml file declares the component's inputs, called props, and describes the data they accept.
My album module already describes a photo's properties with #[ToolProperty] attributes. I was also maintaining descriptions of those same properties in each photo component's .component.yml file. When I changed what a photo property contained, I had to remember to update both descriptions.
So I wrote a Drush command that reads the PHP attributes and generates a shared schema.json file. My album module's generated photo schema describes properties such as alt and caption: their types and what they contain. Each photo component's .component.yml file now references that shared description instead of describing those properties again. When I change what a photo property contains, I update its PHP attribute and run the command.
Moving the descriptions into a shared file creates a new problem. Anything that reads a component's .component.yml now finds a reference to schema.json, not the property definitions. A tool that builds a component catalog, showing what data each component expects, has to find and resolve that reference itself. Core's component API doesn't do it for them: it returns the reference without the photo's property definitions.
Pierre Dureau's merge request in Core issue 3352063 addresses that gap, though it isn't merged yet. With it applied on my site, Core's component API followed the reference and loaded the photo property definitions, without any changes to the schema file.
That matters for generative UI. Frameworks like OpenUI and A2UI let an AI agent assemble an interface from a catalog of components, so they need to know which components exist and what props each one accepts. With this change, an integration could build that catalog from Drupal's API instead of writing its own reference resolver. Tools that read the component files directly still need to learn to follow these references. The SDC add-on for Storybook, a tool for developing and previewing components, doesn't yet follow the Drupal-specific references I use.
The same goes for the generator. Other module maintainers shouldn't each have to write one like mine. My experiment uses Tool API's property descriptions, but describing data and generating schemas are useful beyond tools. Some of that support could belong in Drupal Core, benefiting both SDC and the Icon API, which uses JSON Schema to describe icon settings such as size and color.
My approach only covers components built to render my module's photos. General-purpose components define their own inputs and still need a way to get Drupal's data. Drupal describes entity fields with Typed Data, while SDC describes props with JSON Schema. UI Patterns already handles much of the work between them, including which data sources can supply a prop. Rosetta should build on that work too.
The same photo descriptions and operations now support AI assistants, a React app, workflows inside and outside Drupal, and Drupal components.
I want more module maintainers to adopt Tool API: describe their modules' data once and expose useful operations as tools. That should become a normal part of developing and maintaining a Drupal module.
We should also provide the HTTP integration, OpenAPI generator and component schema generator as shared Drupal infrastructure. Module maintainers shouldn't each have to write that connecting code.
My prototypes show this working for one module. Rosetta is about making that reuse work across Drupal. We need to work with the relevant maintainers and Core committers to decide what belongs in Tool API, its integrations and Drupal Core.
If you maintain a module, try exposing one useful operation as a tool and using it with another system. Share what worked, and open an issue when you find something Tool API can't describe or do.
Thanks to Jamie Abrahams, Mateu Aguiló Bosch, Ronald te Brake, Shibin Das, Pierre Dureau, Matt Glaman, Jürgen Haas, Marcus Johansson, Randy Kolenko, Michael Lander, and Fons Vandamme for reviewing this post and sharing their experience.
read more
Drupal 11.4.10 addresses three core security vulnerabilities, including a critical remote code execution flaw. Site owners should prioritize the appropriate core update and check whether separate Gin or Entity List updates also apply.
read moredrupalThe Navigation module doesn't sufficiently sanitize certain attributes, which can lead to a cross-site scripting (XSS) vulnerability.
This vulnerability is mitigated by the fact that an attacker must have a role with permission to enter HTML tags containing specific data attributes, or the administer menu permission.
Install the latest version:
Drupal 11
Drupal 10
drupalThe Drupal core Link module provides a field type that can be used for internal and external URLs.
The module does not sufficiently sanitize certain markup in some circumstances, which can lead to cross-site scripting (XSS) vulnerabilities.
Install the latest version:
Drupal 11
Drupal 10
drupalA remote code execution vulnerability exists within the Field UI module in Drupal core.
The vulnerability is not directly exploitable with core alone, but multiple serious exploit paths exist with contributed modules. At least one known exploit path does not require authentication. Custom code may also expose the vulnerable functionality.
The vulnerability can be mitigated by uninstalling the core Field UI module (field_ui), which will provide protection while sites are updated.
This issue is being protected by Drupal Steward. Sites that use Drupal Steward are already protected from some known attack vectors, but the protection offered will not cover all possible exploits. Sites should upgrade in the near future in case additional attack vectors are discovered.
Install the latest version:
Drupal 11
Drupal 10
Drupal 8 and Drupal 9 have both reached end-of-life.
Release packaging may still be in progress for this security announcement. If you are unable to access a release, wait 30-45 minutes and then check again.
Author: Will Huggins
The narrative around enterprise AI is changing. Digital leaders — from CMOs looking for campaign velocity to CISOs managing vendor risk — are no longer just asking for new AI features. They are asking for AI infrastructure they can actually trust. They want to know how to maintain brand sovereignty, ensure content provenance, and scale AI operations without creating unmanageable compliance risks.
This shift in the market perfectly aligns with the mission of the Drupal AI Initiative: to establish Drupal as the premier open-source AI platform for digital experiences.
This October, the conversation took a national stage at Digital Leaders' AI Week 2026, the UK's largest online festival of AI learning. And the Drupal community is front and center.
While Drupal AI is fundamentally a technology initiative, its real-world impact comes from the thought leadership of the people building it. At AI Week, members of the Drupal ecosystem shared strategies that go far beyond the CMS, showing how open-source principles are solving the hardest challenges in enterprise AI adoption.
Here is a look at two key sessions you won't want to miss.
The technology to generate content, personalise experiences, and orchestrate complex user journeys is already here. But as many organisations are discovering, having access to an AI model is not the same as having a scalable AI operation.
In this session, we will explore the critical gap between technological capability and organisational readiness. The focus will be on the necessity of an AI Management System (AIMS) — a structured approach to governing AI adoption.
This is where Drupal AI's philosophy truly shines. When we talk about Drupal as an "AI platform," we are talking about built-in governance. Organisations locked into proprietary platforms often struggle to adapt their AI infrastructure as new models emerge or regulations change. Lightweight SaaS tools, conversely, often lack the rigorous audit trails enterprise IT requires.
This talk will illustrate why the organisations that win in the age of AI will be those that prioritise structural sovereignty — the ability to control their own data, choose their own models, and enforce their own brand guidelines at scale. It’s the exact reason why the Drupal AI Initiative developed the Context Control Center (CCC), ensuring that AI-generated content is always grounded in verified, human-authored brand rules.
As AI-generated content floods the web, user trust is becoming the most valuable currency in digital experience. How do organisations prove that their content is accurate, authoritative, and compliant?
This session tackles the critical challenge of provenance data. It’s not enough to simply label something as "AI-generated"; organisations need to design systems that users can fundamentally trust.
This aligns perfectly with Drupal's Grade A rating for Software Sovereignty. Drupal's architecture is built on transparency and community governance. The platform doesn't just generate content; it provides the branch-based versioning, strict approval workflows, and deep audit trails necessary to track exactly how that content was created.
When an AI agent in Drupal proposes a layout optimisation or drafts a translated page, it operates within a highly governed environment. Humans remain firmly in the loop. This session will explore the broader implications of this approach, arguing that trustworthy AI requires safeguards built into the core architecture, not bolted on as an afterthought.
To see how these principles are being put into practice today, explore the Drupal AI interactive demos.
This is a cross-post of a blog by Nathaniel Catchpole, Senior Performance Engineer and Technical Lead at Tag1
At DrupalCon Vienna, Tim Lehnen presented on the main costs for running Drupal.org. Around 50% of the total cost of running drupal.org, or approximately $1.5m, is infrastructure costs. A significant slice of infrastructure costs comes from drupal.org's self-hosted GitLab, and in turn much of that cost is due to GitLab CI for Drupal core and contributed modules.
Figure 1: Drupal Engineering activities compared to the various funding sources
Drupal core is the single biggest project in terms of CI minutes, both due to the sheer number of tests as well as the level of activity in Drupal core issues, with hundreds of commits per month and activity on thousands of issues and Merge Requests ("MRs").
Figure 2: Drupal CI minutes by project, July 2026, core issue forks are treated as separate projects
Since Drupal originally moved to Gitlab CI from our previous Jenkins-based CI infrastructure in 2023, we've been working on reducing the time taken for Drupal core test runs.
The primary end goal of this work was to reduce the wall time for pipelines on MRs. These started at around 55 minutes when we originally moved to Gitlab CI (approximately the same as they were on Drupal CI), and now generally finish in 5-7 minutes. The 55 minute runtimes already relied on previous known optimizations like using a ramdisk for both the database and filesystem, applied to GitLab runners. GitLab does not support this out of the box.
Five minute turnaround times on pipelines have made a huge difference to Drupal core velocity. Whereas core contributors used to push to a branch, then go and eat lunch or dinner while waiting for the pipeline to finish, there's now barely enough time to make a cup of coffee, let alone drink it.
Figure 3: Contributors recognizing and commenting on the time improvement of waiting for the pipeline to finish
However, the bulk of the initial gains we made to core CI pipeline performance was in wall time, with much less impact on CPU minutes. This is now starting to change, as we're finding ways to reduce the CPU minutes while also keeping wall times as short as possible.
We reduced pipeline wall times via the following approaches.
Drupal's run-tests.sh has supported running tests concurrently for a long time. We added support for Gitlab's parallel test runs, splitting test groups with thousands of tests into smaller groups so that they can be run on multiple test runners at once. For example Drupal's functional test group is executed in 8 parallel jobs, at 15 concurrency, with a CPU request of 10 per job. This runs 150 test classes at a time on 100 CPUs. By running smaller sized individual jobs, there is also a higher chance of them fitting into test runners that become available rather than requiring a new AWS instance to be spun up.
Tests are always run slowest first. Drupal's test runner has supported a #slow group for a long time, so that very slow tests can be run first. We now also order tests by the number of methods, so that tests with more methods, which overall tend to be slower, run first too. This is critical for other optimizations to be effective. If a single class takes three minutes to run, starting it at the beginning when the rest of the tests can also be completed in three minutes means the entire test run can be finished in three minutes. But if that job started last, the job could take six minutes, with just that one test being run for half the time, leading to slower wall times and idle CPUs.
In some cases we have had individual test classes that took more than 10 minutes to run. For these very slow running tests, we've split them into smaller test classes so that they can be run in parallel, and/or optimized the test set-up requirements so that no individual test takes longer than a full run.
With these techniques, we've been able to balance CPU requests and concurrency across the various core test types, so that every job finishes within approximately 3-4 minutes. This has given us a solid framework for keeping pipeline wall times to a minimum while allowing us to adjust CPU requests and concurrency for individual test types to match the scope of core's overall test coverage. As far as we know there are no longer obvious optimizations to make via tweaking concurrency and test running order.
While we've been working on optimizing the tests themselves, in recent months focus is increasingly shifting in that direction as the best way to further optimize test runtimes, but more importantly, reduce CI minutes and the resulting infrastructure cost for the Drupal Association overall.
Drupal core started with only one type of test: SimpleTest 'functional tests' that require a full Drupal install into a separate site that the tests are then run against. Over time with the adoption of PHPUnit, we've added unit tests, 'kernel tests' which include a full dependency injection container but don't do a full install, functional JavaScript tests which use a real browser, and build tests which allow creation of a completely separate code base in its own directory. There is an ongoing effort to convert functional tests to kernel and unit tests where this can be done without losing test coverage, with the recent addition of http request testing to kernel tests making many more tests eligible. Converting a functional test to a kernel test can reduce the time it takes by 3/4, so for the tests where this is possible it's one of the most effective ways to make gains, although the conversions have to happen test by test across dozens or hundreds of test classes.
Over the past couple of years there has been a concerted effort to improve Drupal core performance. Many runtime performance improvements don't necessarily make a lot of difference to test runtimes as a whole. But because functional and functional JavaScript tests install a full Drupal site and request real pages, anything which improves installer or cold cache performance tends to have an outsized effect on test runs. Installer performance generally doesn't affect production sites (because they're already installed!) and cold cache performance is often not a priority for production sites because it tends to affect a low percentage of overall requests, however as well as CI times, it can also make huge differences to the user experience for new users as well as improving responsiveness after deployments and cache clears.
In 11.2.0, we changed module install to support installing multiple modules at once without a separate dependency injection container rebuild between each module. Instead of doing 50 or 60 container rebuilds during an install, we do more like 11 or 12. This took tens of seconds off Drupal installs, whether via the UI, Drush, or during test runs.
Figure 4: Installing multiple modules in Drupal 11.2
Source: Figure 4: Installing multiple modules in Drupal 11.2.
In Drupal 11.4, we made container rebuilds during the installer more conditional, reducing container rebuilds during a functional test from 11 to 8.
Recently, I've been looking at whether it would be possible to reduce the 8 remaining container rebuilds further, without necessarily an expectation that there would be much room for improvement, and found some. With all of those changes, some of which are not committed yet, we should be able to get down to an absolute minimum of 2 container rebuilds in tests. While some of the optimizations are test-specific, a real-life Drupal install of the minimal profile takes less than 2 seconds.
This investigation also uncovered further possible performance improvements in the installer.
While the combination of these changes probably saves only around 5 seconds at most from an install during a test run, this saving is multiplied by every install that occurs, with thousands of Drupal installs on every test run, this adds up to several minutes of CI time.
This has already allowed us to reduce the total CPU request for functional tests from 128 to 80 with no increase in wall time. We expect to be able to reduce the CPU request for both functional and functional JavaScript tests further once more optimizations land.
Kernel tests in general run much faster than functional tests, however there is still a per-method overhead which is a lot higher than unit tests. We are looking at adding an option to kernel tests to share the database state between test methods which will remove a lot of that overhead. This in turn will allow us to re-use the dependency injection container between methods. As we move functional tests to kernel tests, this should increase the impact of that change on resource usage even more.
Drupal core has daily, weekly, and on-commit jobs on its branches, as well as those that run on individual MRs. In looking at the information we get from those jobs, we realised that the on-commit jobs, which on average run several times per day, and run the full test suite against multiple different database types (Mysql, MariaDB, SQlite, PostgreSQL) don't necessarily give us information that we can't otherwise get from MR, daily and weekly runs. For release branches, we need immediate post-commit feedback in case something is unexpectedly broken, which sometimes happens when two independent commits are fine individually, don't have merge conflicts, but break when combined anyway. However, we're in the process of trialling running our development branches without on-commit pipelines whatsoever. This should reduce CI minutes for core purely via running pipelines less often, on top of the in-pipeline optimizations above.
While individual contrib projects are not the biggest user of CI minutes, there are thousands of contributed projects. Several of the performance optimizations for the installer, functional tests, and kernel tests will apply to contributed module tests too, since those have to install core the same way as core tests do.
Additionally, there has been recent work to switch contrib's gitlab_templates shared pipeline definitions to running concurrent tests by default. Contrib tests previously used raw phpunit which runs each test sequentially with an option to switch to concurrent test running via run-tests.sh; the default flipped to run-tests.sh by default in September 2026. Because contrib tests should also benefit from core's 'slowest test first' strategy, this should compress pipeline times in contrib and it may have a positive impact in reducing CI minutes overall if runners are able to complete jobs in a shorter time with the same CPU request.
Taken together, these changes lower the cost of running core's CI run by run, through shorter wall times, fewer CPU minutes, and fewer pipelines overall. As Figure 2 shows, core is the single biggest consumer of CI minutes on drupal.org, so that work is aimed at the largest single driver of the GitLab CI costs behind the Drupal Association's infrastructure bill.
What that adds up to on the bill itself is a separate measurement, and will take longer to validate. Total cost depends not only on the cost per run but on how many runs happen, and core activity (commits, issues, and merge requests) is holding steady or rising. So the effect on the DA's hosting costs has to be read from same-month comparisons year over year, or averages across several months, rather than any single snapshot. We’ll be keeping a close eye on this as the latest round of changes are committed.
This blog has been re-posted and edited with permission from Dries Buytaert's blog.
Drupal is now light-years ahead of its reputation. Closing that gap is our #1 challenge, and it was the main message of my DrupalCon Rotterdam keynote.
Just over two years ago, I launched Drupal Starshot. I did it because I wasn't sure we could still innovate like we used to. It turns out we can.
Starshot became Drupal CMS, which brings together Site Templates, Recipes, Drupal AI, Drupal Canvas and more to make building websites easier.
Alongside that work, Drupal Core has become a faster and better framework for developers. A stronger Drupal Core helps us build a better Drupal CMS, while building Drupal CMS has driven further improvements in Drupal Core.
Unfortunately, many people outside the Drupal community haven't seen what Drupal can do today. In Rotterdam, I showed how far we have come and where we're going next, and we launched an advocacy program to help more people see how great Drupal has become.
If you missed the keynote, you can watch the video below or download my slides (86 MB).
The first part of my keynote showed improvements for multilingual sites, JavaScript front-ends, headless Canvas, and Drupal AI.
Drupal has long had strong multilingual capabilities, but Drupal Canvas, our powerful new page builder, didn't yet support multilingual sites. Not only did we add multilingual support to Canvas, but we made all multilingual sites easier to set up.
React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.
At DrupalCon, we extended that same model with Drupal Canvas Headless. Developers can now use Drupal to manage content while building the front-end separately with frameworks like Next.js, Astro, TanStack, Angular, or Nuxt. Editors still get the visual experience of Drupal Canvas: they can build pages in Drupal and preview exactly how those pages will appear on the front-end.
This changes an important trade-off. Teams no longer have to choose between a modern JavaScript front-end and Drupal Canvas' visual authoring experience. They can have both. That opens Drupal to more developers, more front-end architectures, and more types of projects.
Drupal AI is moving so fast that I could have filled a whole keynote with it. Instead, we launched a new Drupal AI demo where people can experience Drupal AI for themselves. It comes preconfigured, making it easy to explore what Drupal AI can do or even show it to customers.
With the latest Drupal AI, you can ask questions and get answers grounded in your site's content. You can audit your content against brand guidelines, translate content, classify content, build pages and React components with AI, and more. Through MCP, AI assistants can work with Drupal content from outside Drupal.
What excites me most is the foundation underneath all of this. Drupal AI turns Drupal into an AI harness: organizations can connect AI models to structured content, tools, and workflows, while keeping control through permissions, guardrails, observability, metering, and a choice of AI models.
The second part of my keynote looked at another important shift: AI assistants can give people a new way to work with Drupal.
In one demo, an editor simply asked an AI assistant to unpublish a page. They didn't need to know where to click or understand Drupal's revisions, moderation workflows, or permissions. The assistant translated their intent into action, but Drupal remained in control: it checked whether the editor was allowed to unpublish the page and applied the site's publishing rules, just as it would if they had done it by hand.
If you want to see the demo in more detail, Scott Falconer, who worked on it, recorded a behind-the-scenes walkthrough showing how to set it up yourself, what happens under the hood, and how to get involved.
That demo was built on the Tool module, which I believe is one of the most important modules for Drupal developers to watch. Drupal modules already contain thousands of useful capabilities: publishing content, managing users, processing media, changing configuration, and much more. The Tool module gives developers a standard way to expose those capabilities so AI assistants and other software can discover and use them.
Today, exposing existing capabilities as tools can still require too much code. My own album module didn't expose tools, and making its existing capabilities available to an AI assistant took about 1,000 additional lines of code.
But once those tools were available, the value became obvious. Adding MCP support has already changed how I manage the more than 10,000 photos on my site. Tasks that used to take a lot of time can now be done much faster and more accurately with an AI assistant, while Drupal still manages the content, permissions, and workflows underneath.
That experience reinforced something I wrote about in AI and the great CMS unbundling: AI can take on more of the execution work while Drupal remains the control layer. I expect more organizations will want to manage parts of their sites through AI assistants. AI can make complex tasks much faster and easier without giving up the structure, governance, and safeguards that Drupal provides.
I believe thousands of module developers will eventually want to expose their capabilities in the same way, so I've been working with Matt Glaman to make it much easier. Matt has been developing a change to the Tool API that lets developers expose existing PHP methods as tools using attributes.
The idea is simple: add PHP attributes to an existing method to describe its name, purpose, inputs and outputs. In my album module, roughly 1,000 lines of integration code became about 20 attributes. My site already uses the experimental branch, and we're working to get it merged into the Tool module proper.
And this isn't only about AI. The same tools can be called by AI assistants over MCP, by other applications over HTTP, or used to generate schemas for JavaScript components and connect Drupal modules to workflow systems like ECA, FlowDrop, and Maestro. The video below shows FlowDrop using capabilities exposed by my album module:
In the last part of my keynote, I came back to Drupal's reputation gap. We can make enormous progress with Drupal, but that doesn't automatically change what people or AI agents think of it. For example, an AI coding agent I tested in June didn't even mention Drupal CMS or Site Templates when it evaluated Drupal.
Over the past few years, much of my personal focus has been on accelerating innovation in Drupal. That work is paying off, and we have real product momentum. I'm now shifting more of my attention to the other side of the equation: making sure people see what we've built, understand what has changed, and know why it matters.
So I announced the Drupal Advocacy Program, led by the Drupal Association.
Drupal already has a contribution credit system. It recognizes the people who contribute to Drupal and the organizations that support their work. For businesses, those credits also help determine visibility in the Drupal marketplace. Until now, we've been much better at recognizing technical contributions and financial support than advocacy work.
The new Drupal Advocacy Program will change that. Advocacy work can now earn contribution credit, and work that reaches people outside the existing Drupal community can earn more weight.
If we want to close Drupal's reputation gap, we can't only talk to people who already know Drupal well. We need more talks at external events, articles in broader publications, customer stories, demos, tutorials, and other work that helps people see what Drupal can do today.
Blue Drop Labs is a good example of what I mean. The day after the DriesNote, they published a post on building a website with Drupal CMS and Canvas Headless. The project itself was already live, but they quickly turned that work into a story others could learn from, with demos showing how editors and developers work with Drupal today.
That is exactly what I mean by "talking louder". There is already a lot of impressive Drupal work happening. We need to do a better job of showing it to the world.
I was a little nervous about announcing the Advocacy Program. We've wrestled with Drupal's reputation gap for a long time, and I felt we needed to do more than acknowledge it. Using contribution credit to reward advocacy was a concrete way to change the incentives, but I wasn't sure how the community would react.
It turned out to be one of the best-received announcements of the keynote. That response gave me confidence that people were ready to act on the reputation gap, not just recognize it.
You can learn how to earn Drupal advocacy credit and submit your advocacy work.
My ask is simple: talk louder about Drupal, especially to people outside our community. Drupal doesn't need hype, but we do need a better public record. We need more people showing, with real examples, what Drupal can do today.
I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Bálint Kléri, Christoph Breidert, Gábor Hojtsy, Lauri Timmanee, Matt Glaman, Michael Lander, Pamela Barone, Shibin Das, and the Drupal AI partners. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.
The Drupal Security Team is pleased to announce that four provisional members have been added as full members of the team: Pierre Rudloff (prudloff), Joseph Zhao (pandaski), Bram Driesen (bramdriesen), and Swan Kalata (akalata). Each has demonstrated their commitment, trustworthiness, and effectiveness during their provisional membership, and we're proud to welcome them as full members of the team.
Pierre is a web developer based in Lille, France, working with Insite. He has been an active Drupal project contributor and software tester since 2019 and holds over 70 security advisory credits. Pierre recently created the Drupal Security Tips repository, a valuable resource that documents recurring vulnerability patterns drawn from two years of security advisories and their associated patches.
Joseph is a solution architect and open-source developer who has been designing, building, and supporting open-source solutions since 2004. He is a prolific contributor to the Drupal ecosystem, having contributed patches, modules, themes, installation profiles, documentation, translations, and automated tests. Joseph has also reviewed project applications and serves as a mentor to newer contributors. He has been a Drupal.org community member for over 13 years.
Bram is a Drupal developer at Sopra Steria, based in Belgium, and has been an active contributor to the Drupal ecosystem since 2015. His involvement extends well beyond code: he is a co-organizer for the Drupal User Group Belgium (DUG BE) and Photography Lead for DrupalCon Europe, with experience organizing events such as the Antwerp, Ghent and Leuven DrupalCamps and Drupal Dev Days Ghent.
Swan is an Architect and Technical Lead at Tag1 Consulting, Inc., based in the United States. They have been an active Drupal community member for nearly 17 years and are a prolific contributor with credits on over 180 issues—including nearly 70 for Drupal core. Their involvement extends well beyond code: they are a community mentor and have participated in numerous international DrupalCon events.
Promoting Pierre, Joseph, Bram, and Swan to full membership strengthens our ability to review vulnerabilities, coordinate with maintainers, and improve the overall security posture of the Drupal project. They join over 20 volunteers currently on the team.
Welcome to the team, Pierre, Joseph, Bram, and Swan!
If you would like to join the team, please read how to join the Drupal Security Team.
This post is a little late. Thanks for your patience :)
AI was used in the drafting of this post. Also thanks for support from pandaski, akalata, bramdriesen, prudloff, larowlan, benjifisher, poker10, xjm, mlhess in drafting this post.
Author: Will Huggins
In enterprise digital experience, the conversation around generative AI has shifted dramatically. Digital leaders are no longer asking whether AI can write a paragraph or spin up a page. They are asking:
The release of Drupal AI 1.5 directly answers those questions.
Driven by 63 active contributors across 31 global organisations, Drupal AI 1.5 shifts the platform from one-shot text generation into an interactive, governed, and brand-safe digital experience engine.
For CMOs, Heads of Digital, and website owners, this release is not about backend developer plumbing - it is about practical marketing velocity, measurable ROI, and total brand sovereignty.
Here is a breakdown of what Drupal AI 1.5 unlocks for your digital roadmap.
Early AI chatbots suffered from digital amnesia: the second a visitor navigated to a new page or refreshed their session, their context vanished. For high-consideration purchases or complex self-service portals, this creates friction and frustrates users.
Drupal AI 1.5 introduces persistent, stateful conversation memory:
The Strategic Win: You transform your website from a static brochure into an intelligent, conversational destination that guides prospects smoothly through the conversion funnel.
For any marketing leader, the greatest fear with public-facing AI is reputational damage: a model hallucinating incorrect pricing, generating off-brand language, or leaking sensitive corporate information.
While traditional safety filters only check text after the entire response is completed—slowing down user experiences—Drupal AI 1.5 introduces active streaming guardrails:
The Strategic Win: Complete brand safety. Your legal, compliance, and IT teams get auditable, proactive safeguards built into the core publishing architecture.
Early CMS AI automations were rigid: an editor clicked an AI button, waited, and was forced to accept or discard whatever came back.
Drupal AI 1.5 turns AI Automators into an interactive creative partner inside the editing workspace:
The Strategic Win: High-velocity content operations. AI handles the first 80% of drafting and repetitive formatting, leaving your team with complete creative control over the final 20%.
If visitors cannot find the right product, resource, or service within seconds, they bounce. Traditional on-site search engines rely on exact keyword matches, frequently failing when visitors search using colloquial questions or conversational language.
Drupal AI 1.5 upgrades search into a semantic relevance engine:
One of the fastest ways to lose executive support for AI initiatives is unpredictability—unexpected API bills or black-box operations that IT cannot audit.
Drupal AI 1.5 builds transparency directly into the dashboard:
Proprietary digital experience platforms lock your organization into their single, closed-ecosystem AI model—charging heavy licensing premiums while limiting your flexibility. Lightweight headless tools offer AI writing widgets, but leave you without enterprise governance, multilingual depth, or data sovereignty.
Drupal AI 1.5 delivers the best of both worlds: model-agnostic freedom to choose the best AI for the job, visual campaign acceleration for marketing teams, and bulletproof architectural security.
👉 Download Drupal AI 1.5 today.
Reading about capabilities is one thing; seeing them transform your digital operations is another.
Explore our live interactive environments to test chatbots with memory, stream-level guardrails, and interactive content workflows:
Image: DriesNote, DrupalCon Rotterdam 2026 by Paul Johnson
Author: Jeremy Chinquist
At DrupalCon Rotterdam on September 29, 2026, Dries Buytaert used his keynote to show how far Drupal has come and who it can reach next. Dries framed the keynote around three pillars that bring Drupal's strengths to more people: multilingual (reach people in more languages), JavaScript and headless (bring more developers and applications to Drupal), and AI (give people new ways to work with Drupal).
This post zooms in on the AI pillar. For the full keynote, including digital sovereignty, multilingual, headless and the new Drupal Advocacy Program, read the official recap: DriesNote Rotterdam: Drupal is Light-Years Ahead of Its Reputation. To watch the six demos from the keynote, see Proof, not promises. Watch the six demos from the DriesNote Rotterdam.
Watch the full keynote on YouTube
Exclusive interview: James Hall sat down with Dries Buytaert for the Drupal AI Initiative. Watch it on LinkedIn
Image: James Hall, Everyone TV interviews Dries Buytaert following the DriesNote
Dominique De Cooman, Head of Partnerships for the Drupal AI Initiative, opened the conference with a short welcome and a clear message: the Drupal AI Initiative is strong and active. Dries later mentioned that over 100 people have contributed to the Drupal AI Initiative so far.
On stage, Dries showed off the demo that the Inside AI team, led by Christoph Breidert, had been developing over the past few months. "Drupal AI Demo: Northmoor University" is a complete university website that shows Drupal AI at work on realistic content. Anyone can try it today at drupal.org/ai/demo. To learn how the demo was built and what it can do, read Christoph's announcement: Introducing the Drupal AI Demo.
Five parts of the demo were highlighted during the talk:
Did you know?
Aidan Foster also used the demo site in the presentation "Encoding Expertise: How UX Research Powers Human-First AI" to show how AI guidelines can help review a site's content.
Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)
What this means for you: for agencies and site owners, this is the quickest way to see Drupal AI on a real site before planning a project. The guardrails matter as much as the features: the AI flags, drafts and cites, and people decide what gets published.
Dries showed AI-assisted development for Drupal Canvas. Given a prompt such as "Build a content template for my articles," the AI assistant checks its work against Canvas Workbench, ESLint and the Canvas CLI. The result is a set of simple template files, pushed to the site with the Canvas CLI.
What this means for you: front-end developers can let an AI assistant write the first draft while Canvas' own tooling validates the result.
Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)
Today, exposing a Drupal module's features to AI assistants via MCP takes around 1,000 lines of code. Dries showed a prototype that brings this down to around 20 PHP attributes, using a recipe that combines the Simple OAuth, MCP Server and Tool API modules. The principle is "describe once, use in multiple places": one description of a capability serves AI assistants, workflow tools and JavaScript components alike.
In the demo, a FindImages tool lets an AI assistant look up images on the site, with FlowDrop connecting the pieces.
What this means for you: this is a prototype, not a release. For module maintainers, it points to a future where one description makes a module usable by AI assistants.
Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)
The next step is the Rosetta Sprint: a four-day sprint with key maintainers to describe Drupal's capabilities once, in a form that AI agents, other systems and humans can all read. The goal is to make Drupal's data and capabilities easier to expose to AI agents, orchestration tools, frontends and more. The date and location are still to be announced.
Did you know?
Kristen Pol used the Drupal AI Demo to record the demo clips for her session "Context Control Center: Bringing AI Context to Drupal CMS." Curious how Drupal gives AI the right context? Take a look.
Dries closed with a clear request: "Here is my ask: Talk louder about Drupal." Try the demo, share what you build with Drupal AI and join the Drupal Advocacy Program.
Image: Karl Hepworth (DriesNote, DrupalCon Rotterdam 2026)
During the keynote, Dries thanked the Drupal AI Partners, the organizations that back the Drupal AI Initiative. Want your organization to join them? Become a partner.
Image: Drupal Association (DriesNote, DrupalCon Rotterdam 2026)
Author: Christoph Breidert, Product Lead, Drupal AI
Earlier this year, the Drupal AI Initiative set itself a clear goal: at DrupalCon Rotterdam, show one Drupal site where AI search, content review, chat-driven editing, and AI translation all work together on real content. Today we are delivering on that promise. The Drupal AI Demo is live, and Dries revealed it in the Driesnote.
You can open it, use it, and see for yourself what Drupal AI looks like when it is built as a complete product. The demo is the website of a fictional university, with the kind of content and structure a real organization's site would have.
The Drupal AI Demo: a realistic, multilingual university website where every AI feature runs on the same content
Until now, Drupal AI has mostly been something we described. We had roadmaps, feature lists, module pages, and conference talks. All of that was accurate, but none of it was tangible. A list of features asks people to imagine how the pieces fit together. A demo lets them see it.
That difference matters to two groups of people in particular.
If you are evaluating Drupal, the demo lets you test the AI features instead of reading about them. I believe Drupal is the most powerful AI-powered CMS available today. Until now, that was a claim you had to take on trust. Now you can check it yourself, try the features on realistic content, and plan your own website around capabilities that are already implemented and working.
If you already build with Drupal AI, the demo shows how each feature is intended to be used. You can evaluate every feature, see how it is configured, and adapt that setup to your own use case. That is a much better starting point than piecing together a feature from documentation alone.
The demo focuses on the features our Drupal AI Partners told us matter most. In May, we asked them which capabilities they most wanted to have ready to use in Drupal. They are at the heart of the demo.
AI content reviews. Check a page against criteria like brand voice, legal requirements, and reading level, and get concrete suggestions for improving it.
AI content review scores a page against brand, legal, and readability criteria and suggests concrete improvements
AI search. Ask a question and get an AI-generated answer, grounded in the site's own content and with the sources behind it.
AI search answers a question with a summary, the sources behind it, and ranked results from the site's own content
Chat-driven content editing. Describe what you want to change, and the AI edits the page for you, right inside the editing experience.
Chat-driven editing: an editor describes a change in the chat, and the AI updates the page directly
AI translation. Move content across languages, with results good enough to publish.
AI translation moves a page into another language, ready for review and publishing
Connect your own AI agents. Connect agents such as Claude, ChatGPT, and others to Drupal through MCP, and make changes to the website from the outside.
An external AI agent, connected through MCP, making a change on the demo website
What makes the demo different from trying these features one at a time is that they all run together on the same site and the same content. That is what building a real website involves, and it is where the hardest work was.
The idea of a demo was always there. We knew from the start that Drupal AI would need one, but first we needed a foundation strong enough to build it on.
The official Drupal AI sprints started in January this year. We spent the first three months refining the core AI functionality. By the second quarter, we had a stable code base to build on. In May, we ran the partner survey, and that was the moment the demo became a shared goal. The partners bought into the idea, and together we agreed on the features it should show. June went into preparation. In July, we started building.
The last eight weeks were the most intense. Between 1 August and 26 September alone:
Activity grew steadily over those weeks, from about 70 commits in the first week of August to more than 300 per week in September. And the part I am most proud of is not the size of those numbers. It is that the result simply works.
Weekly commits across the demo and the drupal.org projects it builds on, 1 August to 26 September 2026
The demo was built by contributors from across the Drupal AI Partners, the organizations that fund and staff this initiative, together with many contributors from the wider Drupal community. Working together, we could build a more advanced AI experience than any of us could have built alone, and everything we build for the demo makes Drupal AI better for everyone who uses it.
Most of the load of the demo itself was carried by four people: Marcus Johansson, Artem Dmitriiev, Aidan Foster, and myself. Marcus, Artem, and I also met in person for three days to do nothing but sprint on the demo. Some of the hardest problems got solved in that room.
Marcus Johansson, Artem Dmitriiev, and Christoph Breidert during their three-day, in-person demo sprint
Many others did substantial work on the demo itself. I want to thank Darren Oh, Kristen Pol, Abhisek Mazumdar, Dan Lemon, Eric Homanchuk, Akhil Babu, and Kiran Kadam.
Of course, a demo is only as good as the modules underneath it, and many projects were heavily developed to be ready for Rotterdam. The main contributors there include Giorgio Alfredo Pagano on AI Disclosure, Michael Lander and Matt Glaman on the Tool API, MCP Server, and Canvas tools, Kristen Pol on AI Context, Rob Loach, Scott Euser on AI Search, Ahmad Khader on AI Content Review, and Sven Decabooter on AI Translate. Much of this work also depended on review: Artem and Marcus alone merged more than 100 merge requests from other contributors in these two months.
Coordinating a distributed effort of this size, with contributors across many organizations, countries, and time zones, in such a short time is its own kind of challenge. My role was to set the direction, define the work packages, and align with key contributors and organizers to make sure we were building the right things. I also reviewed a great deal of work along the way. The day-to-day operations were led by our delivery managers, Arian Raeesi and Vidit Anjaria, who planned the work into sprints and kept it moving every day.
What I had never seen before is so many people building something together that actually works as one. Being part of that is amazing.
The demo was something I had in my head for a long time. Seeing so many people take that idea and make it real, and seeing it work, is one of the most rewarding experiences I have had in the Drupal community.
To everyone who contributed: thank you. This demo is yours.
The demo is live at drupal.org/ai/demo. Try it, test it, and tell us what you think.
If you want to help shape what comes next, join us in the #ai-initiative channel on Drupal Slack, or explore becoming a Drupal AI Partner.
Abhinav Jha, Abhisek Mazumdar, Abhishek Dhariwal, Adam G-H, Adrian McKee, Ahmad Khader, Ahmad Khalil, Aidan Foster, Akhil Babu, Alex Urevick-Ackelsberg, Andrei Mateescu, Andrii Sakhaniuk, Angela Saldaña, Anikó Viola, Ann Mary Sruthy, arne michiels, Artem Dmitriiev, Ashish Dalvi, attilatilman, Avinash jha, Bharat Kelotra, Brooke Mahoney, Bruna Emerich, Bruno Bruno, calmforce, Carlos Romero, Cesar Miquel, Chad Peppers, Christian Burk, Christoph Breidert, Craig Wood, Dan Goodwin, Dan Lemon, Daniel Rodriguez, Darren Oh, Dave Long, David Bravo, Denise Spangler, Dezső Biczó, Dimitris Spachos, Dries Buytaert, Emma Horrell, Eric Homanchuk, George Kastanis, Giorgio Alfredo Pagano, Ignacio Pérez Puertas, István Csáki, Jeff Warrington, Jeremy Cerda, Jibran Ijaz, Joonas Meriläinen, Jordan Graham, JoshHayter, Joshua Fernandes, Juan Correa, Jurriaan Roelofs, Jérôme Tchania, Jürgen Haas, Kenneth Bolívar Castro, Kieran Cott, Kiran Kadam, KJ Monahan, Konstantine Kirkitadze, Kristen Pol, Lee Rowlands, Levente Besenyei, Manuel Garcia, Marcus Johansson, Markus Kalkbrenner, Mateu Aguiló Bosch, Matt Glaman, Matthew Tift, Michael Lander, Miguel Guerreiro, Narendra Singh Rathore, Nick Opris, Nick Pasiuk, Nik LePage, Norman Kämper-Leymann, Pieter Frenssen, Prabhavathi Vanipenta, Pravesh Poonia, Punam Aseem Beedkar, Reinhold Schachner, Ricardo Castañeda, Richard Porter, Rob Loach, Rodel Duterte, scontzen, Scott Euser, Scott Falconer, Sergiu Nagailic, Shashank Rai, Shibin Das, Shivam Sen, Simon Morvan, Sven Decabooter, szato, Tamas Balog, Tekla Aivazashvili, Tormi Tabor, tribekk, Valery Lourie, Will Huggins, Wolfgang Ziegler.
The DriesNote at DrupalCon Rotterdam made one argument above all: Drupal is light-years ahead of its reputation. The strongest evidence was on screen. These six demos show a platform that speaks more languages, welcomes JavaScript developers as first-class citizens, and treats AI assistants as another interface to Drupal, with governance built in.
Everything here is open source and available today. Here are the demos, with the story behind each one.
80% of the world doesn't speak English as a first or second language, so multilingual is how Drupal reaches billions more people. Two things used to hold teams back: setup was hard, and Drupal Canvas didn't yet support multilingual content. Drupal CMS 2.2 changes both, with a language selector right in the installer, a guided Multilingual add-on, three levels of translation configurability, and full translation support in Canvas, including review workflows and optional AI translation. Watch for Dashi, a multilingual food magazine template made entirely by Drupalers.
JavaScript front ends are where many developers start their careers, and Canvas is built for them: a standalone front-end project scaffolded in one command, with React, TypeScript, and Tailwind CSS, previews via Canvas Workbench with zero configuration, and AI coding agents in the workflow. One push with the Canvas CLI and everything is ready for content teams to use visually. No Drupalisms, no trade-offs.
Organisations often compose experiences from multiple backends, and that calls for a headless front end. Canvas Headless connects yours by configuring a URL, with Canvas visual editing built in: editors see a live preview of the real application while developers build in the framework they prefer. Starter templates cover Next.js, Astro, Nuxt, and TanStack Start, and Angular support arrived the very week of the keynote, five frameworks in all.
There's been so much Drupal AI work that demoing it all would fill the keynote. Instead, there's now a demo experience anyone can try: a fictional university site where AI reviews every page against your standards, visitors get answers drawn from your own content with sources shown, and guardrails, a central knowledge hub, and full logging keep it accountable. It's working today, open source, built by leading Drupal AI companies, and pre-configured so you can also use it to show customers. Try it at drupal.org/ai/demo.
A content editor spots Dutch translations showing prices that shouldn't be live yet. From ChatGPT, connected with her own account, she asks for the previous Dutch versions back, English untouched. It happens, with every change recorded as a new revision under her name. She didn't need to know where to click or how revisions, moderation, and permissions work; Drupal handled the governance behind the scenes. You can do this today with a recipe combining Simple OAuth, MCP Server, and the Tool module, built by Michael Lander, Matt Glaman, and others: drupal.org/project/agent_access
The most surprising demo wasn't about AI at all. Dries's personal site holds more than 10,000 photos in a custom album module he tool-enabled himself, the work behind his "describe once, use everywhere" idea. The creator of FlowDrop, a visual workflow tool for Drupal, showed that module's MCP server powering a plain form, searching photos and albums with no AI anywhere, and then an agent that chooses its own tools to answer questions. When capabilities are described once and answers come back structured, AI becomes a choice, not a requirement. That idea is what the upcoming Rosetta Sprint will take forward.
Watch the DriesNote in full, or read the full recap of everything Dries announced, from digital sovereignty to the Drupal Advocacy Program.
