A few years ago I said Drupal needed infrastructure innovation, and I finally took the time to do something about it. While I really like DDEV, I'm really not a fan of having to use Docker for everything so I'm trying to do something about it.
European Digital Identity Wallets are moving from technical framework and pilot programmes towards services that people will be able to use across the European Union. The European Commission says Member States must make wallets available to citizens, residents, and businesses by the end of 2026. For Drupal teams, that makes digital identity less a future policy topic and more an application-architecture question.
The wallet model changes what an online service can ask a user to prove. Instead of treating identity as one complete profile, users can present particular identity data or attestations and disclose only the information required for a transaction. Commission figures say more than 550 companies and public authorities across 26 Member States, Norway, Iceland, and Ukraine are participating in large-scale pilots covering government services, banking, education, health, transport, telecommunications, and other uses.
The relevant role for a Drupal application is the relying party. Under the European framework, organisations that use wallets for digital services must register their intended use and indicate the data they plan to request. That puts the request itself inside a defined trust and registration model rather than leaving every application to decide independently what identity information it wants to collect.
The technical exchange is also more specific than adding another login provider. For remote presentation flows, the EUDI architecture uses OpenID for Verifiable Presentations to carry requests and wallet responses between wallets and relying parties. A Drupal service could potentially use a validated result from that layer for authentication, account linking, permissions, eligibility checks, or workflow decisions, but the material reviewed for this issue does not establish a production-ready Drupal integration that provides those functions today.
Data handling may prove more consequential than authentication itself. A wallet may be able to prove that a person has a particular attribute without requiring the service to collect a larger identity record, and the European framework is designed around data minimisation and selective disclosure. The application still has to decide what happens next: whether the verified attribute becomes persistent Drupal user data, whether only a derived result is retained, or whether the information can disappear once the transaction has been completed.
Those decisions sit above the wallet protocol. Drupal already provides accounts, permissions, fields, workflows, access rules, logging, and application-specific data models, but none of those automatically determine which verified identity attributes an organisation should retain. Connecting a verifier to Drupal therefore solves only part of the problem; the rest belongs to application design, data governance, and the legal requirements of the service being built.
The EUDI technical framework is still developing as deployment approaches. Version 3.0.0 of the EUDI Wallet Architecture and Reference Framework, published in July 2026, updates Wallet-Relying Party registration and introduces the concept of Relying Party Services alongside other changes. For Drupal projects in European government, education, and other identity-sensitive environments, the question is not simply how Drupal accepts a wallet, but which verified facts the application actually needs after the wallet has done its job.
Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.
Kazima Abbas wrote and curated this issue of Editor’s Pick.
read moreEvery update on a multilingual Drupal site must reach each market language - not just the source page.
Drupal multilingual websites can use AI-assisted translation drafts inside Content Translation workflows so editors review and publish without copying text between tools. Maciej Lukianski explains shared fields, editorial ownership, document links, and keeping localized pages consistent for people and AI search.
read moreThis is the first post in a three-part series about the impact of the AWS Open Source Credits program on the Drupal community. Part one covers our testing infrastructure. Part two will cover the community programs we host beyond code. Part three will cover what the AI era is doing to open source infrastructure, and what we're building next.
Drupal is one of the open web's longest-running content management projects, in continuous development since 2001, and a recognized Digital Public Good. It runs a large share of the public web: government portals, universities, hospitals, cultural institutions, and international organizations, including the European Commission and agencies across the UN system. The Drupal Association is the small non-profit that keeps the project's home online. We build the tools that enable our community to build Drupal.
Since 2025, the AWS Open Source Credits program has supported the infrastructure behind that work. This series is our thank you, and impact report about what that support has made possible.
Drupal's collaboration happens on git.drupalcode.org, our self-hosted GitLab instance and one of the largest in open source. It hosts 42,382 contributed projects: 39,003 modules, 2,400 themes, and 979 distributions, alongside Drupal core itself.
The Drupal community opens more than 5,300 merge requests every month, about 65,000 a year, from 8,000 unique contributors annually. Drupal core alone has 15,256 issue forks.
Every one of those merge requests runs through continuous integration (CI) before it can ship. Our GitLab CI runners autoscale on AWS, accounting for roughly a third of our entire cloud footprint. In the last year they executed ~4.1 million jobs, consuming ~159.8 thousand compute hours. That's 438 hours of compute per day. (Data from Aug 26, 2025 – Aug 26, 2026).
Here's what autoscaling CI means for a community like ours. A contributor in Singapore, Mumbai, or Rotterdam pushes a change and gets test results back in minutes. There is no fixed pool of test machines, no queue where contributors wait on each other, no rationing of who gets to test what.
If elastic capacity, funded by credits, means those contributors have never had to deal with longer queues, capped concurrency, or asking volunteers to test less..
We care about this because contributor velocity is essential to the success of Drupal. The Drupal Association engineering team is small, just 4 people. We don't build Drupal; thousands of people do that. Our job is to make sure the tools are available and fast when they need them.
It would be easy to frame fast CI as a developer-happiness story and stop there. But for a project with Drupal's footprint, that same infrastructure is a safety system.
In the last twelve months, the Drupal Security Team has coordinated 163 security advisories across core and contributed projects. Every fix behind those advisories was developed, tested, and released through the same AWS-powered pipeline as any other change. The sites that depend on those fixes find out through us too: about 667,000 Drupal sites check in with our update infrastructure every week to learn whether they need to act. That's a conservative floor, since it only counts sites that phone home.
We also operate Drupal Steward, a protective service that shields sites during the most dangerous window in security response: the hours between a public advisory and a site's own patching. AWS powers that too.
Drupal powers governments, public utilities, and health systems worldwide, making our testing pipeline critical public infrastructure. Every automated test directly protects the security and stability of the websites people rely on daily.
For two decades, much of Drupal's infrastructure ran on donated hosting at the Oregon State University Open Source Lab, which has been a quiet hero to dozens of open source projects. As the lab restructures, we have been migrating essential services to AWS. Credit support meant that migration happened without cutting contributor capacity, and without asking a small non-profit engineering team to do more with less at the worst possible moment.
Our thanks to the OSU Open Source Lab for twenty years of partnership, and to AWS for making this next chapter possible.
While compute numbers show our scale, the human impact matters just as much., In our next post: the community programs we host that have nothing to do with code, and why we think that infrastructure matters just as much.
The Drupal Association is a 501(c)(3) non-profit. If your organization depends on Drupal, or on the health of open source infrastructure generally, you can support our work.
This is the first post in a three-part series about the impact of the AWS Open Source Credits program on the Drupal community. Part one covers our testing infrastructure. Part two will cover the community programs we host beyond code. Part three will cover what the AI era is doing to open source infrastructure, and what we're building next.
Drupal is one of the open web's longest-running content management projects, in continuous development since 2001, and a recognized Digital Public Good. It runs a large share of the public web: government portals, universities, hospitals, cultural institutions, and international organizations, including the European Commission and agencies across the UN system. The Drupal Association is the small non-profit that keeps the project's home online. We build the tools that enable our community to build Drupal.
Since 2025, the AWS Open Source Credits program has supported the infrastructure behind that work. This series is our thank you, and impact report about what that support has made possible.
Drupal's collaboration happens on git.drupalcode.org, our self-hosted GitLab instance and one of the largest in open source. It hosts 42,382 contributed projects: 39,003 modules, 2,400 themes, and 979 distributions, alongside Drupal core itself.
The Drupal community opens more than 5,300 merge requests every month, about 65,000 a year, from 8,000 unique contributors annually. Drupal core alone has 15,256 issue forks.
Every one of those merge requests runs through continuous integration (CI) before it can ship. Our GitLab CI runners autoscale on AWS, accounting for roughly a third of our entire cloud footprint. In the last year they executed ~4.1 million jobs, consuming ~159.8 thousand compute hours. That's 438 hours of compute per day. (Data from Aug 26, 2025 – Aug 26, 2026).
Here's what autoscaling CI means for a community like ours. A contributor in Singapore, Mumbai, or Rotterdam pushes a change and gets test results back in minutes. There is no fixed pool of test machines, no queue where contributors wait on each other, no rationing of who gets to test what.
If elastic capacity, funded by credits, means those contributors have never had to deal with longer queues, capped concurrency, or asking volunteers to test less..
We care about this because contributor velocity is essential to the success of Drupal. The Drupal Association engineering team is small, just 4 people. We don't build Drupal; thousands of people do that. Our job is to make sure the tools are available and fast when they need them.
It would be easy to frame fast CI as a developer-happiness story and stop there. But for a project with Drupal's footprint, that same infrastructure is a safety system.
In the last twelve months, the Drupal Security Team has coordinated 163 security advisories across core and contributed projects. Every fix behind those advisories was developed, tested, and released through the same AWS-powered pipeline as any other change. The sites that depend on those fixes find out through us too: about 667,000 Drupal sites check in with our update infrastructure every week to learn whether they need to act. That's a conservative floor, since it only counts sites that phone home.
We also operate Drupal Steward, a protective service that shields sites during the most dangerous window in security response: the hours between a public advisory and a site's own patching. AWS powers that too.
Drupal powers governments, public utilities, and health systems worldwide, making our testing pipeline critical public infrastructure. Every automated test directly protects the security and stability of the websites people rely on daily.
For two decades, much of Drupal's infrastructure ran on donated hosting at the Oregon State University Open Source Lab, which has been a quiet hero to dozens of open source projects. As the lab restructures, we have been migrating essential services to AWS. Credit support meant that migration happened without cutting contributor capacity, and without asking a small non-profit engineering team to do more with less at the worst possible moment.
Our thanks to the OSU Open Source Lab for twenty years of partnership, and to AWS for making this next chapter possible.
While compute numbers show our scale, the human impact matters just as much., In our next post: the community programs we host that have nothing to do with code, and why we think that infrastructure matters just as much.
The Drupal Association is a 501(c)(3) non-profit. If your organization depends on Drupal, or on the health of open source infrastructure generally, you can support our work.
Your marketing team already knows who the VIPs are. They maintain the segment in Mautic, they send it a campaign every month, they add and remove people as orders and behaviour change. Then somebody asks for a VIP banner on the website, and the website turns out to know nothing about any of it. So "VIP" gets built a second time, as a Drupal role or a checkbox on the user: two definitions of the same audience, maintained by two teams, drifting apart from the first week.
The second problem arrives with the first. Personalisation on Drupal usually means varying the page per visitor, and a page that varies per visitor is a page nobody else can be served, so the banner meant to lift conversion ends up slowing the site down for everyone.
We build and run Mautic-driven marketing for our e-commerce clients, so we kept meeting both problems on the same projects. Mautic Audiences is our answer, now on drupal.org as free software (GPL-2.0-or-later) for Drupal 10.3 and 11, covered by Drupal's security advisory policy. It reads the segments and tags you already maintain in Mautic and turns them into native Drupal primitives: block visibility, Twig, tokens, JavaScript, Views, Search API and, since 1.1, a field.
Place any block, scroll to Visibility, pick Mautic segment, type vip. Save. That is the whole configuration, and it covers most of what people actually ask for:
newsletter, instagram and paid-search, each gated on its own segment.subscriber.coupon:* tag, fired client-side so the page itself stays cacheable at the edge.Anonymous visitors count: someone carrying Mautic's tracking cookie has an audience with no login, which is what lets a campaign link open a personalised page at all. Editors check their work by appending ?ma_preview_segments=vip to any URL, which shows the site as a member of that segment sees it.
Themers get the same decision as a one-liner that brings its own cache metadata, and there is a token for metatag patterns and a JavaScript call for whatever has to happen after the page is served:
{% if is_in_segment('vip') %}
<p>Free shipping today, your VIP perk.</p>
{% endif %}
The module started by answering "who is this visitor?". Version 1.1 adds the other half, "who is this content for?", in a bundled sub-module.
Add the Mautic audience field to any bundle and editors pick, from the real list of segment names, who a piece of content is meant for. By default that is a targeting hint templates and listings read. Per field, you can turn on Restrict viewing to the selected Mautic segments, and content with a segment picked is then refused to everyone outside it. Content with nothing picked stays for everyone.
A gate that only closes the page is not a gate, so the sub-module also ships a Views filter that keeps whichever rows each visitor is entitled to, and a Search API processor that adds the condition at query time rather than keeping items out of the index. Its README lists what none of it can cover, exports, feeds, custom code that loads entities without an access check, because a promise of restriction with holes in it is worse than no promise.
Segment names and tags are business intelligence: cancelled-subscription, risk:churn-90d, coupon:VIP-50. Ship them to the browser and you have published how you categorise your customers, and sometimes a working coupon code, to anyone with DevTools open.
So the client-side API answers questions instead of listing facts. It will tell you whether this visitor is in a segment you name; it will not tell you which segments exist or which ones they are in. The endpoint that returns an actual list starts empty and returns only what an editor has allowlisted. The field type has no formatter at all, and reading its values takes an administrative permission, which covers JSON:API, REST and Views alike.
Audiences are read from local storage on every render, never from the Mautic API, so a slow Mautic never sits in front of a page, and an outage degrades to an empty audience rather than an error. Cache contexts key on the resolved audience rather than on the visitor, so two people in the same segments share a cache entry and a page with two gated blocks has four variants, not one per visitor. Anonymous personalisation does cost you Drupal's Internal Page Cache on the pages that use it, which docs/cdn.md deals with head on.
composer require drupal/mautic_audiences
drush en mautic_audiences
It needs Advanced Mautic Integration for API connectivity, a Mautic instance with API credentials, and PHP 8.2 or later. A bundled sub-module wires Klaro into the resolver, so visitors who have not consented resolve to an empty audience without any code.
The project page, the issue queue and the documentation are at drupal.org/project/mautic_audiences. If you run Drupal Commerce, Commerce Mautic Connect pushes the abandoned carts, customer metrics and coupon tags into Mautic that this module reads back. Issues and merge requests are very welcome.
There will be a security release for a widely used contributed module on September 23, 2026 between 17:00 and 21:00 UTC.
We are announcing this release in advance because the affected contributed module is used on a significant portion of Drupal sites, and the upcoming release will include a significant number of advisories. The advisory with the highest risk score for the release is currently rated as critical.
Drupal core is not affected.
The current rate of advisories may require changes to our practices going forward:
These changes are intended to make the process easier for the team and to make communication from the team easier to follow.
The planned update does not require special release procedures.
Snapshots have been a beloved feature of DDEV for years, but in v1.25.4 there is so much more.
Read on (or watch, or both) to see:
seed snapshot to automatically provide content to a project on first startA DDEV snapshot is a physical, "hot" backup of your database — mariadb-backup/xtrabackup for MariaDB and MySQL, or pg_basebackup for Postgres — not a text-based mysqldump. Because it copies the database's on-disk files instead of dumping SQL statements, it's much faster to create and restore, especially on large databases. All the basics about snapshots are in the docs.
Normally snapshots live in .ddev/db_snapshots/, and the filename encodes the database type and version, for example mariadb_11.8. That's why a snapshot only restores against a matching engine and version — restoring a mariadb_11.8 snapshot into a mariadb_10.11 project will fail.
Snapshots are compressed with zstd by default. --uncompressed skips the decompression step on restore, trading a much larger file on disk for a faster restore. Postgres doesn't support uncompressed snapshots.
ddev snapshot --name=<name> — create a snapshotddev snapshot restore — opens a TUI allowing you to select snapshot to restoreddev snapshot restore <name> — restore a named snapshotddev snapshot restore --latest — restore the most recent snapshotddev snapshot restore $HOME/tmp/mysnapshot-mariadb_11.8.zst — restore from an arbitrary path, not from the default .ddev/db_snapshots/ddev snapshot --list (-l) — table of snapshot name, created date, size, database version, and compression; shows a Worktree column when relevantddev snapshot --cleanup (-C) — delete one snapshot (--name=<name>) or all of them (prompts for confirmation unless -y)ddev snapshot --all (-a) — snapshot all projects (automatically starts stopped projects to accomplish this)If your project has multiple Git worktrees, snapshots taken from other worktrees of the same repository are available too — by name, with --latest, or through the interactive list.
Take a snapshot before each step of a migration or update: ddev snapshot --name=pre-migration-step3. If a step breaks something, restore the last good snapshot instead of restarting the migration from scratch. (ddev snapshot restore --latest can be a great technique if you do this religiously.)
ddev snapshot --list becomes a log of checkpoints, and ddev snapshot restore <name> or restore --latest jumps back to any of them instantly.
This builds on the workflow described in DDEV Database Management: snapshot, ddev restart --reset-database, restore. It's also a natural lead-in to seeding a new database volume directly from a snapshot, covered next.
seed SnapshotDDEV projects have always automatically created a database named db to help you get started fast. But it's been an empty database, with no content. Now, in DDEV v1.25.4+, the seed snapshot has been added. You can create a snapshot named seed (with whatever content you want) and when somebody starts up a project for the first time, the content on the seed snapshot will automatically be loaded. You can even check the snapshot named seed into your Git repository if you don't object to its size, and it can help folks new to the project to get started that much faster. (The seed snapshot is only used when there is no database; your changes to the database are kept as always.)
To add the seed snapshot to Git:
git add -f .ddev/db_snapshots/seed-*
git commit -m "Add default seed db for clean startup"
--seed-snapshotIf you want to start a project with an alternate seed snapshot, ddev start and ddev restart accept --seed-snapshot=<name-or-path>, which seeds the database volume from a snapshot instead of the stock seed database. This only applies when there's no existing database — DDEV errors otherwise, telling you to add --reset-database or use ddev snapshot restore.
<name-or-path> can be a short name from .ddev/db_snapshots/ or a full path:
ddev start --seed-snapshot=$HOME/tmp/mysnapshot-mariadb_11.8.zst
This works for every database type DDEV supports, unlike the baked-dbimage technique below, which is MariaDB/MySQL-only — it's restored the same way ddev snapshot restore does, just at volume-creation time.
Combine --seed-snapshot with --reset-database to reseed an existing project in one step:
ddev restart --reset-database --seed-snapshot=<name> -Oy
-O (--omit-snapshot) skips the automatic snapshot save of the database being thrown away, and -y skips the confirmation prompt.
This is the lightweight alternative to baking a seeded database image: no custom image or registry, just a snapshot file — good for local or small-team use where a shared registry is overkill.
--reset-databaseOnce you have a seed snapshot, ddev restart --reset-database -Oy repeatedly returns the project to that known-good state — handy between test runs.
You can also create a replacement database image that has an alternate seed database built into it. This is especially great for delivering huge databases, as the process can be handled by the image, or an upstream process. All the image building does is copy a base_db.zst or base_db.mbstream into the /mysqlbase/custom directory of the DB image.
For teams that want to share a ready-to-go database via a Docker image registry instead of a snapshot file, build-and-push-seeded-image.sh is an example that builds a real multi-arch (linux/AMD64, linux/ARM64) image with a snapshot baked in:
build-and-push-seeded-image.sh --snapshot=uncompressed-2g \
--output-image=randyfay/uncompressed-2g:v1.25.4 --push \
--base-image=ddev/ddev-dbserver-mariadb-11.8:v1.25.4
This technique relies on mariadb-backup/xtrabackup, so it doesn't support Postgres.
Uncompressed seeds make for a much larger image and a slower push, but a faster, decompress-free container startup. It's worth comparing the actual image sizes to see the bandwidth cost of each trade-off.
dbimage:Point a project at the seeded image using dbimage in .ddev/config.yaml (or .ddev/config.local.yaml):
# .ddev/config.yaml or .ddev/config.db.yaml or .ddev/config.local.yaml
# Example dbimage
dbimage: randyfay/uncompressed-2g:v1.25.4
Then:
ddev restart --reset-database --omit-snapshot -y
build-and-push-seeded-image.sh --snapshot=seed --output-image=randyfay/d11_normal:v1.25.4 --push --base-image=ddev/ddev-dbserver-mariadb-11.8:v1.25.4This article was edited and refined with assistance from Claude Code.
read moreReposted from Acquia with permission from Acquia. Authored by Martin Anderson-Clutz (mandclu)
What changes when an agent stops reading your content and starts writing it?
For the last two years, the conversation about AI and content has mostly been about reading. Retrieval, summarization, a chatbot that answers a question from your knowledge base. That problem is largely solved, and it is solved almost everywhere. Any serious platform can find a relevant paragraph and hand it back.
The shift that actually changes the job of a content platform is quieter. Agents have moved from "answer my question" to "do the work." They are no longer only reading your content. They are starting to write it, assembling pages and populating components and publishing the result. The category we have called content management for twenty years was built for the first job. It was never asked to do the second.
At this point a fair objection turns up: is this not exactly why we keep a human in the loop? It is. Any content platform worth running in an enterprise keeps a person between the agent and the published page. A system that lets an agent push unreviewed work straight to production is not showing you the risk of agentic content. It is showing you that it was never built for the enterprise to begin with.
So the risk worth talking about is not the rogue page. Review catches that. The risk is waste.
A read and a write still fail in opposite directions, and the cost is what separates them. When a retrieval system returns a weak answer, one person spends a moment sorting it out and moves on. When an agent produces a weak write, a layout that misses the brand or a component wired to the wrong relationship or a draft that ignored a business rule, someone has to notice it, correct it, and often send it back to be generated again. Every one of those steps costs the reviewer's time and burns the tokens that produced the work in the first place.
That cost lands on the exact person the agent was supposed to help. The promise of agentic content is leverage, so the specialist spends their time on judgment instead of assembly. A guessing agent quietly reverses the trade. Rather than assembling the page themselves, the reviewer now inspects a draft they did not write. They hunt for the places it went wrong and explain what to change. That is not leverage. It is rework wearing the costume of automation, and it scales the wrong way, because an agent that guesses does not guess once. It guesses across every draft, at machine volume.
This is why context is the whole game. A human in the loop is cheap when the work in front of them is already right, and expensive when it is not. Give the agent structured, governed context and the review step becomes a quick yes. Hand it flat fields and hope, and the review step becomes the job you were trying to automate, now done twice.
It helps to look at what actually changed, because the content platform has served three different consumers over its life.
| Content Management System | Headless and Composable | Agentic Content Platform | |
|---|---|---|---|
| Primary consumer | A person in a browser | A front end serving a person | Software that acts |
| Content flows | Outward, to one presentation | Outward, to many presentations | In both directions |
| How editorial judgment is applied | By hand, page by page | By hand, page by page | Encoded as context up front, confirmed at review |
| Measure of success | Editorial autonomy | Reuse across channels | Safe, accountable machine action |
For most of that history, judgment stayed with the editor. The system stored content and rendered it, while a person decided what was true, what was on-brand, and what was ready to publish. Headless moved content to more places, but it did not move that responsibility. A human still stood between the content and the world.
Agentic content management changes that. The agent now does the assembly the editor used to do, which means the judgment the editor brought to the work has to come from somewhere. A platform that carries it, with the business rules and the content relationships and the standards for what good looks like, hands the reviewer a draft that already reflects those things. A platform that cannot leaves every one of those calls for the person to supply by hand, one draft at a time. The judgment does not disappear. It moves back onto the reviewer the agent was supposed to free.
Here is the line most tooling blurs, and the reason so many agentic demos fall apart the moment they meet a real enterprise. Content is not context.
Content is what you publish: the page, the article, the product description, the campaign.
Context is everything an agent draws on to produce that content safely. Your brand voice. Your content model. Your business rules, your reference material, and the relationships that connect all of it. Context is what turns a vague prompt into a result the organization would actually stand behind.
Most systems collapse the two. They hand an agent a set of flat fields and hope it infers the rest: the tone, the relationships, the governance that always lived in the editor's head. Guessing works beautifully in a demo and breaks in production, because the fields never carried the context to begin with. The agent was handed the output and asked to reconstruct the reasoning behind it.
Treating context as a governed layer of its own, with clear owners, review, version history, and scope, is what separates an agent that produces a plausible draft from one an enterprise can trust to publish. The prompt gets simpler. The result gets more accountable. The organization decides in advance what the agent is allowed to know and do.
Here the shape of the underlying system stops being an implementation detail and becomes the whole question.
An agent that writes needs things the read era never demanded. It needs to see the page as a structure it can reason about, with components, order, and resolved values, rather than a wall of markup it has to pattern-match. It needs to work inside the governance that already exists, the roles and permissions and workflows the organization spent years getting right, instead of routing around them. And it needs its output to land in a reviewable state, with a record of who initiated the work and what produced it, so a person can still say yes or no before anyone sees it. Structured context is what makes that review a quick confirmation rather than a second round of work.
None of that can be added after the fact. A platform that stores content as flat, disconnected fields cannot suddenly expose relationships it never modeled. A platform with shallow governance cannot suddenly supervise an agent it was never designed to hold. These are properties of the foundation. Either the structured content and the mature governance are already there, or you are trying to pour a footing under a building that already stands.
For years, careful content modeling and granular governance were treated as overhead, the slow and unglamorous work that held teams back. The agentic era inverts that. The same rigor is now what lets a team move quickly and safely at once, because it is exactly what an agent needs in order to act without guessing.
Plenty of tools can turn a prompt into a layout now. That trick is becoming table stakes, and it is the wrong thing to be dazzled by. The real question is whether the layout that comes back is on-brand, relevant, usable on the devices your audience actually reaches for, and built on terms you control. The answer depends on the foundation under the prompt, and that is what Drupal Canvas is designed around.
Four differences show up the moment you move past the demo.
The first is how layouts get built. Canvas assembles them from Twig-based single-directory components, React-based code components, and Drupal blocks, so you work with the component technologies your team already knows rather than adopting one proprietary format wholesale.
The second is where the context comes from. Because Canvas can ground its work in the Context Control Center, the agent is not inventing your brand from a prompt. It is working from the voice, content model, business rules, and relationships your organization has already curated and approved. That is the difference between a layout that is merely plausible and one that is on-brand and relevant.
The third is the model underneath. Through a provider-agnostic AI layer, Canvas is not wired to a single vendor's model. You use the one that suits the task in front of you, and you change your mind later as the field moves, without re-platforming to chase whatever shipped this quarter.
The fourth is where the output can go. Coupled or decoupled, you manage the content once and render it across the front ends and devices your audience uses, so a traditional site and a headless build stay open to you from the same system.
Any one of these helps on its own. Together they are the distance between generating a layout and producing one you can put into production: on-brand because it is grounded in your context, usable anywhere because the output is ambidextrous, and built with whatever model best fits the work.
None of this is a single product feature or a one-vendor bet. It comes out of the Drupal AI Initiative, the funded and coordinated effort in the Drupal community to make the platform both a great place to build with AI and a safe place for agents to act. That initiative is the engine behind the capabilities that put Drupal in front on the things that matter here: structured content an agent can reason about, governance it has to respect, a provider-agnostic model layer, and the freedom to publish coupled or decoupled.
The work runs on two fronts. One brings common AI features directly into Drupal so they operate together instead of as disconnected add-ons. The other makes Drupal legible and callable to agents and tools working from outside, measured against an Agent Readiness scorecard that keeps the progress honest. Because it is happening in the open, on standards-based foundations, the improvements compound for everyone building on Drupal rather than accruing to one company.
The Context Control Center is a good marker of the pace. It turns the context an agent can draw on into a governed content entity, with ownership, workflow, revisions, translations, and scope, and its first stable release is expected in the days ahead. That moves the grounding layer from promising to production, which is the exact piece most platforms are still treating as a roadmap.
If you want to see where this is heading, DrupalCon Rotterdam has two AI Summits dedicated to it. I will be presenting at the AI Dev Summit, and my colleague Scott Falconer will present at the Enterprise AI Summit, one track for the people building with these tools and one for the people who have to answer for them in production.
Faced with a fast-moving category, the tempting move is to wait for a winner and buy in later. The trouble is that the properties that matter here do not arrive as an upgrade. Structured content, relationship-aware data, a governed context layer, model choice, and the freedom to render coupled or decoupled are either in the foundation or they are not.
So the question for a content team is not which AI feature to switch on. It is harder and more useful than that. When an agent stops reading your content and starts writing it, does your platform still carry the judgment that used to live with your editors? Content answers to a person. Context is what lets software act in their place. The teams that see the difference, and that build on a foundation treating context, structure, and governance as first-class concerns, are the ones who will let agents do real work while keeping a hand on what ships.
Reposted from Acquia with permission from Acquia. Authored by Martin Anderson-Clutz (mandclu)
What changes when an agent stops reading your content and starts writing it?
For the last two years, the conversation about AI and content has mostly been about reading. Retrieval, summarization, a chatbot that answers a question from your knowledge base. That problem is largely solved, and it is solved almost everywhere. Any serious platform can find a relevant paragraph and hand it back.
The shift that actually changes the job of a content platform is quieter. Agents have moved from "answer my question" to "do the work." They are no longer only reading your content. They are starting to write it, assembling pages and populating components and publishing the result. The category we have called content management for twenty years was built for the first job. It was never asked to do the second.
At this point a fair objection turns up: is this not exactly why we keep a human in the loop? It is. Any content platform worth running in an enterprise keeps a person between the agent and the published page. A system that lets an agent push unreviewed work straight to production is not showing you the risk of agentic content. It is showing you that it was never built for the enterprise to begin with.
So the risk worth talking about is not the rogue page. Review catches that. The risk is waste.
A read and a write still fail in opposite directions, and the cost is what separates them. When a retrieval system returns a weak answer, one person spends a moment sorting it out and moves on. When an agent produces a weak write, a layout that misses the brand or a component wired to the wrong relationship or a draft that ignored a business rule, someone has to notice it, correct it, and often send it back to be generated again. Every one of those steps costs the reviewer's time and burns the tokens that produced the work in the first place.
That cost lands on the exact person the agent was supposed to help. The promise of agentic content is leverage, so the specialist spends their time on judgment instead of assembly. A guessing agent quietly reverses the trade. Rather than assembling the page themselves, the reviewer now inspects a draft they did not write. They hunt for the places it went wrong and explain what to change. That is not leverage. It is rework wearing the costume of automation, and it scales the wrong way, because an agent that guesses does not guess once. It guesses across every draft, at machine volume.
This is why context is the whole game. A human in the loop is cheap when the work in front of them is already right, and expensive when it is not. Give the agent structured, governed context and the review step becomes a quick yes. Hand it flat fields and hope, and the review step becomes the job you were trying to automate, now done twice.
It helps to look at what actually changed, because the content platform has served three different consumers over its life.
| Content Management System | Headless and Composable | Agentic Content Platform | |
|---|---|---|---|
| Primary consumer | A person in a browser | A front end serving a person | Software that acts |
| Content flows | Outward, to one presentation | Outward, to many presentations | In both directions |
| How editorial judgment is applied | By hand, page by page | By hand, page by page | Encoded as context up front, confirmed at review |
| Measure of success | Editorial autonomy | Reuse across channels | Safe, accountable machine action |
For most of that history, judgment stayed with the editor. The system stored content and rendered it, while a person decided what was true, what was on-brand, and what was ready to publish. Headless moved content to more places, but it did not move that responsibility. A human still stood between the content and the world.
Agentic content management changes that. The agent now does the assembly the editor used to do, which means the judgment the editor brought to the work has to come from somewhere. A platform that carries it, with the business rules and the content relationships and the standards for what good looks like, hands the reviewer a draft that already reflects those things. A platform that cannot leaves every one of those calls for the person to supply by hand, one draft at a time. The judgment does not disappear. It moves back onto the reviewer the agent was supposed to free.
Here is the line most tooling blurs, and the reason so many agentic demos fall apart the moment they meet a real enterprise. Content is not context.
Content is what you publish: the page, the article, the product description, the campaign.
Context is everything an agent draws on to produce that content safely. Your brand voice. Your content model. Your business rules, your reference material, and the relationships that connect all of it. Context is what turns a vague prompt into a result the organization would actually stand behind.
Most systems collapse the two. They hand an agent a set of flat fields and hope it infers the rest: the tone, the relationships, the governance that always lived in the editor's head. Guessing works beautifully in a demo and breaks in production, because the fields never carried the context to begin with. The agent was handed the output and asked to reconstruct the reasoning behind it.
Treating context as a governed layer of its own, with clear owners, review, version history, and scope, is what separates an agent that produces a plausible draft from one an enterprise can trust to publish. The prompt gets simpler. The result gets more accountable. The organization decides in advance what the agent is allowed to know and do.
Here the shape of the underlying system stops being an implementation detail and becomes the whole question.
An agent that writes needs things the read era never demanded. It needs to see the page as a structure it can reason about, with components, order, and resolved values, rather than a wall of markup it has to pattern-match. It needs to work inside the governance that already exists, the roles and permissions and workflows the organization spent years getting right, instead of routing around them. And it needs its output to land in a reviewable state, with a record of who initiated the work and what produced it, so a person can still say yes or no before anyone sees it. Structured context is what makes that review a quick confirmation rather than a second round of work.
None of that can be added after the fact. A platform that stores content as flat, disconnected fields cannot suddenly expose relationships it never modeled. A platform with shallow governance cannot suddenly supervise an agent it was never designed to hold. These are properties of the foundation. Either the structured content and the mature governance are already there, or you are trying to pour a footing under a building that already stands.
For years, careful content modeling and granular governance were treated as overhead, the slow and unglamorous work that held teams back. The agentic era inverts that. The same rigor is now what lets a team move quickly and safely at once, because it is exactly what an agent needs in order to act without guessing.
Plenty of tools can turn a prompt into a layout now. That trick is becoming table stakes, and it is the wrong thing to be dazzled by. The real question is whether the layout that comes back is on-brand, relevant, usable on the devices your audience actually reaches for, and built on terms you control. The answer depends on the foundation under the prompt, and that is what Drupal Canvas is designed around.
Four differences show up the moment you move past the demo.
The first is how layouts get built. Canvas assembles them from Twig-based single-directory components, React-based code components, and Drupal blocks, so you work with the component technologies your team already knows rather than adopting one proprietary format wholesale.
The second is where the context comes from. Because Canvas can ground its work in the Context Control Center, the agent is not inventing your brand from a prompt. It is working from the voice, content model, business rules, and relationships your organization has already curated and approved. That is the difference between a layout that is merely plausible and one that is on-brand and relevant.
The third is the model underneath. Through a provider-agnostic AI layer, Canvas is not wired to a single vendor's model. You use the one that suits the task in front of you, and you change your mind later as the field moves, without re-platforming to chase whatever shipped this quarter.
The fourth is where the output can go. Coupled or decoupled, you manage the content once and render it across the front ends and devices your audience uses, so a traditional site and a headless build stay open to you from the same system.
Any one of these helps on its own. Together they are the distance between generating a layout and producing one you can put into production: on-brand because it is grounded in your context, usable anywhere because the output is ambidextrous, and built with whatever model best fits the work.
None of this is a single product feature or a one-vendor bet. It comes out of the Drupal AI Initiative, the funded and coordinated effort in the Drupal community to make the platform both a great place to build with AI and a safe place for agents to act. That initiative is the engine behind the capabilities that put Drupal in front on the things that matter here: structured content an agent can reason about, governance it has to respect, a provider-agnostic model layer, and the freedom to publish coupled or decoupled.
The work runs on two fronts. One brings common AI features directly into Drupal so they operate together instead of as disconnected add-ons. The other makes Drupal legible and callable to agents and tools working from outside, measured against an Agent Readiness scorecard that keeps the progress honest. Because it is happening in the open, on standards-based foundations, the improvements compound for everyone building on Drupal rather than accruing to one company.
The Context Control Center is a good marker of the pace. It turns the context an agent can draw on into a governed content entity, with ownership, workflow, revisions, translations, and scope, and its first stable release is expected in the days ahead. That moves the grounding layer from promising to production, which is the exact piece most platforms are still treating as a roadmap.
If you want to see where this is heading, DrupalCon Rotterdam has two AI Summits dedicated to it. I will be presenting at the AI Dev Summit, and my colleague Scott Falconer will present at the Enterprise AI Summit, one track for the people building with these tools and one for the people who have to answer for them in production.
Faced with a fast-moving category, the tempting move is to wait for a winner and buy in later. The trouble is that the properties that matter here do not arrive as an upgrade. Structured content, relationship-aware data, a governed context layer, model choice, and the freedom to render coupled or decoupled are either in the foundation or they are not.
So the question for a content team is not which AI feature to switch on. It is harder and more useful than that. When an agent stops reading your content and starts writing it, does your platform still carry the judgment that used to live with your editors? Content answers to a person. Context is what lets software act in their place. The teams that see the difference, and that build on a foundation treating context, structure, and governance as first-class concerns, are the ones who will let agents do real work while keeping a hand on what ships.
Launching your site isn’t the end of the work. That’s the bad news.
Even after you settle back into your day-to-day, your website still needs you. There’s still so much you can and should do.
The good news: the work spreads out across the year, and the effort rises and falls. But measuring your data and making steady improvements is needed to keep your website effective long after launch.
read moreAbout a week ago, I wrote about the simplytest.me rewrite and closed on what was next: site templates and recipes. You can now launch a sandbox for a site template. I'm excited that people can now easily try out all the site templates on Simplytest.me.
read moreCompound field was released as an alpha release two days ago. It's getting a lot of people excited. Let's install it and see how it works.
Its that time of the year where you stand the best chance to secure your spot for DrupalCon Orlando at the lowest price of the year.
Starting September 14, 2026, tickets are available at just $650. But that's not all. Every paid Early Bird registrant will receive Drupy, a limited-edition PHP elePHPant x DrupalCon plush, complete with a latin name: Elephpas hypertextus drupalensis primus, roughly translated to "the first Drupal PHP elephant." Drupy will be available for pickup at registration in Orlando while supplies last, so the earlier you register, the better!
DrupalCon Orlando 2027 takes place March 22–25, 2027 at the Hyatt Regency Grand Cypress Resort, a stunning 1,500-acre resort just minutes from Walt Disney World® and Universal Orlando Resort™. All conference activities happen right at the hotel, putting you at the center of everything from keynotes and sessions to hallway conversations and community gatherings.
The Early Bird rate is available until February 1, 2027 at 7:59 AM EST, after which prices go up. Registering early also means you'll have more time to plan your trip, book your stay at the official hotel block at the discounted rate starting at just $259/night with no resort fee, and make the most of everything DrupalCon Orlando has to offer.
Today we are talking about Laravel, Marketing, and The PHP Foundation with guest Matt Stauffer. We'll also cover Formdazzle as our module of the week.
For show notes visit: https://www.talkingDrupal.com/570
TopicsMatt Stauffer - mattstauffer.com
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Amber Matz - tugboatqa.com [amber himes matz](https://www.drupal.org/u/amber himes matz)
MOTW CorrespondentBernardo Martinez - bernardm28
Prices, specifications and proof buried in body copy are hard to compare, filter or reuse across pages, feeds and AI answers.
Drupal content modeling stores those facts as fields, connects related records with entity references and leaves prose for explanation. Maciej Lukianski walks through buyer-question audits, product and service field tables, migration stages and coverage reports that turn one edit into every output.
read moreAI crawlers already fetch product pages during live conversations, but citations stay rare. Drupal sites cited by AI need one fact in fields, then the same value on the page, in JSON-LD, in feeds and through JSON:API or MCP tools.
Maciej Lukianski walks through what fetchers need, which Drupal modules cover Markdown, llms.txt and MCP Server today, and where configuration still decides whether a bot can quote your catalogue.
read moreAt 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.
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").
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.
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.
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.
read moreNewsletters are meant to keep audiences connected in a consistent way, building familiarity and trust. They carry updates, stories, and ideas straight into inboxes. It’s a format that rewards consistency over noise, and clarity over clever tricks. A good newsletter feels less like marketing and more like a friendly letter that arrives just when you need it.
read moreWritten by Duncan Worrell (dunx)
DrupalCon Rotterdam is almost here. Alongside two dedicated AI summits and the main conference keynote, the program is stacked with high-value AI content for developers, strategists, and leaders alike. Whether you're looking to push agentic workflows, scale digital governance, streamline content operations, or keep your AI integrations trustworthy, here is a complete breakdown of the top AI sessions to help you optimize your schedule.
Full schedule at https://events.drupal.org/rotterdam2026/schedule
Tickets at https://events.drupal.org/rotterdam2026/registration-information
All session times are local CEST.
In addition to the main DrupalCon event, there are two AI-specific summits being held catering for two very different audiences.
An executive-focused event for CXOs, Heads of Digital, and enterprise leaders connecting with curated Drupal AI partners. Hosted on the historic former ocean liner, SS Rotterdam.
Date & Time: All day Monday, 28 September
Event details here: https://summit.enterprisedrupal.eu/schedule.html
Getting Drupal developers up to speed on AI coding tools, AI in PHP/Symfony/Drupal frameworks, Canvas, and Drupal CMS innovations.
Date & Time: All day Monday, 28 September
Event details here: https://events.drupal.org/rotterdam2026/ai-dev-summit
For many, the DriesNote by Drupal founder Dries Buytaert is the week’s highlight. Expect a keynote packed with the latest AI roadmap updates, architectural reveals, and live technical demos.
Date & Time: Tuesday, September 29, 2026 - 10:30 to 11:45
DriesNote will live stream on YouTube if you can’t make the event in person.
Every session is likely to mention “AI” but we expect these sessions to be focused on AI.
Research and strategies for moving AI initiatives past the pilot phase to deliver real-world impact.
Date & Time: Tuesday, 29 September 2026, 13:00 – 13:10
Speakers: Amanda Falshaw (AI Enablement Lead at Reading Room) & Megan Harvey (Reading Room)
Features AI-assisted content creation as part of an open-source Drupal intranet workspace.
Date & Time: Tuesday, 29 September 2026, 13:15 – 13:25
Speaker: Maciej Łukiański (CEO and Co-founder of Droptica)
Leadership and organizational change management required to guide teams through fast-moving AI adoption.
Reviewer-Friendly AI: A Practical Drupal Contribution Workshop
Practical AI-assisted workflows designed to turn ideas into high-quality, review-ready open-source contributions.
Date & Time: Tuesday, 29 September 2026, 13:30 – 14:15
Speaker: Scott Falconer (Senior Principal Software Engineer at Acquia)
Engineering reliable, trustworthy AI agent integrations in Drupal using modules like AI, ECA, and agentic tools.
Date & Time: Tuesday, 29 September 2026, 13:30 – 14:15
Speaker: Shibin Devadas Kakanat (Backend Pro Lead at Factorial)
Structuring, scoping, and natively managing AI context within Drupal CMS for downstream agents and tools.
Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10
Speakers: Emma Horrell (User Experience Manager University of Edinburgh and UX Research Lead for Drupal CMS) & James Abrahams (Technical Director at Freelygive)
Applying UX research methods to train and ground AI content tools to output domain-specific quality.
Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10
Speaker: Aidan Foster (Senior UX Strategist at Kanopi Studios)
Addressing data security, compliance, provider selection, and cost control as AI adoption scales.
Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10
Speaker: Michael Schmid (Head of Technology and Co-Founder of amazee.io)
Testing AI coding agents on live projects to automate complex site migrations into Drupal Canvas, examining real metrics, wins, and limitations.
Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30
Speakers: Wolfgang Ziegler (Architect, Founder of drunomics) & Jeremy Chinquist (Project Manager at drunomics)
Automating inclusive governance and identifying accessibility errors early by bridging code, humans, and AI workflows.
Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30
Speaker: Mike Gifford (Senior Accessibility Strategist at CivicActions)
Adapting content architecture for direct answer delivery to AI systems while increasing Drupal’s strategic value.
Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30
Speakers: Tomi Mikola & Ulla Koho (both digital strategists and content architects at Wunder)
Maintaining human readability, software architecture, and clean code standards when using AI generators.
Date & Time: Wednesday, 30 September 2026, 11:40 – 12:25
Speaker: Len Swaneveld (Senior Drupal Developer at iO)
Unifying 35 national voices into a cohesive travel brand using generative AI integrated into Drupal.
Date & Time: Wednesday, 30 September 2026, 11:40 – 12:25
Speakers: Krisztián Kása & Zsófia Alföldi (both Project Managers at Brainsum)
Leveraging Drupal’s structured architecture to build optimized environments for AI Agents running inside and outside CMS boundaries.
Date & Time: Wednesday, 30 September 2026, 12:30 – 12:40
Speaker: James Abrahams (Technical Director at Freelygive)
How autonomous AI agents act as primary decision-makers selecting, building, and verifying Drupal systems.
Date & Time: Wednesday, 30 September 2026, 12:45 – 13:30
Speaker: Scott Falconer (Senior Principal Software Engineer at Acquia)
Official product update from the Drupal AI Initiative leadership on building production-ready Agentic CMS capabilities.
Date & Time: Wednesday, 30 September 2026, 13:40 – 14:25
Speakers: Niels Aers (CTO/AI Tech Lead at Dropsolid) & Dr. Christoph Breidert (CEO and Founder of 1xINTERNET)
Generating governed, high-quality draft campaign pages straight from PDF briefs in minutes without code tickets.
Date & Time: Wednesday, 30 September 2026, 13:40 – 14:00
Speaker: Kieran Cott (Executive Creative Technology Director at Delete Agency)
Open discussion on improving how LLMs describe, evaluate, and recommend Drupal to users.
Date & Time: Wednesday, 30 September 2026, 13:40 – 14:25
Speaker: Larissa Tropp (Digital Marketing & Growth Specialist at 1xINTERNET)
Leveraging AI tools to simplify, re-architect, and map legacy un-typed data into clean destination bundles during migrations.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speaker: Roberto Peruzzo (Principal Architect and Founder of Sparklingboys)
Honest post-mortems on AI project failures and pragmatic ways to navigate rapid technological shifts.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speakers: Dieter Blomme (Drupal Architect at Dropsolid) & Valery Lourie (Lead Software Engineer at EPAM Systems)
Running lightweight, client-side search powered by Pagefind with an AI layer for query expansion and summaries.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speaker: Jeremy Andrews (CEO and Founder of Tag1 Consulting)
Training AI agents to generate Single Directory Components, insert them into pages, and verify browser rendering.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speaker: Matt Glaman (Principal Software Engineer at Acquia)
Agentic translation and governance workflows developed for the European Commission across 24 languages.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speakers: David Galeano & Adam Nagy (both work in the DIGIT department at the European Commission)
Enabling non-technical users to build, style, and structure complete Drupal sites via conversational prompts.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speakers: Francesco Pesenti & Francesco Quagliati (both are Developer Advocates and Solution Engineers at Platform.sh)
Designing constrained AI search engines over standard chatbots to deliver structured content answers.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speaker: Antonella Picarella (Head of Digital Communications & Content Strategy at BFF Banking Group)
Strategic shifts from Search Engine Optimization to Generative Engine Optimization as AI engines handle discovery.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speaker: Wouter De Bruycker (Digital Marketing Strategist at Dropsolid)
Translating and moderating hundreds of high-volume personal stories across 60+ languages using AI tools.
Date & Time: Wednesday, 30 September 2026, 17:00 – 17:45
Speakers: Charles Andrew Revkin & Diego Fernando Costa (both part of the digital communications team at the Union for International Cancer Control (UICC), which runs World Cancer Day)
Practical tactics for Answer Engine Optimization (AEO) and maintaining content discoverability in AI platforms.
Date & Time: Wednesday, 30 September 2026, 17:00 – 17:45
Speakers: Reena Tripathi (Digital Marketing Manager at OpenSense Labs) & Anubhav Gupta (CEO/Technical Architect at OpenSense Labs)
Whether you’re coming to DrupalCon Rotterdam to build with AI, figure out how to govern it, or understand where it is taking Drupal next, there is a lot to choose from. From the two Monday summits through the DriesNote and a packed slate of sessions, AI is clearly woven throughout this year’s programme. Check the full schedule, plan around the sessions that matter most to you, and we’ll see you in Rotterdam.
Written by Duncan Worrell (dunx)
DrupalCon Rotterdam is almost here. Alongside two dedicated AI summits and the main conference keynote, the program is stacked with high-value AI content for developers, strategists, and leaders alike. Whether you're looking to push agentic workflows, scale digital governance, streamline content operations, or keep your AI integrations trustworthy, here is a complete breakdown of the top AI sessions to help you optimize your schedule.
Full schedule at https://events.drupal.org/rotterdam2026/schedule
Tickets at https://events.drupal.org/rotterdam2026/registration-information
All session times are local CEST.
In addition to the main DrupalCon event, there are two AI-specific summits being held catering for two very different audiences.
An executive-focused event for CXOs, Heads of Digital, and enterprise leaders connecting with curated Drupal AI partners. Hosted on the historic former ocean liner, SS Rotterdam.
Date & Time: All day Monday, 28 September
Event details here: https://summit.enterprisedrupal.eu/schedule.html
Getting Drupal developers up to speed on AI coding tools, AI in PHP/Symfony/Drupal frameworks, Canvas, and Drupal CMS innovations.
Date & Time: All day Monday, 28 September
Event details here: https://events.drupal.org/rotterdam2026/ai-dev-summit
For many, the DriesNote by Drupal founder Dries Buytaert is the week’s highlight. Expect a keynote packed with the latest AI roadmap updates, architectural reveals, and live technical demos.
Date & Time: Tuesday, September 29, 2026 - 10:30 to 11:45
DriesNote will live stream on YouTube if you can’t make the event in person.
Every session is likely to mention “AI” but we expect these sessions to be focused on AI.
Research and strategies for moving AI initiatives past the pilot phase to deliver real-world impact.
Date & Time: Tuesday, 29 September 2026, 13:00 – 13:10
Speakers: Amanda Falshaw (AI Enablement Lead at Reading Room) & Megan Harvey (Reading Room)
Features AI-assisted content creation as part of an open-source Drupal intranet workspace.
Date & Time: Tuesday, 29 September 2026, 13:15 – 13:25
Speaker: Maciej Łukiański (CEO and Co-founder of Droptica)
Leadership and organizational change management required to guide teams through fast-moving AI adoption.
Reviewer-Friendly AI: A Practical Drupal Contribution Workshop
Practical AI-assisted workflows designed to turn ideas into high-quality, review-ready open-source contributions.
Date & Time: Tuesday, 29 September 2026, 13:30 – 14:15
Speaker: Scott Falconer (Senior Principal Software Engineer at Acquia)
Engineering reliable, trustworthy AI agent integrations in Drupal using modules like AI, ECA, and agentic tools.
Date & Time: Tuesday, 29 September 2026, 13:30 – 14:15
Speaker: Shibin Devadas Kakanat (Backend Pro Lead at Factorial)
Structuring, scoping, and natively managing AI context within Drupal CMS for downstream agents and tools.
Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10
Speakers: Emma Horrell (User Experience Manager University of Edinburgh and UX Research Lead for Drupal CMS) & James Abrahams (Technical Director at Freelygive)
Applying UX research methods to train and ground AI content tools to output domain-specific quality.
Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10
Speaker: Aidan Foster (Senior UX Strategist at Kanopi Studios)
Addressing data security, compliance, provider selection, and cost control as AI adoption scales.
Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10
Speaker: Michael Schmid (Head of Technology and Co-Founder of amazee.io)
Testing AI coding agents on live projects to automate complex site migrations into Drupal Canvas, examining real metrics, wins, and limitations.
Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30
Speakers: Wolfgang Ziegler (Architect, Founder of drunomics) & Jeremy Chinquist (Project Manager at drunomics)
Automating inclusive governance and identifying accessibility errors early by bridging code, humans, and AI workflows.
Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30
Speaker: Mike Gifford (Senior Accessibility Strategist at CivicActions)
Adapting content architecture for direct answer delivery to AI systems while increasing Drupal’s strategic value.
Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30
Speakers: Tomi Mikola & Ulla Koho (both digital strategists and content architects at Wunder)
Maintaining human readability, software architecture, and clean code standards when using AI generators.
Date & Time: Wednesday, 30 September 2026, 11:40 – 12:25
Speaker: Len Swaneveld (Senior Drupal Developer at iO)
Unifying 35 national voices into a cohesive travel brand using generative AI integrated into Drupal.
Date & Time: Wednesday, 30 September 2026, 11:40 – 12:25
Speakers: Krisztián Kása & Zsófia Alföldi (both Project Managers at Brainsum)
Leveraging Drupal’s structured architecture to build optimized environments for AI Agents running inside and outside CMS boundaries.
Date & Time: Wednesday, 30 September 2026, 12:30 – 12:40
Speaker: James Abrahams (Technical Director at Freelygive)
How autonomous AI agents act as primary decision-makers selecting, building, and verifying Drupal systems.
Date & Time: Wednesday, 30 September 2026, 12:45 – 13:30
Speaker: Scott Falconer (Senior Principal Software Engineer at Acquia)
Official product update from the Drupal AI Initiative leadership on building production-ready Agentic CMS capabilities.
Date & Time: Wednesday, 30 September 2026, 13:40 – 14:25
Speakers: Niels Aers (CTO/AI Tech Lead at Dropsolid) & Dr. Christoph Breidert (CEO and Founder of 1xINTERNET)
Generating governed, high-quality draft campaign pages straight from PDF briefs in minutes without code tickets.
Date & Time: Wednesday, 30 September 2026, 13:40 – 14:00
Speaker: Kieran Cott (Executive Creative Technology Director at Delete Agency)
Open discussion on improving how LLMs describe, evaluate, and recommend Drupal to users.
Date & Time: Wednesday, 30 September 2026, 13:40 – 14:25
Speaker: Larissa Tropp (Digital Marketing & Growth Specialist at 1xINTERNET)
Leveraging AI tools to simplify, re-architect, and map legacy un-typed data into clean destination bundles during migrations.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speaker: Roberto Peruzzo (Principal Architect and Founder of Sparklingboys)
Honest post-mortems on AI project failures and pragmatic ways to navigate rapid technological shifts.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speakers: Dieter Blomme (Drupal Architect at Dropsolid) & Valery Lourie (Lead Software Engineer at EPAM Systems)
Running lightweight, client-side search powered by Pagefind with an AI layer for query expansion and summaries.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speaker: Jeremy Andrews (CEO and Founder of Tag1 Consulting)
Training AI agents to generate Single Directory Components, insert them into pages, and verify browser rendering.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speaker: Matt Glaman (Principal Software Engineer at Acquia)
Agentic translation and governance workflows developed for the European Commission across 24 languages.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speakers: David Galeano & Adam Nagy (both work in the DIGIT department at the European Commission)
Enabling non-technical users to build, style, and structure complete Drupal sites via conversational prompts.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speakers: Francesco Pesenti & Francesco Quagliati (both are Developer Advocates and Solution Engineers at Platform.sh)
From Drupal Content to AI Answers: Learnings from EPSY
Designing constrained AI search engines over standard chatbots to deliver structured content answers.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speaker: Antonella Picarella (Head of Digital Communications & Content Strategy at BFF Banking Group)
Strategic shifts from Search Engine Optimization to Generative Engine Optimization as AI engines handle discovery.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speaker: Wouter De Bruycker (Digital Marketing Strategist at Dropsolid)
Translating and moderating hundreds of high-volume personal stories across 60+ languages using AI tools.
Date & Time: Wednesday, 30 September 2026, 17:00 – 17:45
Speakers: Charles Andrew Revkin & Diego Fernando Costa (both part of the digital communications team at the Union for International Cancer Control (UICC), which runs World Cancer Day)
Practical tactics for Answer Engine Optimization (AEO) and maintaining content discoverability in AI platforms.
Date & Time: Wednesday, 30 September 2026, 17:00 – 17:45
Speakers: Reena Tripathi (Digital Marketing Manager at OpenSense Labs) & Anubhav Gupta (CEO/Technical Architect at OpenSense Labs)
Whether you’re coming to DrupalCon Rotterdam to build with AI, figure out how to govern it, or understand where it is taking Drupal next, there is a lot to choose from. From the two Monday summits through the DriesNote and a packed slate of sessions, AI is clearly woven throughout this year’s programme. Check the full schedule, plan around the sessions that matter most to you, and we’ll see you in Rotterdam.
drupalThe Drupal project uses the CKEditor library for WYSIWYG editing. CKEditor has released a security update that impacts Drupal.
Vulnerabilities are possible if Drupal is configured to use CKEditor for WYSIWYG editing. An attacker that can create or edit content (even without access to CKEditor themselves) may be able to exploit this Cross-Site Scripting (XSS) vulnerability to target users with access to the WYSIWYG CKEditor, including site admins with privileged access.
For more information, see CKEditor's security advisory:
Install the latest version:
Drupal 11
Drupal 10
Note that Drupal 8 and Drupal 9 have both reached end-of-life.
Site owners should also review their site following the protocol for managing external libraries and plugins, as contributed projects may use additional CKEditor plugins not packaged in Drupal core.
CKEditor has also released another CVE in today's release that does not affect Drupal, but may affect custom plugins or other usecases:
Every month I do my agency's billing by hand: export timesheets from one system, create invoices in another, merge, email, file, upload to the accountant. I maintain ECA. Elsewhere, a multi-agency project runs from an Excel sheet nobody can keep current, because the spreadsheet is the only place people see everything and feel in control. Everybody orchestrates, most by hand, and not for lack of tools. ECA, Maestro, FlowDrop, Tool API, AI Integration - ECA 1.0.0 and the Orchestration module with Activepieces, soon n8n, could run my billing end to end today. But the builder opens five UIs and, worse, has to decide which engine runs which step. No user can make that decision. The fix is one UI: every component of every participating system on one canvas, engine routing done by the platform. The Modeler API, the Workflow Modeler, Tool API's typed contract and Post 6's shared vocabulary are that architecture. Missing: a composite model owner, a dispatcher, the cross-system data contract. Let's build them. In Drupal.
Join us THURSDAY, September 17 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.
Author: Will Huggins
Imagine asking an AI assistant:
"Show me waterproof jackets under £150, in size M, available for delivery tomorrow".
Today, the assistant might search the web, read several retail websites and summarise what it finds. But what if, instead of reading pages, the agent could ask retailers directly which products matched those requirements?
With that information, you could fast-track your shopping journey and ask:
"Add [my chosen product] to my basket"
The important change here isn't the chatbot; it’s what sits behind it. A traditional website can tell an AI agent what products it has and provide the details. Tomorrow’s website will give the agent a controlled way to buy it.
That is the shift from publishing pages to publishing capabilities. It fundamentally changes what we expect a CMS to do.
Ever since the early days of the internet, content management systems have had a fairly straightforward job: someone creates a piece of content, the CMS publishes it as a page, a person finds that page, and then reads it and decides what to do next.
Over time, CMS capabilities developed around improved findability of content and the experience humans have when they land on a page. AI agents are now changing that equation, introducing a different type of interaction that moves beyond pages altogether, in search of capabilities that solve a problem rather than pages to read.
Take that same retailer from the jacket example. Its website contains thousands of pages describing products, categories, delivery and returns information, promotions, and offers. That information is useful to both human and AI visitors. But the retailer doesn't only have information, it offers services too: searching products according to particular requirements, comparing specifications, checking availability, calculating delivery, adding products to a basket, and buying them.
The focus is on wrapping those capabilities in an interface that optimises the customer’s experience and drives greater conversion. Those ‘wrappers’ are navigation menus, search boxes, filters, buttons and checkout flows that guide someone towards that conversion target.
Think of an AI agent less like another customer and more like a personal shopper acting on their behalf. Or, perhaps, interacting directly with the shop's warehouse rather than the shop staff.
The visiting customer may care about the photography, the brand story, the layout, and the overall shopping experience. And whilst these elements remain vital in building trust with a potential customer, the personal shopper has a different job. They need to understand what the customer wants, quickly identify suitable products, check availability, compare options and, if instructed, complete the purchase.
They don't need to navigate the website the same way the customer does. In fact, forcing them through the same menus, filters and checkout steps may simply create unnecessary friction. The AI agent needs reliable, structured ways and clearly defined methods to discover what the retailer offers and what actions it can perform.
AI agents need to know not just what the retailer sells, but how to search, compare, check and buy on the customer's behalf, potentially across numerous websites at once. The retailer that makes the personal shopper's job frictionless is the one more likely to win the sale.
None of this means websites are about to become obsolete. People will continue to visit websites, and great digital experiences will still require accessible interfaces, thoughtful design, persuasive content, and strong brand experiences. A retailer still needs customers to trust its products!
But the webpage will increasingly become one interface to an organisation's digital information and services, rather than the only interface.
Drupal has been moving in this direction for a long time. The same structured content managed in Drupal can already be used across websites, applications, search experiences, feeds and APIs. Drupal is now leading the way in how AI agents can interact with websites to complete transactions.
For a marketing team, publishing has traditionally meant putting something in front of an audience: a campaign, a landing page, or a new product
With the rise of the agentic web, publishing is developing another dimension, one that needs AI systems to understand what you offer, who it's for, whether and where it's available, what it costs, and what actions can be taken, and by whom.
That makes structured content much more than a CMS implementation requirement. It must become part of your brand architecture. The idea of ‘capabilities’ takes that idea one step further.
You don't need to start exposing every organisational process to AI agents right away. Start by asking different questions about your digital estate. Think beyond "do we have a page explaining this product or service?" and ask "what is the underlying action or outcome we want customers to complete, and could an authorised agent safely perform it?"
This is where Drupal AI gets really interesting!
Drupal has always been good at structured content. A product doesn't have to be defined simply through a large page of text called "product page."
For the personal shopper to do its job well, it needs more than a page to read. Drupal can understand that a product has a:
Those pieces of information can be connected to other things Drupal understands, such as related products or customer reviews.
The customer sees the finished page, but underneath that page is a structured content model that provides an AI agent with context, meaning and additional information not directly available to a human reader on the "product page."
Go back to the waterproof jacket. If an agent asks for products under £150, structured data gives it a much more dependable answer than inferring prices from paragraphs of product copy. Ask for size M, and Drupal knows which fields represent product type, features and size. Ask which jackets are available for next-day delivery, and Drupal can use live availability and delivery information rather than relying on an AI model to guess from a page's wording.
The same structured content that makes a product page useful to a human is what lets a personal shopper act on it. The Drupal AI roadmap builds on that relationship between Drupal's content model, context, governance, and trustworthy AI experiences.
But structured information is only half of the story. Drupal is now developing ways to describe actions just as clearly.
AI has already given us enough acronyms to fill a data center, but three are particularly relevant to the future of content management systems: API, MCP, and ARD.
An API, or Application Programming Interface, is a controlled way for one system to request information or perform an action.
In the context of agentic AI acting on a Drupal website, think of it like a service counter. Instead of navigating through the shop yourself, you make a specific request:
"Show me all products under £50 that are currently in stock."
The API defines what can be requested and how the answer comes back.
APIs aren't new. They already connect websites to apps, CRMs, commerce systems, search platforms, and countless other services.
MCP, or Model Context Protocol, is an open standard that lets AI models safely connect to external tools, data and services.
Put simply, while an API can expose a capability, MCP gives an AI agent a consistent way to use it.
Drupal's MCP Server project builds on Tool API, making Drupal tools available to compatible AI systems. It also supports authentication, allowing individual tools to require appropriate authorisation rather than simply opening everything to an external agent.
There is another problem: an AI agent can only use a capability if it knows it exists.
Agentic Resource Discovery, or ARD, is an emerging idea exploring how agents might discover services that can fulfil a particular need.
Instead of already knowing which website to visit, an agent could potentially ask a broader question:
"Who can help me find a product matching these requirements?"
Discovery and execution are different problems. One helps an agent find the right door, whereas the other helps it interact with what is behind the door.
The standards are still evolving, and nobody needs to redesign their digital strategy around a particular acronym today. The important thing is the direction of travel.
One important building block in Drupal's emerging agentic AI architecture is Tool API. It gives Drupal a consistent, reusable way to describe not only the information it holds but also the things it can do, with clearly defined inputs and outputs that Drupal AI Agents, MCP, and other automation systems can all use.
A tool might effectively say I can search products and describe what information it needs (e.g., product type, size, colour, price range and delivery requirements) and what it will return (e.g., a list of matching products).
Another might say I can check stock availability for a particular product and size, or I can add a selected product to the customer’s basket.
AI agents can reuse tools and expose them to other AI systems through technologies such as MCP. Tool API is currently available as a beta project, so this is active, evolving work rather than a finished endpoint for the vision.
The big idea is that Drupal can increasingly describe not just what it knows, but what it can do.
That is a fundamentally new Drupal capability being built on top of Drupal's existing publishing capabilities.
This is also where the Drupal AI Initiative's distinction between Inside AI and Outside AI becomes useful.
Inside AI focuses on AI working within Drupal to help you create, manage, and optimise your website. Outside AI focuses on external agents acting on Drupal.
Outside AI enables an external agent to connect to Drupal, inspect it, change it, verify it, migrate into it, or launch it. That makes the publishing-capabilities idea more than a thought experiment.
Drupal's Outside AI work is actively exploring the infrastructure needed to make Drupal a reliable and governable action surface for external AI agents: who the agent is and where it came from, reliable execution in the background, guardrails, limits on what each tool can touch, visibility into what happened, and predictable contracts between agents and Drupal.
In other words, the question isn't simply "can an AI agent make Drupal do something?" but "can we let an AI agent do something useful while Drupal still controls what is permitted, records what happened and protects everything the agent should not be able to touch?"
Imagine an AI agent interacting with a retailer. An anonymous agent might be allowed to search the product catalogue, add a selected product to that shopper’s basket, or check the status of their order.
None of those agents should suddenly gain permission to view another customer’s orders, change product prices or publish a new promotion.
Drupal has spent decades developing data access and functional controls, based on roles, permissions and workflows for human users. Those same principles become increasingly valuable when the user is an AI agent, and it’s one of the reasons Drupal AI's work on guardrails matters.
Guardrails were introduced into Drupal AI and expanded in the 1.4 release so safety and policy checks can be applied more broadly to incoming and outgoing AI interactions, including support for streaming responses. The Context Control Center (CCC) is another piece of this work, helping Drupal AI draw on the right content, rules and standards to deliver more accurate results.
In simple terms, Drupal can put rules between AI and the organisation.
As agents become more capable, that may be just as important as the capability itself.
APIs aren't new. Drupal permissions aren't new and structured content certainly isn't new.
What’s new is how those established strengths are being assembled for an agentic web.
For digital leaders, perhaps the simplest way to understand the direction is in four layers.
This is a very different picture of a CMS from the system many people still imagine when they hear the term. It is not simply the place where somebody logs in to edit the homepage. It becomes a critical control layer between an organisation's information, services and the growing number of digital interfaces through which people interact with them.
The first generation of content management systems helped organisations put information on the web. The next generation helped them structure it, personalise it, distribute it across channels and connect it to increasingly sophisticated digital experiences.
AI agents now offer a shortcut to the ultimate outcomes, which may mean they use the website on the customer's behalf. That doesn't make the CMS less important… it makes the CMS much more important because you now need a way to tell the AI agents what your organisation knows, what it can do, who is allowed to do it, and what happens when they do.
Yesterday's CMS published pages. Tomorrow's CMS publishes capabilities.
Drupal is designed to govern both.
Author: Martin Anderson-Clutz. Originally posted on The Acquia Blog.
Two GovCon keynotes came at disruption from opposite ends. Read them together and you get a map of the moment Drupal is in.
Earlier this month, I spent some time at Drupal GovCon, and a striking element was how well the two keynotes fit together. They were pitched under the same banner — "Building Through Disruption" — but they came at it from opposite ends. Mike Madison talked about how disruption can be something you do, on purpose, to make your team better. Kerry Greer reminded us that disruption is also something that happens to people, and that holding a team together through it is real work that rarely shows up on a ticket. Put those two talks side by side and you get something close to a complete picture: the courage to lead change, and the care to make sure nobody gets left behind while you do it.
I want to walk through both, because I think the Drupal community needs both right now.
Mike (a former Acquian, now Senior Director of Global Web at Zscaler) has spent much of his career being paid, in his words, to "professionally disrupt organizations." His whole framing was a permission slip. When we talk about disruption in business we tend to reach for the giants: Netflix, Airbnb, Uber. And that framing is paralyzing, because none of us is going to reinvent a multibillion-dollar industry over lunch. So Mike flipped it. Think small. Disruption, boiled down, is just "replacing an old way of doing something," and every person in the room already has the standing to do that on their own team.
Every person in this room has the ability to go and disrupt your team or your organization in a meaningful way — and you can do that without pissing everybody on your team off, if you do it right.
His recipe was almost aggressively simple. Four steps: have an idea, figure out how you will change it, convince somebody it is a good idea, and then (the hard part) actually go do the thing. He was honest that the last step is where most of us fail. Ideas are cheap; we all have the brilliant one at breakfast that is gone by bedtime. Doing the work is what separates change from complaint.
A few of his points stuck with me. One was where to find your ideas: "channel your inner hate." The stuff that drives you nuts at work, the things that keep you up at night: that is the gold mine, because you already care enough to push. Another was a caution from science-fiction writer Isaac Asimov: it is easy to predict the car, but hard to predict the traffic jam. Even a great change has unintended consequences, and that is fine, as long as you are watching for the traffic jams.
The part most relevant to us as a technology community was his argument against standing still. He put up the most popular programming languages from 2005, when he started, with PHP sitting proudly near the top — and then watched it slide down the list decade by decade, ceding ground the whole time. His point was not that PHP is doomed; it was that the teams with the most experience are too often the ones least willing to change, and that "what goes too long unchanged destroys itself," as Ursula K. Le Guin put it. The antidote is deliberate: budget time for continuous improvement, kaizen, the way you would budget for meetings or security work. Do not wait for permission to get better.
And crucially, he was clear that driving change is a social act, not a heroic one. The story he told to prove it was about being an intern at a national lab, convinced they were using the wrong tool for the job, and knowing that the intern standing alone in front of a room of senior engineers was going to lose. So he spent a year finding allies — people with the tenure and technical credibility he did not have yet — and when the real decision came, it was not him making the pitch. It was a room full of respected voices backing the idea. That lab runs on Drupal today. His takeaway: right idea, wrong timing or wrong messenger, and nothing happens. Change is something you build with other people or not at all.
Kerry has been in the Drupal community for around two decades — a lineage that runs back to the early federal adopters — and she is now an account director at Forum One. Where Mike talked about disruption you choose, Kerry talked about the disruption that arrived uninvited. Over the past couple of years, the ground shifted for a lot of people who build for government: a new administration, workforce reductions, changing contracts and priorities, and AI landing on top of all of it at once. For many of her colleagues and friends, that was not theoretical. People lost jobs. Teams reshaped overnight.
Her question was different from Mike's. Not "how do I change things?" but "how do I keep creating when everything around me keeps changing?" And her answer was that the thing that carries a team through disruption is not another tool, methodology, or roadmap. It is what she called the invisible work, or the human architecture — the layer that never gets a Jira ticket.
When disruption hits, you don't have time to build the relationship. You only have time to trust what's already built.
She named five load-bearing principles, and they resonated because she illustrated them with two real projects from the past year, one that went well and one that very much did not. The difference between them, she argued, was not talent. Both teams were made of capable people doing their best in an uncertain moment. The difference was the human architecture that had — or had not — been built before the pressure hit.
Build trust before you need it, because when disruption lands you do not have time to build the relationship; you only get to spend the trust you already have. Create clarity when you cannot create certainty — when a meeting stops making sense, be the person who says so out loud, whether or not that is your job. Do not let the org chart define the team; on her successful project, the person bringing the most clarity was the most junior UX designer on it. Share what you know instead of gatekeeping, because a community that hoards knowledge does not survive disruption. And remember what you are here for: purpose is the thing that does not move when people, roadmaps, and org charts do.
She grounded all of it in who the work is actually for — the single parent trying to renew a license at the DMV with sick kids in the back seat, the family that needs to know there is a bear in their Yellowstone campground. Government does not get to stop building. When someone asked her about AI displacing the human connection, her answer was steady: AI is another tool, like Google or Word or Excel before it, and it will change some jobs — but humans have to stay in the loop, "especially in government," because the public still needs accurate information from something they can trust.
Together these two talks are more useful than either alone. Mike hands us the agency to lead change; Kerry reminds us that leading change without tending to people is how projects quietly fall apart. And this is exactly the moment the Drupal community is in. Every team I talk to is being asked to meet familiar challenges — and some new ones — with fewer resources and, in some cases, unfamiliar tools. That is Kerry's disruption and Mike's opportunity at the same time.
Here is the optimistic part, and I do not think it is wishful. On the technical level, Drupal is unusually ready for this moment. Many of the decisions this community made years ago — treating structured content, configuration, permissions, and workflow as first-class, exportable things rather than logic buried in code — turn out to be exactly what makes a system legible to AI agents. We have been doing the unglamorous governance work for a decade, and it is about to pay off.
We are also finding new ways to embrace change as a project, not just as individuals — which is really Mike's "do the thing" and Kerry's structured collaboration operating at community scale. The Drupal AI Initiative is the clearest example. Rather than letting work this important languish or fall victim to bikeshedding, it is structured as a funded initiative with dedicated contributors, and it keeps adapting its own shape to match what the market actually needs. That recently meant splitting into two complementary tracks. Inside AI is building what partners literally ranked as their priorities — AI search first, then content review, translation, and chat-driven editing — all working together on one real, multilingual site rather than a scatter of demos. Outside AI is tackling agent experience: making Drupal "legible, callable, safe, and verifiable" for the agents that will increasingly build on our behalf, so that our decades-old advantage in governance-as-data is something agents can actually reach and trust. Both are aiming to prove the path — not just claim it — at DrupalCon Rotterdam, including at the AI Dev Summit and Enterprise AI Summit.
Notice how neatly that maps to what Mike and Kerry each described. The initiative is a room full of people choosing to disrupt an old way of doing things and then doing the hard, unglamorous work of shipping it. And it is doing so through exactly the human architecture Kerry championed: shared knowledge instead of gatekeeping, clarity of purpose, and a structure that lets contributors lead regardless of where they sit on any org chart.
So here is where their insights brought me, and it is the note I want to end on. Disruption is not something happening to the Drupal community. It is something we are equipped to lead — technically, because of choices we made years ago, and culturally, because we know how to build with each other. Mike is right that we are all more capable of driving meaningful change than we think we are. Kerry is right that the most important thing we build is not software; it is the trust and the people that make the software possible. Hold both, and this is a moment to be excited about. We get to help write what comes next, and we get to make sure that as it changes, nobody gets left behind.
The Drupal Business Survey investigates the trends in the digital market, in particular from service providers involved with the open source Drupal CMS and enterprise platform. Digital agencies from all over the world participate in the yearly survey and the business insights on market share and growth opportunities gained are shared with those who’ve submitted responses.
Begun many years ago by Drupal Business Network with Janne Kalliola, Michel Van Velde, and Imre Gmelig Meijling, the survey is now administered by the Drupal Association to promote global reach and protect the confidentiality of the information. Moving forward, the Drupal Association will handle the analysis and reporting of the anonymised data from the survey. We're grateful to Janne, Michel, and Imre for their many years of work in shaping and running the survey.
Drupal’s open source ecosystem is supported by a strong community of tens of thousands professionals worldwide, working together on the popular digital experience platform. Because Drupal is open source, anyone can work with Drupal or make changes to it. An important part of this community are the agencies that provide Drupal services to end users and drive Drupal’s market. The Drupal Business Survey seeks the input from these agencies so that meaningful data for business owners and decision makers can be built into their business strategies.
The Drupal Business Survey has been a valuable guide for digital service providers, even to those working with other technologies than Drupal.
The Drupal Business Survey supports Drupal businesses worldwide and is organised by the Drupal Association. The survey was founded by Imre Gmelig Meijling (React Online), Janne Kalliola (Exove) and Michel van Velde (Craftmore), and we're grateful for their years of work in building it into what it is today.
Drupal is the open source Digital Experience Platform used by many organisations worldwide including Nestlé, Lufthansa and World Wildlife Fund (WWF).
Drupal experts are invited to share their Drupal business insights through the Business Survey anonymously and come to DrupalCon Europe to review the results together.
You can take the Drupal Business Survey 2026 anonymously here. The survey closes on 7 September.
This post is adapted from the DA Insider, the Drupal Association's monthly newsletter. Subscribe here to get it in your inbox each month.
To the Drupal community,
As northern hemisphere summer winds down, DrupalCon Rotterdam is rapidly approaching — and if you haven't booked yet, today is your last chance at Regular pricing. Late Rate kicks in at midnight CEST, so this is my friendly nudge to save yourself €270 and register now.
Rotterdam isn't the only Con on the horizon. DrupalCon Orlando Early Bird registration opens 14 September, and paid Early Bird tickets come with a limited-edition DrupalCon elePHPant — once they're gone, they're gone.
Elsewhere in this edition: the 2026 Drupal Business Survey is open until 7 September (your answers shape where we focus next), the engineering teamhas completed the migration of Drupal's security issue tracking to GitLab, and we're delighted to welcome Janna Malikova to the Drupal Association Board.
As always, thanks for being part of it. See you in Rotterdam!
Ryan Witcombe, Director, Product Marketing
Your input shapes an anonymized report that helps the whole community. You'll see how your pipelines, win rates, and revenues compare to global peer data, share what's actually working, and directly influence where the Drupal Association focuses next.
Take the survey by 7 September 2026 at 23:59 UTC. Responses are strictly confidential and fully anonymized. Everyone who completes the survey receives the full report by email.
Join Drupal experts and community members to discover what’s next for Drupal and the open web, exchange ideas, and build connections across the ecosystem in Rotterdam from 28 September to 1 October.
The regular rate is now closed, but registration for DrupalCon Rotterdam 2026 is still open. Register here.
The Early Bird registration for DrupalCon Orlando 2027 opens Monday, 14 September 2026 at 8:00 am EST, with tickets available for $650. And Early Bird comes with a special perk. Paid Early Bird DrupalCon tickets include a limited-edition DrupalCon PHP elePHPant named Drupy (Elephpas hypertextus drupalensis primus in Latin), available exclusively during the Early Bird registration period.
Free tickets do not include an elePHPant, but you'll have the option to purchase one during registration while supplies are available.
Kick off DrupalCon Orlando on Monday, 22 March 2027 with a full day of deeper learning and industry-specific discussions, all available as add-ons to your registration.
Choose from six summits tailored to your interests: AI · Government · Higher Education · Nonprofit · Healthcare · Community.
Two summits with special pricing: the Community Summit is free for all DrupalCon registrants, and the Nonprofit Summit is free for Nonprofit ticket holders.
One focused training on offer: AI Inside Drupal: From Smart Editorial Workflows to Canvas Agents That Build Pages, presented by DrupalEasy.
Save the Tuesday night, 23 March 2027, for the DrupalCon Community Party, featuring something brand new for Orlando: the first-ever DrupalCon Talent Show!
It's FREE, and opting in helps us plan for everyone who wants to join us Tuesday night.
More details are coming soon.
There's still time to help shape the DrupalCon Orlando 2027 program! We're accepting speaker submissions through 20 October 2026.
Submit your DrupalCon Orlando session.
Bytes the Gator is making his way around the Drupal community and you can join the fun for a chance to win a free registration to DrupalCon Orlando 2027. Can't attend a Drupal event or find Bytes? Another alligator works too, preferably not a live one!
Meet Bytes and learn how to enter the mascot contest.
This month the team completed the migration of Drupal's security issue tracking to git.drupalcode.org, making the volunteer Security Team faster and easier to grow.
The broader issue migration now covers 90,000+ issues across 7,200+ projects. Release packages were re-signed for 3,200+ projects through Rugged, our new package signing pipeline.
localize.drupal.org and jobs.drupal.org have moved to modern cloud infrastructure, and the Drupal 11 upgrade of the new Drupal.org platform is underway.
Next up: porting community events to new.drupal.org so we can retire groups.drupal.org.
We are excited to announce the winner of 2026 Community At-Large Board Elections. We would like to congratulate and welcome our newest board member, Janna Malikova, for winning the community-elected seat.
We are grateful to Alejandro Moreno for their service and dedication to Drupal and the community, and to all the candidates who applied this year. Read the full announcement here.
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.
The Drupal Association is excited to announce the winner of 2026 Community At-Large Board Elections.
We extend a sincere thank you to Alejandro Moreno for his service and dedication, not only to Drupal, but to the Drupal community. Your time spent on the board made such a difference to the future of the Drupal project, and we thank you all for participating with grace, thoughtfulness, and insightful contributions.
We would like to congratulate and welcome our newest board member, Janna Malikova, for winning the community-elected seat during our 2026 At-Large Board Elections.
We cannot wait to see all the amazing things Janna will accomplish while on the Drupal Association Board.
There were 8 candidates in this year’s At-Large board member election. 307 voters cast their ballots out of a pool of 1274 eligible voters. Eligible voters are active Drupal Association members, known as Ripple Makers, whose membership must have been active at least 24 hours before voting opened.
Under Approval Voting, each eligible voter can give a vote to one or more candidates.
The final total of votes were as follows:
|
Candidate |
Votes |
|
Scott Falconer |
74 |
|
James Abrahams |
131 |
|
Bert Boerland |
120 |
|
Chris Kelly |
26 |
|
Darren Oh |
57 |
|
Janna Malikova |
141 |
|
Helge Notø |
74 |
|
Matthew Saunders |
128 |
On behalf of all the staff and board of the Drupal Association, a heartfelt Drupal Thanks to all of you who stood for the elections this year. It truly is a big commitment to contribution, the Drupal Association, and the community, and we are so grateful for all of your voices. Thank you for your willingness to serve, and we hope you’ll consider participating again in 2027!