For most of the web’s history, we have designed digital experiences around a simple assumption: a person will visit our website. That person might arrive through a search engine, follow a campaign link, scan a QR code, or maybe even type the URL into their browser.
AI is changing that... dramatically and rapidly!
People are now asking AI assistants to research products, compare services, explain policies, recommend suppliers and complete tasks on their behalf. Sometimes, they might not even consciously choose AI and are simply guided by seemingly familiar tools like Google 'AI Overviews'. Either way, instead of visiting ten websites, a customer may ask one assistant to gather the relevant information and present a recommendation.
In the near future, that AI assistant could be doing more than reading a web page: checking product availability, requesting information, preparing an application, arranging an appointment or even completing a transaction.
Your next website visitor may not be a person at all, but an AI agent acting on their behalf, which raises a serious question:
Can AI systems understand our organisation, trust our information and interact with our services safely?
To be useful, AI assistants need to find the right information, understand its meaning and decide whether it is current and trustworthy.
A prospective student asking an assistant to compare courses across several universities, a buyer requesting a shortlist of products that meet detailed technical, ethical and budget requirements - both are now part of your website’s audience.
While human visitors use navigation, page layouts, graphic cues and calls to action, AI systems depend more heavily on structured information, descriptive metadata, clear relationships and reliable access to data.
Your web pages may look perfectly clear to a person but remain ambiguous to a machine. For example, a human might understand from the design that one contact address is intended for media enquiries, and another is for customer enquiries, but an AI assistant may not interpret it correctly unless it’s represented clearly in the underlying content structure.
The content management decisions you make today will shape how accurately they are represented by AI tomorrow.
Many organisations are currently focused on whether their content appears in AI-generated answers. That is important, but visibility is only one part of the problem.
An AI system also needs to understand:
Without this context, AI assistants may rely on outdated pages, confuse similar services or combine information that was never intended to be used together.
Preparing for AI visitors therefore requires more than content. It requires a well-structured and reliably governed source of truth.
Drupal treats content as structured information rather than a collection of web pages. A university course, for example, could have defined fields for qualification, fees and application route, rather than burying them in a block of text. That structure is what makes the same content usable well beyond a single page.
For a human visitor, Drupal assembles that information into an attractive and accessible page. For an AI visitor, the same structure makes the information easier to identify, compare and reuse.
You don't need to maintain one version of content for people and another for machines because Drupal allows the same governed content to serve websites, applications, search services and AI agents.
AI systems are powerful, but they are only as dependable as the information and context available to them. The idea of autonomous agents can quickly become uncomfortable when governance is treated as an afterthought: what happens if an agent uses sensitive information, makes an unsuitable change, or you simply can't tell why an action occurred?
Drupal can provide a controlled source of organisational knowledge. Its content model, taxonomy and relationship system describe what information means, not simply where it appears on a page, helping an AI assistant distinguish a current policy from an archived one, or a general contact address from a specialist enquiry route.
The Drupal AI ecosystem is developing capabilities to support this level of governance, including guardrails for requests and responses, observability and activity logging, controlled access to organisational context, provider-independent integrations, and human review and approval workflows.
This is especially valuable for large or complex digital estates, where information is created by multiple departments across different languages and regions.Drupal's advanced AI implementation and integration does not negate all risk from AI usage, but it does give you a stronger foundation for identifying and managing it
Put simply, AI makes content governance essential to digital communication.
Making content understandable is the first step. The next is enabling controlled action
Giving an AI agent access to your digital platform creates an obvious concern: what will it be allowed to see and do?
Drupal has long supported detailed roles and permissions, allowing different users to view, edit, approve or publish specific types of content.
The same principle can be applied to AI visitors. A useful agent may need to inspect content, search records, or carry out an action, but it should never gain unrestricted access to your systems, or expose private content simply because that content exists in the same system. It should only be able to access the information and tools permitted for the person, service or task it represents.
The Drupal AI Initiative organises this work through two connected areas:
This changes the role of the content management system from being a 'human experience engine' to being a governed platform through which people, applications and AI agents can understand and interact with your organisation.
Human visitors are not disappearing. People will continue to value clear information, strong design, accessible services and experiences that feel relevant and trustworthy. However, they will increasingly use AI to navigate and make sense of the vast amount of information available to them.
AI readiness can look like a technology challenge, but an AI system cannot reliably represent your brand if the underlying content is fragmented, duplicated or poorly structured.
The organisations that adapt successfully will not choose between human-centred design and machine-readable content. They will build digital platforms that support both by creating information people can understand, data machines can interpret and processes agents can interact with safely.
Your next website visitor might not be human - will your digital platform know exactly how to help them?
Try Drupal today!
For most of the web’s history, we have designed digital experiences around a simple assumption: a person will visit our website. That person might arrive through a search engine, follow a campaign link, scan a QR code, or maybe even type the URL into their browser.
AI is changing that... dramatically and rapidly!
People are now asking AI assistants to research products, compare services, explain policies, recommend suppliers and complete tasks on their behalf. Sometimes, they might not even consciously choose AI and are simply guided by seemingly familiar tools like Google 'AI Overviews'. Either way, instead of visiting ten websites, a customer may ask one assistant to gather the relevant information and present a recommendation.
In the near future, that AI assistant could be doing more than reading a web page: checking product availability, requesting information, preparing an application, arranging an appointment or even completing a transaction.
Your next website visitor may not be a person at all, but an AI agent acting on their behalf, which raises a serious question:
Can AI systems understand our organisation, trust our information and interact with our services safely?
To be useful, AI assistants need to find the right information, understand its meaning and decide whether it is current and trustworthy.
A prospective student asking an assistant to compare courses across several universities, a buyer requesting a shortlist of products that meet detailed technical, ethical and budget requirements - both are now part of your website’s audience.
While human visitors use navigation, page layouts, graphic cues and calls to action, AI systems depend more heavily on structured information, descriptive metadata, clear relationships and reliable access to data.
Your web pages may look perfectly clear to a person but remain ambiguous to a machine. For example, a human might understand from the design that one contact address is intended for media enquiries, and another is for customer enquiries, but an AI assistant may not interpret it correctly unless it’s represented clearly in the underlying content structure.
The content management decisions you make today will shape how accurately they are represented by AI tomorrow.
Many organisations are currently focused on whether their content appears in AI-generated answers. That is important, but visibility is only one part of the problem.
An AI system also needs to understand:
Without this context, AI assistants may rely on outdated pages, confuse similar services or combine information that was never intended to be used together.
Preparing for AI visitors therefore requires more than content. It requires a well-structured and reliably governed source of truth.
Drupal treats content as structured information rather than a collection of web pages. A university course, for example, could have defined fields for qualification, fees and application route, rather than burying them in a block of text. That structure is what makes the same content usable well beyond a single page.
For a human visitor, Drupal assembles that information into an attractive and accessible page. For an AI visitor, the same structure makes the information easier to identify, compare and reuse.
You don't need to maintain one version of content for people and another for machines because Drupal allows the same governed content to serve websites, applications, search services and AI agents.
AI systems are powerful, but they are only as dependable as the information and context available to them. The idea of autonomous agents can quickly become uncomfortable when governance is treated as an afterthought: what happens if an agent uses sensitive information, makes an unsuitable change, or you simply can't tell why an action occurred?
Drupal can provide a controlled source of organisational knowledge. Its content model, taxonomy and relationship system describe what information means, not simply where it appears on a page, helping an AI assistant distinguish a current policy from an archived one, or a general contact address from a specialist enquiry route.
The Drupal AI ecosystem is developing capabilities to support this level of governance, including guardrails for requests and responses, observability and activity logging, controlled access to organisational context, provider-independent integrations, and human review and approval workflows.
This is especially valuable for large or complex digital estates, where information is created by multiple departments across different languages and regions.Drupal's advanced AI implementation and integration does not negate all risk from AI usage, but it does give you a stronger foundation for identifying and managing it
Put simply, AI makes content governance essential to digital communication.
Making content understandable is the first step. The next is enabling controlled action
Giving an AI agent access to your digital platform creates an obvious concern: what will it be allowed to see and do?
Drupal has long supported detailed roles and permissions, allowing different users to view, edit, approve or publish specific types of content.
The same principle can be applied to AI visitors. A useful agent may need to inspect content, search records, or carry out an action, but it should never gain unrestricted access to your systems, or expose private content simply because that content exists in the same system. It should only be able to access the information and tools permitted for the person, service or task it represents.
The Drupal AI Initiative organises this work through two connected areas:
This changes the role of the content management system from being a 'human experience engine' to being a governed platform through which people, applications and AI agents can understand and interact with your organisation.
Human visitors are not disappearing. People will continue to value clear information, strong design, accessible services and experiences that feel relevant and trustworthy. However, they will increasingly use AI to navigate and make sense of the vast amount of information available to them.
AI readiness can look like a technology challenge, but an AI system cannot reliably represent your brand if the underlying content is fragmented, duplicated or poorly structured.
The organisations that adapt successfully will not choose between human-centred design and machine-readable content. They will build digital platforms that support both by creating information people can understand, data machines can interpret and processes agents can interact with safely.
Your next website visitor might not be human - will your digital platform know exactly how to help them?
Try Drupal today!
Article by: Martin Anderson-Clutz. Originally posted on the Acquia blog.
Drupal turns decoupled architecture into a governed AI harness, combining live visual editing with agent-ready content schemas.
Back in March, at EvolveDigital in Toronto, I ran into Preston So. He mentioned that the team behind Decoupled Days was looking for speakers, and that this year the event would be in Montréal. I was interested right away. Drupal Canvas is the most compelling answer I have seen to a problem that has followed decoupled architectures for years, and I wanted that message to reach beyond the Drupal faithful — out to the practitioners who live and breathe headless every day.
The talk I ended up giving was not really about a content management system at all. It was about how Drupal has quietly become something else: a governed harness for artificial intelligence. Here is the argument I made, the demo that seemed to land hardest with the room, and why I think 2026 is the year the trade-offs of going headless finally stop being trade-offs.
Drupal did not arrive late to the headless conversation. Far from it. The community committed to an API-first architecture roughly a decade ago, and a vibrant subcommunity has been refining decoupled patterns ever since. That work produced a spectrum of delivery models rather than a single one: traditional, where Drupal renders everything; progressively decoupled, where a JavaScript front end takes over the parts of the page that benefit from it while editorial preview stays intact; and fully decoupled, where Drupal is a pure API feeding any number of channels.
That range matters, because it means Drupal has never been only a content API. It owns content, delivery, and governance at the same time. The headless-native platforms compete on one of those axes. Drupal competes on all three.
When organizations adopted front-end frameworks like Next.js and Astro, most of them accepted what I think of as the headless bargain. They gained fast front ends and their choice of framework, and in exchange they gave up live visual editing, layout control, and real-time editorial preview. Editors went from composing pages to filling in form fields blind and filing tickets for changes they used to make themselves.
The industry tried to patch around this — bespoke preview services, visual editors bolted onto the front end, what amounted to Storybook pressed into service as a content tool. None of it fully closed the gap.
Drupal Canvas, which shipped as the default editing experience in Drupal CMS 2.0, closes it a different way. It delivers a true-to-life editing workspace where content creators edit layouts live in the browser, and the site still ships as a high-performance decoupled front end. The CMS stopped being the bottleneck and became the conductor. You keep Next.js or Astro, and you get the editorial experience back.
Something larger is happening underneath all of this. For most of the last two decades, the job of a CMS was to model content and publish it to channels. Through 2024 and 2025, artificial intelligence showed up inside these platforms as a feature — an assist button in a text box that summarized a paragraph or suggested tags when a human clicked it.
By 2026, that framing is obsolete. Artificial intelligence has become infrastructure rather than an accessory: autonomous agents that run scheduled jobs, batch operations, and real-time triggers. Analysts have adopted new vocabulary to match, from agentic experience platforms to AI-ready content management. Three capabilities now separate a platform that is serious about this from one that is not: the Model Context Protocol (MCP), which lets external agents query and update content through one standard interface; autonomous agents that behave like digital teammates; and answer engine optimization, which structures content so it surfaces accurately inside tools like ChatGPT and Perplexity.
And the whole category is converging on the same destination. Headless-native platforms like Sanity, Contentstack, and Storyblok others are all racing to add agents, automation, and AI-assisted authoring. When everyone is heading for the same place, the differentiator is no longer whether a platform has AI. It is how that AI is governed and orchestrated.
Even the most capable models today are prone to hallucination, blind to context they are not explicitly given, and easy to push outside the bounds of what an organization would allow. That is why almost no one uses a raw model directly. They use a harness: the code around the model that improves the quality, safety, and reliability of what comes back. A harness augments the query, enforces guardrails on input and output, and adds tools that give the model real capabilities.
Think of your AI model as the engine: the part that makes your reasoning system go. The harness is the vehicle built around it: the controls that point it in the right direction, change gears when the situation calls for it, and bring it to a stop when needed.
If you list what a good AI harness needs — structured content the model can reason over, access control, deterministic workflows, versioned and reviewable configuration, and centralized governance — Drupal has shipped every one of those for years, for reasons that had nothing to do with AI. The model at the center is a commodity. It is swappable, replaceable, and never the true value driver. Everything Drupal wraps around it is the durable part.
Which leads to the line I kept coming back to: what drives the value of intelligent systems is your schema, not your prompt. Prompts are transient. Typed fields, entity relationships, and taxonomy give a model unambiguous ground truth instead of prose it has to guess at. And the same JSON:API structure that feeds your decoupled front end is exactly what an external agent inspects and reasons over. Drupal orchestrates the content and context; the external model supplies the intelligence. That division of labor ages far better than trying to build models in-house.
Everything above is architecture. The demo is where it becomes visible, and it is the part of the talk the audience responded to most.
I had set up a demo environment for a fictional company called Inspace. Ahead of time, I populated the Context Control Center with the things a real brand would have on hand: a brand guide, a tone of voice, documentation for a component library I had programmatically migrated from Drupal's Mercury design system into Code Components and synced into Astro, and a set of context items describing a new "Executive Suites" offering that Inspace was preparing to launch.
Then, live, I created a new page in Canvas, opened Canvas AI, and gave it one sentence: generate a landing page for the new Executive Suites offering. It went to work, and while it did, I took questions from the audience. A couple of minutes later it had assembled a full landing page out of real components, populated with relevant, on-brand content. To make the point that a human stays in the loop, I dropped an image from the media library into the hero component and published. Then I switched to the Astro app, navigated to the same path, and there was the identical page — every decision the human and the model had made, rendered by the decoupled front end. A complete landing page, start to finish, in a couple of minutes.
The second beat pushed further. The marketing team wants a brand-new component: a call to action for a waitlist. I asked Canvas AI to build a full-width announcement banner with an announcement pill, a headline, a supporting line, and a primary call to action. After a short pause, the component appeared in the Canvas interface — colors on brand, formatting consistent with the rest of the library — with its code fully visible and editable and a live preview I could resize to check different breakpoints. I noted that in the real world you might refine the code yourself or ask Canvas AI to iterate, then saved it to the library, dragged it into the Executive Suites page, and published.
When I reloaded the Astro app, it threw a fatal error, exactly as I had planned. The layout now referenced a component the front end did not know about. One npx canvas push from the command line synced the components, a refresh brought the page back, and the new banner rendered cleanly in the Astro layout. That deliberate stumble made the architecture legible: content edits flow to the front end instantly, but new component code is a real, versioned artifact that moves through a real workflow.
I closed the demo by going back to the Context Control Center, because that is the intelligence that made the rest possible. This is what AI prompt grounding looks like in practice: before a single token is generated, each request is automatically supplied with the brand voice, domain knowledge, and guardrails relevant to the task at hand. Some context items are global and travel with every request. Others are scoped specifically to working in Canvas. Others still apply only to content about the Executive Suites program. All of them were assembled automatically behind those short prompts — which is why one sentence was enough to get on-brand, relevant output. I finished on the form for managing a single context item, showing the range of ways its use can be scoped and restricted. Compliance before generation, not review after.
For regulated and enterprise teams, governance is where this stops being a demo and starts being a decision. Drupal is model-agnostic by design: dozens of providers sit behind one abstraction layer, spanning cloud services like OpenAI, Anthropic, and Gemini as well as self-hosted options like Ollama and Mistral for data sovereignty. Swapping providers is a configuration change, not a rewrite of your schemas or your logic.
Agents act inside Drupal's existing permission model which includes the Access Policy API, so the access logic that already governs your people governs your agents too — no separate guardrail layer to maintain. Deterministic orchestration through the Event-Condition-Action (ECA) or FlowDrop frameworks handle rules-based logic that costs no tokens and never hallucinates, which is a useful reminder that the cheapest, most reliable AI call is often the one you do not make. And because that orchestration lives inside the platform as native state machines — ECA for event-driven rules, Maestro for durable, multi-step approvals — stateful business logic runs where the content lives, rather than being stitched together from external webhooks, serverless functions, and third-party glue code. Guardrails filter sensitive data before it leaves the server, and metering tracks token spend by user and role so finance can see what AI actually costs.
It doesn't serve anyone to pretend one side wins everything, and I said so in Montréal. The headless-native platforms lead on real things: faster time to value, a cleaner developer experience, and more polished agentic tooling in market today. If those are your priorities right now, they are genuine strengths.
Where Drupal leads is open source with no lock-in and dozens of documented APIs, model-agnostic freedom, deep governance and orchestration, and fit for enterprise, multi-brand, and regulated environments. It is also worth remembering the shape of the thing behind it: an open ecosystem moves at the speed of everyone who needs it to, while a single-vendor roadmap moves at the speed of one company's priorities.
The way I put it at the end of the talk: we gave up the editorial experience to go headless, and in 2026 we stopped having to. The original headless win is now additive with the editorial win, not traded against it. One structured content model can serve four consumers at once — a decoupled front end, editors in Canvas, internal AI agents, and the wider martech stack over MCP.
Drupal is not a CMS with AI features bolted on. It is a governed AI harness that happens to have been building the right foundations for 20 years. If you want to see it for yourself, start with Drupal CMS 2.0 and Canvas, then explore the AI, context, and MCP modules. For teams that would rather not set up and host Drupal themselves, Acquia Source CMS offers a fully managed on-ramp to the same platform. And if you are ready to help shape where this goes, the Drupal AI Initiative is where the work is happening.
Making that case in Montréal was a highlight of my year. If you were in the room, thank you — the questions were sharp, and a few of them changed how I will explain this next time. If you were not, come find me, and we can pick up where the talk left off.
Article by: Martin Anderson-Clutz. Originally posted on the Acquia blog.
Drupal turns decoupled architecture into a governed AI harness, combining live visual editing with agent-ready content schemas.
Back in March, at EvolveDigital in Toronto, I ran into Preston So. He mentioned that the team behind Decoupled Days was looking for speakers, and that this year the event would be in Montréal. I was interested right away. Drupal Canvas is the most compelling answer I have seen to a problem that has followed decoupled architectures for years, and I wanted that message to reach beyond the Drupal faithful — out to the practitioners who live and breathe headless every day.
The talk I ended up giving was not really about a content management system at all. It was about how Drupal has quietly become something else: a governed harness for artificial intelligence. Here is the argument I made, the demo that seemed to land hardest with the room, and why I think 2026 is the year the trade-offs of going headless finally stop being trade-offs.
Drupal did not arrive late to the headless conversation. Far from it. The community committed to an API-first architecture roughly a decade ago, and a vibrant subcommunity has been refining decoupled patterns ever since. That work produced a spectrum of delivery models rather than a single one: traditional, where Drupal renders everything; progressively decoupled, where a JavaScript front end takes over the parts of the page that benefit from it while editorial preview stays intact; and fully decoupled, where Drupal is a pure API feeding any number of channels.
That range matters, because it means Drupal has never been only a content API. It owns content, delivery, and governance at the same time. The headless-native platforms compete on one of those axes. Drupal competes on all three.
When organizations adopted front-end frameworks like Next.js and Astro, most of them accepted what I think of as the headless bargain. They gained fast front ends and their choice of framework, and in exchange they gave up live visual editing, layout control, and real-time editorial preview. Editors went from composing pages to filling in form fields blind and filing tickets for changes they used to make themselves.
The industry tried to patch around this — bespoke preview services, visual editors bolted onto the front end, what amounted to Storybook pressed into service as a content tool. None of it fully closed the gap.
Drupal Canvas, which shipped as the default editing experience in Drupal CMS 2.0, closes it a different way. It delivers a true-to-life editing workspace where content creators edit layouts live in the browser, and the site still ships as a high-performance decoupled front end. The CMS stopped being the bottleneck and became the conductor. You keep Next.js or Astro, and you get the editorial experience back.
Something larger is happening underneath all of this. For most of the last two decades, the job of a CMS was to model content and publish it to channels. Through 2024 and 2025, artificial intelligence showed up inside these platforms as a feature — an assist button in a text box that summarized a paragraph or suggested tags when a human clicked it.
By 2026, that framing is obsolete. Artificial intelligence has become infrastructure rather than an accessory: autonomous agents that run scheduled jobs, batch operations, and real-time triggers. Analysts have adopted new vocabulary to match, from agentic experience platforms to AI-ready content management. Three capabilities now separate a platform that is serious about this from one that is not: the Model Context Protocol (MCP), which lets external agents query and update content through one standard interface; autonomous agents that behave like digital teammates; and answer engine optimization, which structures content so it surfaces accurately inside tools like ChatGPT and Perplexity.
And the whole category is converging on the same destination. Headless-native platforms like Sanity, Contentstack, and Storyblok others are all racing to add agents, automation, and AI-assisted authoring. When everyone is heading for the same place, the differentiator is no longer whether a platform has AI. It is how that AI is governed and orchestrated.
Even the most capable models today are prone to hallucination, blind to context they are not explicitly given, and easy to push outside the bounds of what an organization would allow. That is why almost no one uses a raw model directly. They use a harness: the code around the model that improves the quality, safety, and reliability of what comes back. A harness augments the query, enforces guardrails on input and output, and adds tools that give the model real capabilities.
Think of your AI model as the engine: the part that makes your reasoning system go. The harness is the vehicle built around it: the controls that point it in the right direction, change gears when the situation calls for it, and bring it to a stop when needed.
If you list what a good AI harness needs — structured content the model can reason over, access control, deterministic workflows, versioned and reviewable configuration, and centralized governance — Drupal has shipped every one of those for years, for reasons that had nothing to do with AI. The model at the center is a commodity. It is swappable, replaceable, and never the true value driver. Everything Drupal wraps around it is the durable part.
Which leads to the line I kept coming back to: what drives the value of intelligent systems is your schema, not your prompt. Prompts are transient. Typed fields, entity relationships, and taxonomy give a model unambiguous ground truth instead of prose it has to guess at. And the same JSON:API structure that feeds your decoupled front end is exactly what an external agent inspects and reasons over. Drupal orchestrates the content and context; the external model supplies the intelligence. That division of labor ages far better than trying to build models in-house.
Everything above is architecture. The demo is where it becomes visible, and it is the part of the talk the audience responded to most.
I had set up a demo environment for a fictional company called Inspace. Ahead of time, I populated the Context Control Center with the things a real brand would have on hand: a brand guide, a tone of voice, documentation for a component library I had programmatically migrated from Drupal's Mercury design system into Code Components and synced into Astro, and a set of context items describing a new "Executive Suites" offering that Inspace was preparing to launch.
Then, live, I created a new page in Canvas, opened Canvas AI, and gave it one sentence: generate a landing page for the new Executive Suites offering. It went to work, and while it did, I took questions from the audience. A couple of minutes later it had assembled a full landing page out of real components, populated with relevant, on-brand content. To make the point that a human stays in the loop, I dropped an image from the media library into the hero component and published. Then I switched to the Astro app, navigated to the same path, and there was the identical page — every decision the human and the model had made, rendered by the decoupled front end. A complete landing page, start to finish, in a couple of minutes.
The second beat pushed further. The marketing team wants a brand-new component: a call to action for a waitlist. I asked Canvas AI to build a full-width announcement banner with an announcement pill, a headline, a supporting line, and a primary call to action. After a short pause, the component appeared in the Canvas interface — colors on brand, formatting consistent with the rest of the library — with its code fully visible and editable and a live preview I could resize to check different breakpoints. I noted that in the real world you might refine the code yourself or ask Canvas AI to iterate, then saved it to the library, dragged it into the Executive Suites page, and published.
When I reloaded the Astro app, it threw a fatal error, exactly as I had planned. The layout now referenced a component the front end did not know about. One npx canvas push from the command line synced the components, a refresh brought the page back, and the new banner rendered cleanly in the Astro layout. That deliberate stumble made the architecture legible: content edits flow to the front end instantly, but new component code is a real, versioned artifact that moves through a real workflow.
I closed the demo by going back to the Context Control Center, because that is the intelligence that made the rest possible. This is what AI prompt grounding looks like in practice: before a single token is generated, each request is automatically supplied with the brand voice, domain knowledge, and guardrails relevant to the task at hand. Some context items are global and travel with every request. Others are scoped specifically to working in Canvas. Others still apply only to content about the Executive Suites program. All of them were assembled automatically behind those short prompts — which is why one sentence was enough to get on-brand, relevant output. I finished on the form for managing a single context item, showing the range of ways its use can be scoped and restricted. Compliance before generation, not review after.
For regulated and enterprise teams, governance is where this stops being a demo and starts being a decision. Drupal is model-agnostic by design: dozens of providers sit behind one abstraction layer, spanning cloud services like OpenAI, Anthropic, and Gemini as well as self-hosted options like Ollama and Mistral for data sovereignty. Swapping providers is a configuration change, not a rewrite of your schemas or your logic.
Agents act inside Drupal's existing permission model which includes the Access Policy API, so the access logic that already governs your people governs your agents too — no separate guardrail layer to maintain. Deterministic orchestration through the Event-Condition-Action (ECA) or FlowDrop frameworks handle rules-based logic that costs no tokens and never hallucinates, which is a useful reminder that the cheapest, most reliable AI call is often the one you do not make. And because that orchestration lives inside the platform as native state machines — ECA for event-driven rules, Maestro for durable, multi-step approvals — stateful business logic runs where the content lives, rather than being stitched together from external webhooks, serverless functions, and third-party glue code. Guardrails filter sensitive data before it leaves the server, and metering tracks token spend by user and role so finance can see what AI actually costs.
It doesn't serve anyone to pretend one side wins everything, and I said so in Montréal. The headless-native platforms lead on real things: faster time to value, a cleaner developer experience, and more polished agentic tooling in market today. If those are your priorities right now, they are genuine strengths.
Where Drupal leads is open source with no lock-in and dozens of documented APIs, model-agnostic freedom, deep governance and orchestration, and fit for enterprise, multi-brand, and regulated environments. It is also worth remembering the shape of the thing behind it: an open ecosystem moves at the speed of everyone who needs it to, while a single-vendor roadmap moves at the speed of one company's priorities.
The way I put it at the end of the talk: we gave up the editorial experience to go headless, and in 2026 we stopped having to. The original headless win is now additive with the editorial win, not traded against it. One structured content model can serve four consumers at once — a decoupled front end, editors in Canvas, internal AI agents, and the wider martech stack over MCP.
Drupal is not a CMS with AI features bolted on. It is a governed AI harness that happens to have been building the right foundations for 20 years. If you want to see it for yourself, start with Drupal CMS 2.0 and Canvas, then explore the AI, context, and MCP modules. For teams that would rather not set up and host Drupal themselves, Acquia Source CMS offers a fully managed on-ramp to the same platform. And if you are ready to help shape where this goes, the Drupal AI Initiative is where the work is happening.
Making that case in Montréal was a highlight of my year. If you were in the room, thank you — the questions were sharp, and a few of them changed how I will explain this next time. If you were not, come find me, and we can pick up where the talk left off.
This week's release of Drupal AI Context Beta 4 added taxonomy-based context selection, priority controls, workflow states, and token-budget visibility. Kristen Pol, primary maintainer of Context Control Center, said the project is moving towards its first release candidate, while Drupal.org release notes list 70 credited issues in the beta. The additions put more structure around deciding what information reaches an AI agent before it acts.
The release arrived as Drupal founder Dries Buytaert was asking a broader question about what happens when AI makes code cheaper to produce. In a 17 August 2026 blog post, Dries argued that as application functionality becomes easier to recreate, commercial value may shift towards dependable operation: deployment, security, scaling, monitoring, and reliable service over time. His argument is about software economics rather than AI context, but it points to the same larger change: implementation is no longer the only scarce input.
The DropTimes' 18 August interview with Kristen showed where that shift meets Drupal AI. Context Control Center can use moderation, revisions, permissions, scheduling, and scopes to govern the knowledge supplied to a model, but those controls cannot guarantee how the model will respond. Requirements that cannot tolerate probabilistic behaviour still need deterministic rules, validation, access controls, or human approval.
A similar distinction appeared in open-source development. Symfony founder Fabien Potencier began an issue-first contribution experiment for Symfony Language Tools on 19 August 2026. The experiment applies only to that repository. When coding agents can handle more of the implementation, the context supplied by the person reporting an issue — including the application setup, configuration, failure conditions, and intended behaviour — becomes a larger part of the contribution.
The same pressure appears after generation. Content Sync's Drupal governance argument is that faster content creation does not remove decisions about ownership, approvals, local adaptation, and which version remains authoritative. AI can reduce drafting time while leaving organisations with more material to review, maintain, and govern.
These developments put the difficult work somewhere other than generation alone. Faster implementation does not define the problem, determine which knowledge is authoritative, establish the constraints, review the result, or make the finished system dependable. Code may become easier to produce without making context, validation, operations, or human judgement easier to replace.
At The DropTimes' August Open Town Hall on 19 August 2026, the editorial team described a similar shift in its AI coverage: looking more closely at agent context, permitted actions, validation, and human review, alongside a broader effort to distinguish what sources claim from what available evidence establishes.
Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.
This issue of Editor’s Pick was written and curated by Allen Jason.
read moreDDEV's generic project type will run anything that brings its own web server, and people already use it for Node and other stacks. Umbraco is a less-travelled case: .NET, Kestrel, and SQL Server. I wanted to know how much of the DDEV experience still holds up there. Clone a repository, run one command, have a working site and database a few minutes later.
Most of it holds up. The result is umbraco-clean-ddev, which runs Umbraco on .NET 10 with SQL Server and Adminer, and gets a new developer going with a single ddev start. What took the time was a handful of places where DDEV expected something I had not worked out yet.
I wanted four things out of this, and nothing more ambitious than that.
DDEV already does all of this elsewhere. The Umbraco Cloud backup turned out to be the least transferable: ddev import-db and ddev export-db work on the database container DDEV manages, and this project omits that container entirely. Anything equivalent I would have to write myself.
Keeping the dependencies off my machine also makes the project easier to hand to someone who has never worked with .NET. The SDK and SQL Server both live in containers, so trying Umbraco does not start with installing either of them locally. Clone the repository, run one command, and the CMS is there to look at.
DDEV's generic type doesn't start nginx or PHP-FPM, which is what you want when the application brings its own web server:
# .ddev/config.yaml
name: umbraco-clean
type: generic
docroot: ""
webserver_type: generic
omit_containers: [db]
disable_settings_management: true
omit_containers: [db] drops DDEV's MariaDB, since SQL Server runs as a separate service and MariaDB would only sit there idling.
A generic web server type also emits no default router configuration, so without one, every request 404s. web_extra_exposed_ports supplies it:
# .ddev/config.yaml
web_extra_exposed_ports:
- name: umbraco
container_port: 80
http_port: 80
https_port: 443
Those two port numbers being equal matters. DDEV builds the Traefik backend URL from http_port rather than container_port, so an otherwise reasonable pairing of container_port: 8080 with http_port: 80 sends traffic to port 80 in the container and returns a 502. I lost a while to that one before reading the router configuration it generates.
DDEV's web image has no .NET SDK, so .ddev/web-build/Dockerfile.dotnet adds one. The important thing about that file is what it does not contain:
# .ddev/web-build/Dockerfile.dotnet
RUN curl -fsSL https://packages.microsoft.com/config/debian/13/packages-microsoft-prod.deb -o /tmp/pmp.deb \
&& dpkg -i /tmp/pmp.deb \
&& rm /tmp/pmp.deb \
&& apt-get update \
&& ACCEPT_EULA=Y apt-get install -y dotnet-sdk-10.0 mssql-tools18 \
&& rm -rf /var/lib/apt/lists/*
RUN dotnet tool install --tool-path /usr/local/share/dotnet-tools microsoft.sqlpackage
ENV PATH="$PATH:/usr/local/share/dotnet-tools:/opt/mssql-tools18/bin"
There is no FROM line. DDEV prepends its own, and adding one starts a fresh stage that throws away the user setup, supervisord, healthcheck and tooling that make the container a DDEV container. You would have to rebuild all of that yourself, which I do not recommend as a way to spend an evening.
Debian trixie ships no .NET packages, so the SDK comes from Microsoft's feed, registered by installing packages-microsoft-prod.deb. Only .NET 10 publishes an ARM64 build there, so anyone on Apple Silicon has a floor of 10.0.
I also left webimage_extra_packages out of config.yaml on purpose. DDEV injects it ahead of the web-build Dockerfile, so any package listed there is looked up before the Microsoft feed exists.
Full SQL Server publishes no ARM64 image, so the database service is Azure SQL Edge. It speaks the same TDS protocol and Umbraco cannot tell the difference.
DDEV does have an add-on for SQL Server, ddev-sqlsrv, which runs full SQL Server and works on Apple Silicon through Rosetta 2 emulation. Apple has announced Rosetta is going away, and I wanted to see what was possible without installing it.
This is the choice I would most like to revisit. If Microsoft ever publishes an ARM64 image, I would rather be running full SQL Server than Azure SQL Edge.
# .ddev/docker-compose.umbraco.yaml
services:
sqlserver:
container_name: ddev-${DDEV_SITENAME}-sqlserver
image: mcr.microsoft.com/azure-sql-edge:latest
environment:
- ACCEPT_EULA=Y
- MSSQL_SA_PASSWORD=${MSSQL_SA_PASSWORD}
volumes:
- sqlserver-data:/var/opt/mssql
healthcheck:
test:
- CMD-SHELL
- python3 -c "import socket; s=socket.create_connection(('localhost',1433),2); s.close()"
start_period: 30s
The healthcheck is a raw socket connection because Azure SQL Edge ships no sqlcmd to query with. It only proves the port is open, and the server accepts logins a moment after that, so the check is weaker than I would like. The 30 second grace period covers the initialisation of the system databases on a first run, which takes about 20 seconds and would otherwise exhaust the retries.
The named volume is why the database survives a ddev restart: without it every restart would hand Umbraco an empty server and trigger the unattended install again.
Alongside sqlserver and adminer, the compose file carries a short web block, the one place this project reaches into the container DDEV owns:
# .ddev/docker-compose.umbraco.yaml
services:
web:
depends_on:
sqlserver:
condition: service_healthy
environment:
- Umbraco__CMS__WebRouting__UmbracoApplicationUrl=${DDEV_PRIMARY_URL}
condition: service_healthy is what the healthcheck above exists for. It holds the web container until SQL Server answers, so dotnet watch is not racing a database that has not finished booting. UmbracoApplicationUrl hands Umbraco the site's real external address rather than letting it infer one from a request that arrived over plain HTTP from the router. Everything else about the web container is configured through config.yaml, so DDEV keeps ownership of its lifecycle.
The application runs as an extra daemon rather than as a container command:
# .ddev/config.yaml
web_extra_daemons:
- name: umbraco
command: "dotnet watch run --non-interactive --no-launch-profile"
directory: /var/www/html/MyProject
That puts dotnet watch under the web container's supervisord, so supervisord restarts it on failure. Overriding the compose command instead would displace DDEV's own entrypoint, and a build error would leave you with a container that is up but serving nothing.
Five environment variables, two of them there because the router sits in front of Kestrel:
# .ddev/config.yaml
web_environment:
- ASPNETCORE_ENVIRONMENT=Development
- ASPNETCORE_URLS=http://0.0.0.0:80
- ASPNETCORE_FORWARDEDHEADERS_ENABLED=true
- DOTNET_CLI_TELEMETRY_OPTOUT=1
- NUGET_PACKAGES=/mnt/ddev-global-cache/nuget
Kestrel has to bind 0.0.0.0 because the router reaches it across the Docker network rather than over loopback. The forwarded headers setting is easy to miss and confusing when it's absent: the router terminates TLS and forwards plain HTTP, so without it Kestrel decides the request was insecure and generates http:// links on an https:// site.
The NuGet line has nothing to do with the router. It moves the package cache onto a DDEV volume, so a rebuilt container no longer re-downloads every package. The remaining two are ordinary .NET settings that happen to belong here rather than in a launch profile.
ddev start
A pre-start hook copies appsettings.Local.json.example into place when it is missing:
# .ddev/config.yaml
hooks:
pre-start:
- exec-host: "bash -c '[ -f MyProject/appsettings.Local.json ] || cp MyProject/appsettings.Local.json.example MyProject/appsettings.Local.json'"
pre-start rather than post-start, because Kestrel comes up with the container: a post-start hook would write the file after the application had already read its configuration. That phase also forces exec-host, since there is no container yet to run the command inside.
On first boot Umbraco runs its unattended install, creating the schema and the default admin user, admin@example.com with password 1234567890.
:::warning[Error 4060 on first boot]
The first boot logs Cannot open database "UmbracoDb" with error number 4060. The database does not exist until the unattended install creates it, so Umbraco logs the error a couple of times during startup until it can connect and action the unattended install.
:::
After that, ddev dotnet is a passthrough that runs the CLI in the project directory, so nobody needs the SDK on their host to run ddev dotnet build.
This is the one I care most about: pulling a backup down from Umbraco Cloud and running it locally to test or debug against real content. A local environment that cannot take a copy of the site's actual database will not reproduce the bug you are chasing. DDEV's own import-db and export-db talk to the container this project does not have, and Umbraco Cloud backups come as .bacpac files, so I wrote two commands to handle them:
ddev bacpac-export # writes UmbracoDb.bacpac to the project root
ddev bacpac-import UmbracoDb.bacpac
Both wrap sqlpackage, which has no apt package and so gets installed via dotnet tool install in the web image build. Import is the harder of the two: sqlpackage requires an empty or nonexistent target, and Kestrel holds an open connection to the database being dropped:
# .ddev/commands/web/bacpac-import
sqlcmd -S sqlserver -U sa -P "${MSSQL_SA_PASSWORD}" -C -Q "
IF DB_ID('UmbracoDb') IS NOT NULL
BEGIN
ALTER DATABASE UmbracoDb SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE UmbracoDb;
END"
SINGLE_USER WITH ROLLBACK IMMEDIATE forces that connection closed so the drop can proceed. Both commands read and write /var/www/html, which is the host-mounted project root, so a .bacpac downloaded from Cloud goes next to the solution file and imports from there.
.ddev/.env holds the SA password, the Umbraco connection string and the SMTP configuration for mailpit, and it is committed. That is a fixed local development credential in the same spirit as DDEV's own db/db/db, and committing it is what makes a fresh clone work with no manual step. On a project with real secrets I would not do this: the file would move somewhere untracked, and a setup step would have to prompt for the values.
appsettings.Local.json is git-ignored and exists for per-developer overrides such as logging levels. Program.cs registers it after CreateBuilder has already added the environment variable provider, so that file wins over .ddev/.env. A ConnectionStrings block there will override the environment, and someone who then edits the password in .ddev/.env will find it has no effect.
Both files the Adminer add-on provides are committed here, the compose file and the ddev adminer launcher, so ddev add-on get never has to run and a clone starts with Adminer already working. docker-compose.adminer.yaml carries one edit: its default depends_on: [db] is gone, because this project has no db container. Adminer's connection defaults are set in docker-compose.umbraco.yaml instead, pointing it at the sqlserver service. Neither committed copy carries a #ddev-generated marker, so DDEV treats them as mine and leaves them alone. The cost is that they no longer update with the add-on.
The repository is at millnut/umbraco-clean-ddev, built on Paul Seal's Clean starter kit. Clone it, run ddev start, and you should have Umbraco and SQL Server running without either of them touching your machine directly.
It is still a bespoke setup rather than something reusable. The .NET SDK install, the SQL Server service and the bacpac commands are all things I now maintain by hand, and an add-on would be a better home for most of them. If you work with Umbraco or .NET and want to try it, I would be glad to hear what breaks: I have only run this on my own machine, against one project.
read more
When you move a Drupal site to a headless CMS, the thing most likely to break silently is not your content. It is the invisible wiring between pieces of it. Drupal stores relationships as numeric IDs (node 4127, term 88, media 903), and almost every headless platform mints brand-new IDs the moment you import. So every taxonomy tag, every embedded image, every "related articles" block that pointed at an old number now points at nothing, or worse, at whatever content happened to inherit that number. The pages still render. The links inside them just quietly go nowhere. Here is the scene that keeps happening. The migration "succeeds." Every article is present, the word counts match, everyone high-fives. Then two weeks later someone notices the related-content sidebar is empty on 8,000 pages, half the article hero images resolve to a 404, and the tag pages that used to rank now list either…
Read the rest at Replatform Radar
read moreToday we are talking about Drupal, AI, and learning to use it responsibly with guest Mike Anello. We'll also cover Entity Mesh as our module of the week.
For show notes visit: https://www.talkingDrupal.com/566
TopicsMike Anello - drupaleasy.com ultimike
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi JD Flynn - dorficus
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
read more
The International Splash Awards 2026 have reached a new milestone, with 40% more submissions compared to last year.
A huge thank you to everyone who submitted a project and helped make this year’s edition even bigger.
The jury is now reviewing the submissions, with nominations set to be announced in early September.
We look forward to celebrating the projects and teams behind them during DrupalCon Rotterdam 2026.
Thank you to everyone who submitted a design and shared their creativity with the community, and to everyone who took part in the voting. The five finalist designs showed the imagination and community spirit that make DrupalCon so special.
After an open public vote, Juliane Vöske’s design has been selected as the official DrupalCon Rotterdam 2026 T-shirt.
Her winning design will be worn by attendees from across the global Drupal community. This is the T-shirt that will bring us together in Rotterdam.
A few months ago I put an api online to search and query the whole Drupal code ecosystem. With the release of some more capable local AI models I thought it could be good to release a MCP server with that same data optimized for LLM use. Same data, different packaging. The address for the MCP server is:
Add the server to your setup of choice and you'll be able to ask things like:
The conversation at DrupalCon Rotterdam 2026 won't just be about what Drupal CMS 2.x can do — it will be about how teams are actually getting there. Migration is the real-world bridge between the platform you have today and the Recipe-driven, Canvas-powered experience covered in Post #1 of this series.
This post is a hands-on guide covering the three migration paths developers are navigating in 2026, the tools that power each one, and the common pitfalls that derail projects weeks or months into execution. We'll go deep on the Migrate API, look at real YAML definitions, and document the failure modes you're most likely to hit — along with their fixes.
"Migrating to Drupal CMS" covers three structurally different problems. The tools, timeline, and risk profile are different for each:
|
Your Current Platform |
Migration Type |
Primary Tooling |
|
Drupal 7 |
Data + platform upgrade |
Migrate API + Migrate Drupal |
|
Drupal 9 / 10 / 11 (classic) |
Layer adoption, no data move |
Recipes + Canvas adoption |
|
WordPress / Joomla / AEM / Sitecore |
Full platform replacement |
Migrate API + custom source plugins |
Knowing which one you're doing early — before scoping or quoting — is the single biggest factor in accurate estimation.
Regardless of source platform, Drupal's Migrate API is the ETL (Extract–Transform–Load) engine underneath every non-trivial migration. It lives in Drupal core and is composed of three module layers:
Install the contrib layer before anything else:
A source plugin reads rows from legacy data. Process plugins transform field values one by one. The destination plugin writes to Drupal entities. Understanding this pipeline is what separates developers who debug migrations quickly from those who spend days chasing phantom errors.
Drupal 7's end-of-community-life has passed, and commercial extended support windows are closing. If you're still running D7 in 2026, this migration is urgent — not optional.
Add the legacy database as a second connection in settings.php:
Inspecting the Generated Migrations
The upgrade command generates a full set of migration YAML definitions tailored to your D7 module footprint. Before running anything, inspect what was created:
Writing a Custom Content Type Migration
Auto-generated migrations handle standard field types well. Custom CCK fields, computed values, or non-standard formatters need explicit YAML definitions. Here's a realistic example — a D7 Event content type with a date range field:
This is the most common scenario at agencies right now: modern Drupal running well, but built before Recipes and Canvas existed. There is no data migration here — your content stays exactly where it is. What you're adopting is a new site-building layer.
Because recipe config actions use createIfNotExists, this is safe on a live codebase — it will not overwrite your existing SEO or media configuration; it only fills in missing pieces.
This is where teams stall. If your current site uses Layout Builder or Paragraphs for page composition, official tooling to migrate into Drupal Canvas does not yet exist as of mid-2026. Your real options today:
Option C — Wait: If your site has thousands of Paragraphs-based pages, holding for official migration tooling may be the most pragmatic decision — a visible discussion at DrupalCon Rotterdam.
This is the highest-complexity path but increasingly common as organizations exit proprietary platforms for digital sovereignty and cost reasons.
This example extracts WordPress posts from a side-by-side MySQL database and loads them into Drupal CMS article nodes:
Media is where CMS migrations to Drupal quietly break — broken image paths and dead embedded media are among the most common post-launch complaints.
The problem: body content migrated as raw HTML still contains <img src="/wp-content/uploads/..."> paths referencing the old platform. Two strategies fix this:
Strategy A — Migrate files first, rewrite src attributes after
Strategy B — Use the file_import process plugin
Always run a dedicated media migration pass before your content migration, so file entities exist before nodes try to reference them.
⚠ Pitfall 1 Migration is busy with another operation: Importing
The most frequently encountered Migrate API error. It happens when a migration process is killed mid-run (Ctrl+C, server timeout, PHP fatal) and the status lock isn't cleared.
The fix:
⚠ Pitfall 2 Skipping the Content Audit Phase
A reliable migration follows six stages: audit, content mapping, environment setup, content migration, media migration, and SEO preservation. Skipping a stage tends to resurface later as a launch-day fire drill.
A full pre-migration audit must cover:
⚠ Pitfall 3 Not Planning for Delta Migrations
Initial migration runs are never the final run. Between your first migration pass and go-live, editors will keep publishing on the old platform. You need a delta migration strategy — re-running migrations to pick up records created or updated after the initial pass.
⚠ Pitfall 4 Incorrect URL Alias Handling
After migration, old URLs may lead to 404 errors if not redirected correctly. Set up 301 redirects for old URLs to preserve SEO and user experience.
The pathauto module will regenerate URL aliases on save — which is exactly what you don't want post-migration if your old URLs had a different pattern. Disable Pathauto auto-generation on migrated content by setting path/pathauto to 0 in your migration YAML (as shown in the WordPress example above).
⚠ Pitfall 5 Migrating Roles and Permissions Too Early
If you migrate users before your Drupal CMS roles and permissions are fully configured, user role assignments land in the system referencing role IDs that either don't exist or have different permission sets than intended.
The correct order:
1. Configure roles and permissions on the destination site first
2. Export config with drush cex
3. Then run upgrade_d7_user or equivalent user migration
4. Verify a sample of migrated users have the expected roles before migrating content
⚠ Pitfall 6 Not Rolling Back Cleanly Between Test Runs
During development and testing, you'll run migrations many times. Not rolling back cleanly between runs leads to duplicate content, inconsistent map tables, and cascading lookup failures.
Beyond the technical tooling, the cutover strategy matters as much as the code. Three patterns dominate real-world projects:
|
Strategy |
Best For |
Key Characteristic |
|
Big Bang |
Smaller sites (<300 pages) |
Single cutover, maintenance window required |
|
Progressive |
Large content libraries |
Reverse-proxy routing, sections migrate gradually |
|
Hybrid (API Gateway) |
Regulated industries, complex integrations |
Drupal CMS as content hub, legacy systems via API |
Realistic timelines from field experience: small projects 6–12 weeks, medium-complexity 3–6 months, large enterprise migrations 6–12 months or more. These aren't conservative padding — they reflect what competent, well-resourced teams actually take when they don't skip the audit and planning phases.
This is the step migration guides most often omit. Migrate moves your content — it does not configure Drupal CMS's site-building layer. After your data migration validates cleanly, apply the relevant recipes:
Case studies from the Digital Sovereignty track — real migration stories from organizations exiting proprietary CMSs, with full technical detail
Migration to Drupal CMS 2.x is three different problems depending on where you start:
In every case, the six pitfalls covered in this post — stuck migration locks, skipped audits, missing delta runs, broken URL aliases, wrong sequencing of users and roles, and unclean rollbacks — account for the majority of timeline blowouts. Most of them are avoidable with upfront discipline.
← Post #1: Getting Started with Drupal CMS 2.x: Site Building with Recipes
→ Post #3: AI-Powered Drupal: Integrating LLMs and Agentic Architecture
Migration paths, Canvas tooling gaps, and the future of Migrate Drupal will all be live conversations in Rotterdam, 28 September – 1 October 2026.
This is cross-posted from Mike Herchel's blog
A few weeks ago, I met up with some of the DrupalCon Orlando local planning committee at the Hyatt Regency Grand Cypress Resort to check out the venue and finalize a bunch of plans.
We toured the resort, planned events, sampled food and drinks (strictly for quality assurance, of course), floated around the pools, and spent way too much time talking about all the fun stuff we're putting together.
After seeing everything in person, I'm convinced this is going to be the best DrupalCon ever!
If you've been to previous DrupalCons, one thing you'll notice right away is that this one is going to have a different vibe. Normally we're in a downtown convention center where you can walk to bars, restaurants, coffee shops, and whatever else you stumble across.
This isn't that. The Grand Cypress sits in the middle of Orlando's resort area near Disney. If you want to leave the property, you'll probably grab an Uber or Lyft. Disney Springs is only about 10 minutes away, and the parks are just beyond that.
But honestly... I don't think most people are going to want to leave. This resort is awesome.
Instead of everyone scattering around downtown after the sessions end, I think we're going to end up hanging out together around the resort having poolside cocktails, or smores by the fire pits. And after spending the weekend there, I think that's going to make for an even better conference.
Seriously. The pool area is unlike anything we've ever had at a DrupalCon.
The pools wind around faux limestone cliffs with waterfalls pouring down into them. There's a cave that connects two sections of the pool, a grotto, a waterslide, two hot tubs, and tons of places to spread out.
Then you've got a poolside bar serving frozen drinks, beer, and food just a few steps away. I can already picture dozens of Drupal people hanging out there after sessions.
If you're coming from somewhere that's still cold in late March... congratulations. This is probably the nicest time of year to be in Florida.
Expect highs around 80°F (27°C), cool evenings, blue skies, and weather that's pretty much perfect for sitting outside all day. It's warm enough to swim without feeling like you're melting.
One of the nicest surprises is the hotel rate that we have. The Drupal Association was able to lock in an incredible rate of just $259/night, and that includes no resort fee. Considering this is one of the best times of year to visit Florida (and a resort like this!) it's an amazing deal. If you're planning to attend, book sooner rather than later:https://www.hyatt.com/events/en-US/group-booking/VISTA/G-DC27.
This might sound boring compared to waterfalls and waterslides, but trust me, it matters. One thing I loved about the venue is how compact the conference space is. No hiking across giant hotel lobbies or speed-walking half a mile to your next session. No wondering which section your talk is actually in.
Everything is clustered together, which means less walking and more time talking to people in the hallways, which is the best part of every DrupalCon anyway.
I've been trying to make this happen for years. Every DrupalCon I’d pitch the idea of a talent show, and every year something got in the way. Well... this is the year! It’s happening!
We'll be looking for pretty much anything entertaining:
We’re not taking sign-ups just yet, but keep an eye out!
Besides your laptop?
This venue is a little different than what we're used to, but after spending the weekend there, I know it's going to create a totally different kind, and super memorable, DrupalCon.
Instead of everyone disappearing into the city after the sessions end, I think people are going to stick around. Hanging out by the pool. Sitting around the fire pits. Grabbing a drink. Talking Drupal late into the night.
And honestly? I can't wait!
This is cross-posted from Mike Herchel's blog
A few weeks ago, I met up with some of the DrupalCon Orlando local planning committee at the Hyatt Regency Grand Cypress Resort to check out the venue and finalize a bunch of plans.
We toured the resort, planned events, sampled food and drinks (strictly for quality assurance, of course), floated around the pools, and spent way too much time talking about all the fun stuff we're putting together.
After seeing everything in person, I'm convinced this is going to be the best DrupalCon ever!
If you've been to previous DrupalCons, one thing you'll notice right away is that this one is going to have a different vibe. Normally we're in a downtown convention center where you can walk to bars, restaurants, coffee shops, and whatever else you stumble across.
This isn't that. The Grand Cypress sits in the middle of Orlando's resort area near Disney. If you want to leave the property, you'll probably grab an Uber or Lyft. Disney Springs is only about 10 minutes away, and the parks are just beyond that.
But honestly... I don't think most people are going to want to leave. This resort is awesome.
Instead of everyone scattering around downtown after the sessions end, I think we're going to end up hanging out together around the resort having poolside cocktails, or smores by the fire pits. And after spending the weekend there, I think that's going to make for an even better conference.
Seriously. The pool area is unlike anything we've ever had at a DrupalCon.
The pools wind around faux limestone cliffs with waterfalls pouring down into them. There's a cave that connects two sections of the pool, a grotto, a waterslide, two hot tubs, and tons of places to spread out.
Then you've got a poolside bar serving frozen drinks, beer, and food just a few steps away. I can already picture dozens of Drupal people hanging out there after sessions.
If you're coming from somewhere that's still cold in late March... congratulations. This is probably the nicest time of year to be in Florida.
Expect highs around 80°F (27°C), cool evenings, blue skies, and weather that's pretty much perfect for sitting outside all day. It's warm enough to swim without feeling like you're melting.
One of the nicest surprises is the hotel rate that we have. The Drupal Association was able to lock in an incredible rate of just $259/night, and that includes no resort fee. Considering this is one of the best times of year to visit Florida (and a resort like this!) it's an amazing deal. If you're planning to attend, book sooner rather than later:https://www.hyatt.com/events/en-US/group-booking/VISTA/G-DC27.
This might sound boring compared to waterfalls and waterslides, but trust me, it matters. One thing I loved about the venue is how compact the conference space is. No hiking across giant hotel lobbies or speed-walking half a mile to your next session. No wondering which section your talk is actually in.
Everything is clustered together, which means less walking and more time talking to people in the hallways, which is the best part of every DrupalCon anyway.
I've been trying to make this happen for years. Every DrupalCon I’d pitch the idea of a talent show, and every year something got in the way. Well... this is the year! It’s happening!
We'll be looking for pretty much anything entertaining:
We’re not taking sign-ups just yet, but keep an eye out!
Besides your laptop?
This venue is a little different than what we're used to, but after spending the weekend there, I know it's going to create a totally different kind, and super memorable, DrupalCon.
Instead of everyone disappearing into the city after the sessions end, I think people are going to stick around. Hanging out by the pool. Sitting around the fire pits. Grabbing a drink. Talking Drupal late into the night.
And honestly? I can't wait!
This is a guest post from the team at Zoocha, a Gold Drupal Certified Partner with offices in the United Kingdom, Spain, Brazil, and the United States.
As Drupal agencies, we're fortunate to benefit from a vibrant ecosystem that generates awareness, interest, and opportunities for all of us. At Zoocha we receive inbound enquiries from a variety of sources. Whether they arrive via Drupal AI, Drupal CMS, a community recommendation, a Drupal event, or direct through our site, every enquiry often represents something important: a person taking their first step towards our community.
Not every lead is a project.
Not every lead has a budget.
Not every lead is ready to buy.
But they always deserve a meaningful response.
When someone reaches out to a Drupal agency, they're rarely just evaluating that agency, they’re more often than not seeking to engage with Drupal itself. For many prospective clients, they may not know the difference between Drupal, the Drupal Association, Drupal CMS, an implementation partner, a hosting provider, or the wider open source community. They simply know they've heard about Drupal and are looking for guidance.
The response they receive helps shape their perception of the entire ecosystem. If their first interaction feels dismissive, transactional, or overly focused on qualification, they may walk away believing that's what the Drupal community is like. If their first interaction is friendly and genuine, they leave with a very different impression.
Most agencies have some form of qualification process. It's sensible, and so do we. Time is valuable, and we know not every conversation will become a project.
However, there is a difference between understanding someone's needs and interrogating them. We've all seen responses that immediately ask:
While those questions have their place, they are rarely the most important thing during an initial conversation. Many prospects simply don't know the answers yet.
Some are conducting research. Some are exploring options. Some are trying to understand whether Drupal is even the right fit. At this stage, what they often need most is guidance.
One of the most effective approaches we've found at Zoocha is to assume that the first conversation may never lead to a sale. That does sound counterintuitive for a commercial organisation, but it changes the nature of the interaction. Instead of trying to move the conversation towards a proposal as quickly as possible, we focus on being useful. That might mean:
Sometimes that conversation ends there, and that's ok. The contact doesn't leave empty handed. They leave with a positive impression of who we are in the Drupal community.
Interestingly, some of our most successful client relationships started with conversations that had no immediate commercial outcome. We've had early exchanges that were little more than an idea, with individuals facing a specific challenge and just looking to find out if they're even in the right place with Drupal. After a person-first conversation, they disappeared. But a few months, or even a year, later, they came back, and what began as a casual enquiry became a long-term client partnership.
This didn't happen because we had the best sales team or process. It happened because we prioritised human connection over a fast sale.
Drupal has always been built around principles of collaboration, openness, and knowledge sharing, these values really shouldn't stop at code contributions. They can also shape how we engage with prospective users of the platform. When we answer questions generously, share expertise freely, and help organisations make informed decisions, we're strengthening confidence in Drupal itself.
Even if a particular opportunity never becomes a client engagement, the person on the other end of that conversation is left with a positive impression of the community. That's good for all of us!
The next time a speculative Drupal enquiry lands in your inbox, try viewing it differently. Consider simply asking, "How can we actually help this person?" The answer might only require a short email, a useful link, or a brief conversation, and yes, the immediate commercial return is likely to be zero. But the long-term return, for your agency and for the Drupal ecosystem, can be significant.
Every first interaction is an opportunity to demonstrate what makes the Drupal community different. Let's make sure it's a positive one.
This post is adapted from the DA Insider, the Drupal Association's monthly newsletter. Subscribe here to get it in your inbox each month.
Dear Drupal community,
Open source hums along on the work that just gets done. As I step into the interim CEO seat, I'm making a point to notice the sheer volume of work powering this ecosystem, from the DA and beyond. Here's some of what has come together in the past month:
My goal as interim CEO is straightforward: make sure the Association's foundation is resilient enough to support all this energy. The first step is helping all of us notice and appreciate the work that already "just happens."
I hope you enjoy this month's newsletter and everything everyone's been building. And one final note: board elections are open. Please vote.
Tiffany Farriss Interim CEO
If you're a Ripple Maker, your ballot arrived by email from Helios Voting on 22 July. Voting closes 14 August 2026 at 23:59 UTC, so there's still time to get to know the candidates: read their profiles and leave questions on the election details page, catch the Open Community Forum recording on our YouTube channel, or revisit the async conversation in #drupal-association on Drupal Slack. Every vote counts — make yours matter.
DrupalCon Rotterdam 2026 is ready. Join the global Drupal community for four days of learning, collaboration, and connection — explore the program, meet the speakers, and start planning your experience. Secure your ticket now.
The DrupalCon Orlando 2027 Call for Speakers opened 4 August and closes 20 October 2026, with some notable changes this year:
A more focused program with fewer concurrent sessions and an emphasis on high-quality, impactful content. Updated session tracks reflecting the evolving Drupal ecosystem. And a new pathway for first-time speakers: if you've never spoken at a DrupalCon, DrupalCamp, or other Drupal event, you can submit to the new Poster Session — selected presenters showcase their work at the Monday Welcome Reception and present a 10-minute session on the Lightning Stage.
And keep an eye out for Bytes the Gator, the DrupalCon Orlando mascot, who'll be visiting Drupal events around the world between now and March 2027 — with a chance to win a free registration to DrupalCon Orlando 2027 along the way.
Nominations are open for the Women in Drupal Award, sponsored by Jakala, recognising women whose work strengthens the Drupal community — in the projects they build, the teams they support, the ideas they bring forward, and the space they create for others to grow. Know someone whose contribution deserves recognition? Submit a nomination.
When highly critical vulnerabilities emerge — like SA-CORE-2026-004, a SQL injection in Drupal core that anonymous users can trigger — every minute matters. Drupal Steward is a security service from the Drupal Association that gives you extra time to respond before vulnerabilities can be widely exploited: early notification of highly critical issues, recommended WAF mitigation rules, and access to security expertise, in coordinated collaboration with the Drupal Security Team. It's available in a Community Tier for smaller site portfolios, plus Small, Mid-Size & Enterprise tiers for organisations that want full control. Referral incentives are available for Drupal Certified Partners.
The migration of projects to GitLab issues continues — including security issues and hundreds of Ripple Maker projects — with GitLab soon to be enabled by default for all new projects, alongside updated contribution docs and a new custom commands reference. The team has also kicked off a collaboration with Alpha-Omega through their Security Engineer in Residence program to triage and respond to the growing wave of AI-generated security reports. And an RFP is under way for the Drupal Site Template Marketplace, focused on closing the last mile from template selection to live hosted site.
We're building a dedicated product marketing site for Drupal — a purpose-built, marketing-led site designed to reach the people who haven't heard of Drupal yet: marketers, IT directors, and enterprise decision-makers evaluating CMS platforms.
High-priority tasks are being added to the promote_drupal project on GitLab — real, scoped pieces of design, content, video, and strategy work with significant contribution credits attached, with more added on a rolling basis. If something catches your eye, reach out to Ryan Witcombe at ryan.witcombe@association.drupal.org or @RyanWitcombe on Drupal Slack.
On 15 July, the Drupal Burkina Faso Association, led by its president Seferiba Salif Soulama, met with Burkina Faso's Minister of Digital Transition, Dr. Aminata Zerbo/Sabane, to explore how Drupal can support the country's digital future. The meeting marks a significant step toward a formal partnership between the Ministry and the Drupal Burkina Faso Association, with Drupal at the heart of Burkina Faso's digital modernisation agenda.
This is what open source looks like in action: communities, governments, and technology coming together to build something that belongs to everyone. Read the full story.
The Drupal AI Initiative team has launched The AI Byte, a monthly LinkedIn newsletter curating the best content across the web about Drupal AI — new capabilities, case studies, events, and webinars. Subscribe on LinkedIn.
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.
AI was used to help adapt this newsletter into a blog post. It was reviewed and edited by Drupal Association staff before publishing.
When I took on the role of Interim CEO, I committed to being direct about our finances and noted that our earlier audits already told much of the story. The board has now released our 2025 audit report, which was provided to the Board of Directors of the Drupal Association on 8 July 2026 and approved on 25 July 2026. It provides additional context and detail, but does not change the overall picture or our path forward.
To be clear, nothing in this audit means any of the services the project depends on are at risk. What this audit does is help us to understand the status quo so that we can take appropriate action moving forward.
The DA spent about $451,000 more on operations than we brought in last year (2025), and that followed a larger shortfall the year before ($923,000).
Those two years are not cleanly comparable, because the 2025 audit also restates our previously audited 2024 results. Our auditors determined that about $353,000 of membership revenue had been recognized in 2024 that should instead have been allocated to 2025, when it was actually earned. This was a non-cash correction to our books: no money changed hands, and nothing was lost or misspent.
Together, 2024 and 2025 produced a combined shortfall of about $1.15M, which averages roughly $573,000 a year. Our current forecast puts 2026 on the same path.
Our cash reserves (the unrestricted funds we can actually spend on operations) have decreased by about 60% since the end of 2022, to roughly $960,000, which represents 2.3 months of operating expenses. Board policy sets a six-month target and a three-month reserve minimum. 2025 is the first year since 2019 that the DA has failed to meet the minimum. The DA remains a going concern and is not in danger of becoming insolvent, but it is time for action.
Coming out of 2022 with strong reserves, the board approved a three-year strategic plan on 6 June 2023 and chose to put some of its surplus toward ambitious, community-requested investments in marketing and project support. Funding strategic growth is how excess reserves are best leveraged.
These investments have had a measurable impact:
Contributions to Drupal strategic product innovation tripled, reaching 211,037 organizational credits in 2025, a 54% increase over 2024.
We reached 106 Drupal Certified Partners under enhanced "maker" requirements, roughly double the 2022 figure.
43 people were brought into Drupal leadership roles for the first time, against a goal of 38.
We adopted and executed a go-to-market plan for the launch of Drupal CMS, and built marketing capacity inside the DA for the first time.
However, the sustainability of these efforts long-term was tied to a goal which we did not meet:
Increase Drupal Association total revenues by 3X, from $3.49M in 2022 to $10.5M in 2026 to better support mission-driven activities.
Our reported revenue did grow about 25% between 2022 and 2025. While 2025 is one of our largest revenue years on record, this figure is misleading, because most of the growth is in non-monetary services provided in trade (described in more detail below). Putting that aside, the Association’s cash revenue grew 5% over three years while out-of-pocket costs grew 27%.
The gap is paid for out of our reserves. Reserves are the right instrument for starting something and the wrong instrument for running it. Funding our strategic initiatives from reserves was the right decision for the duration of the strategic plan, but while that plan ended last year, the work has continued without a viable funding plan.
Marketing and project support are precisely the kind of mission-aligned work the DA should be doing. So the task in front of us is to fund it properly: each program examined discretely, with its own revenue plan, and held to revenue neutrality now that it has moved out of pilot and into operations.
In 2022 we spent $1.3M running Drupal.org (the Web site, composer endpoints, GitLab, CI, authentication, and the global CDN), and in 2025 we spent $2.1M. That is up 61% in three years. It is the Drupal Association's single largest cost, and it has no direct funding mechanism. Every organization that uses Drupal relies on this infrastructure, but none of them are asked to pay for it, because we have never built a way for them to.
For most of Drupal's history that did not matter, because the surplus revenue from DrupalCon covered the costs of Drupal.org. However, since 2022 the DrupalCon surplus has fallen from about $994,000 to about $227,000. While event costs have continued to increase since we resumed in-person events, event revenue has gone down.
This means that we are increasingly relying on the generosity of a handful of vendors and partners who provide services for free or in trade for sponsorship placements. That generosity has grown from $249,249 in 2022 to $1,011,995 in 2025 and now covers nearly half of what we spend on Drupal.org. These services in trade and donated services have not reported in our monthly reports because they were “non-cash”; they appeared only at audit.
|
Share of what we spend on Drupal.org |
2022 |
2025 |
|
Covered by DrupalCon surplus |
76% |
11%↓ |
|
Covered by services in trade, gratis |
19% |
48%↑ |
|
Covered by general operating revenue |
4% |
41%↑ |
The remainder of the infrastructure spending gap must be paid for out of general operating revenue, and failing that, out of reserves. These costs increased from $56,825 in 2022 to $859,384 in 2025.
It is also important to note that these numbers do not account for work that is deferred because the funding is not there to pay for it. This technical debt does not appear on any of our financial statements, but is a growing liability that will need to be paid for at some point.
The bottom line is that while our cash spending on infrastructure has remained steady, we have a rising essential cost that currently has no funding model attached to it yet.
The fiscal year 2024 closed 31 December 2024. The initial audit for 2024 was released in July 2025 showing $570,000 of deficit. Then in July 2026, it was restated downward to a $923,000 deficit as part of the 2025 audit.
While the Drupal Association CEO is accountable for the organization’s day-to-day operations, the board provides oversight over the organization’s budget and finances. This oversight requires timely, accurate, and consistent financial reporting.
The monthly reports that the board’s Finance Committee reviewed and the audited statements published 6 months after the year close were prepared on different bases, with nothing reconciling the two. The Finance Committee struggled to get consistent answers or clarity about what individual figures included. In April 2026, Finance Committee asked our auditors to examine the reporting revenue recognition practices directly. That request is what produced the restatement of 2024 as part of the 2025 audit. This also explains how long it took to know where we stood in 2024.
The responsible approach is to act now, while we can still make changes on our own terms rather than in a crisis. Some of this is already underway and the rest has dates attached to it.
As Interim CEO, I am operationally accountable to make sure that the board has access to an annual budget that is actively managed with variances mitigated; receives consistent, contextualized and timely financial reports; and that robust internal controls and workflows are in place. This clarity will give the Finance Committee and the board what they need to exercise proper oversight within the policy guardrails they have set.
Our internal reporting will be reconciled to audit-basis accounting, so that the figures the board governs against during the year are as close as possible to the ones we publish after it; non-cash arrangements will be recorded as they occur rather than at year end; and our reserve position will be reported on a single defined basis, against both policy thresholds, every period.
Drupal.org will be presented as a program with a cost that the Drupal Association is accountable for funding. The Association needs a durable way to fund Drupal.org rather than the patchwork indirect one we have now. These issues are not unique to Drupal, and I am looking forward to hearing others' thoughts, but be assured that I do not intend to solve a funding problem by reducing the services the community relies on.
Within the coming months, I will publish:
What each part of our work actually costs and how it is funded
The full costs of Drupal.org as a measurable figure, which will be the first time anyone, including the board, will have seen that number
An updated 2026 forecast and preliminary mitigation plan
This fall, I will prepare a two-year 2027-2028 Operating Budget with the Finance Committee that the board will be able to review and approve before the end of the year.
Nothing about the 2025 audit changes our commitment, our mission or the direction we need to go. It just adds a little urgency. I am focused on co-creating a financial model where the work sustaining Drupal rests on a foundation that is resilient and sustainable for the next long-term CEO.
Author: Will Huggins
In our previous blog posts, we’ve talked about how our growing ecosystem — now backed by 32 global partner organisations and a dedicated delivery team — is structured to build a secure, stable, and highly integrable AI-native digital experience platform.
So what does this mean for your day-to-day digital communications and marketing operations? How do you translate this into improved experiences for your audience, higher conversion rates, and reduced cost?
To win in the age of AI, digital leaders don’t just need faster ways to generate content or build great digital experiences. They need a platform that helps them move at maximum speed, while still maintaining the highest quality and content standards.
Here is an inside look at the key features on the Drupal AI 2026 roadmap, focused on the outcomes that matter most to digital communications and marketing teams: speed, brand safety, and measurable ROI.
Many AI-powered page builders on the market suffer from what digital leaders call "AI Slop": random, messy, raw HTML blocks based on generic AI models. These pages can break your site's layout, look wildly off-brand, fail accessibility standards, and create the dreaded ‘technical debt’ for your developers to clean up.
Drupal AI’s upcoming Canvas AI Page Builder operates under a completely different paradigm. It is natively component-aware.
A major anxiety for marketing teams is brand dilution. If your team is using disconnected AI tools, your brand voice can quickly fragment, sounding professional on one page and generic on another.
Drupal AI solves this by embedding a centralised Context Control Centre directly into the CMS. This serves as the single source of truth for your brand's identity and governance rules.
You can scale your global content footprint across multiple regions and channels, confident that every single piece of copy, everywhere, sounds exactly like you.
Today, your content lives in the CMS, but your performance data is trapped inside a web analytics dashboard (like Google Analytics or Matomo), and the two systems rarely talk to each other. As a result, marketing teams often miss trends, fail to optimise low-performing pages, and struggle to scale what actually works.
Drupal AI is built to close this loop by bringing performance intelligence directly into the content creation interface.
No more digging through dashboards to find what's not working. Your website becomes a living, self-optimising engine, learning what works best for your audience and handing ready-to-publish optimisations directly to your content editors, bridging the gap between data and action.
Speed is meaningless if your IT department or compliance team vetoes your tools due to security risks. To build an AI platform organisations can trust, Drupal AI treats security and governance as structural priorities, not afterthought add-ons.
Unlike lightweight SaaS tools that operate outside of your corporate governance, Drupal AI operates entirely within your existing approval workflows and editorial permissions.
This means you get the agility of generative AI backed by enterprise-grade, auditable, secure workflows: the kind of governance IT teams look for.
The future of digital experience is being built on open-source, model-agnostic foundations. By giving your marketing team visual page building, centralised brand context, and performance-driven optimisation within an enterprise-grade secure environment, Drupal AI is paving the way for digital teams to operate at maximum velocity with zero brand risk.
The future of open-source digital experience is being built right now. If your digital product or content marketing teams are ready to experience what is possible today, explore our progress and try the live demo.
Author: Will Huggins
In 2025, the Drupal AI Initiative launched with a clear vision: to establish Drupal as the premier open-source AI platform for digital experiences.
One year later, the market momentum is clear. What began as a highly focused working group has grown into a powerful ecosystem supported by 32 global partner organisations, over 50 active contributors, and over $2.3 million in committed funding. Most importantly, with the core AI technology now clocking up over 18,000 installs, organisations are actively building their next-generation marketing engines on Drupal.
For digital teams, AI presents a host of opportunities. The power to increase speed of production on one hand, while maintaining quality, consistency and governance on the other. Drupal is addressing this head-on by creating two dedicated product workstreams: Inside AI and Outside AI.
This blog post outlines what this means for your digital roadmap and how Drupal can help your digital marketing operations win in the age of AI.
As AI has evolved from chat boxes into autonomous, multi-step agents, digital leaders need a platform that does two things simultaneously: empowers human creators inside the browser and securely integrates with external marketing systems.
To accelerate our product roadmap, we have divided our day-to-day development into two specialised, business-focused tracks:
Through this dual focus, we aim to make Drupal the most advanced, intuitive workspace for your marketing teams and content creators, as well as the most secure and connectable platform to build on.
As you plan your digital product roadmaps and marketing strategies, here is a summary of exactly what is production-ready, what is ready for pilot testing, and what is on the horizon:
These capabilities are fully stable, secure, and ready to drive immediate ROI in your production environments:
These features are highly advanced and close to general availability. They are perfect for controlled pilot programs to gain a competitive edge:
One of the cutting-edge, experimental capabilities currently being refined in sandbox environments is Fully Autonomous Agents. These background agents are designed to analyse website performance, automatically propose layout optimisations to boost conversions, or build complex database queries entirely on their own.
As a mature open-source platform, Drupal AI is structurally sovereign, model-agnostic, and transparently governed.
Whether you need to host open-source models locally to comply with strict regional privacy regulations or plug into the latest commercial LLMs for maximum speed, Drupal AI ensures you always own your data, your models, and your digital roadmap. We build trust directly into the architecture through branch-based content versioning, strict governance workflows, and deep audit trails.
The Drupal AI Initiative is driving the future of open-source digital experience. If your marketing or digital product teams are ready to leverage the power of collaborative AI, try Drupal today.
This is a guest post from the incredible team at 1xINTERNET, a Top-Tier Drupal contributor and digital agency headquartered in Frankfurt, Germany.
When the Drupal Association announced that 1xINTERNET had become one of the world's Top-Tier Drupal Contributors, it was a proud moment for the company. Reaching the highest level of contribution recognition places 1xINTERNET among a select group of organisations helping shape the future of one of the world's leading open-source content management systems.
Yet, ask anyone inside the company about the achievement, and you'll hear the same response: becoming a Top-Tier Contributor was never the ultimate goal. Instead, it is the natural outcome of more than a decade of believing that if you build your business on open source, you should help build open source itself.
For over thirteen years, 1xINTERNET has invested in the Drupal ecosystem, not only by delivering digital platforms for clients, but by contributing code, maintaining projects, sponsoring community events, supporting governance, leading strategic initiatives and encouraging employees to actively participate in the community.
Today, the company sponsors more than 500 hours of Drupal contribution every month, actively supports more than 85 Drupal projects, has sponsored over 50 Drupal events, and has contributed to hundreds of issues across the Drupal ecosystem. Those numbers tell one story. The people behind them tell another.
Contribution isn't only about strengthening Drupal, it creates real value for the organisations that choose Drupal as the foundation for their digital platforms. We spoke with Baddý Breidert, Christoph Breidert and James Tillotson about why contributing matters, how it benefits clients, and why they believe giving back is essential to building better digital experiences.
James Tillotson, Christoph Breidert, and Baddý Breidert (Composite visual created with generative AI tools)
For 1xINTERNET CEO Baddý Breidert, contributing to Drupal has always been part of the company's identity.
"It represents over a decade of dedication to the Drupal project," she says. "I've worked with Drupal since 2006 and been actively involved in the community since 2013. Being recognised as one of the top three Drupal companies globally validates the expertise and sustained effort our team has invested over the years."
But the motivation goes much deeper than recognition. Instead of simply following the direction of Drupal, 1xINTERNET believes in helping shape it. Since Drupal is the technological foundation behind many of the company's digital platforms, contributing to its future isn't viewed as optional, it's viewed as a responsibility.
That philosophy influences almost every decision the company makes. Rather than waiting for new features, improvements or innovations to arrive, the team actively participates in creating them.
Managing Director Christoph Breidert describes it simply.
"We don't just build with Drupal; we help influence where the platform is going next."
It's an approach that benefits not only the Drupal community, but every organisation that chooses Drupal as the foundation for its digital future.
Although contribution often means writing code, the three leaders agree that it's ultimately about something much bigger.
Open source succeeds because thousands of people collaborate, share knowledge and solve problems together. Every contribution, whether it's code, documentation, testing, mentoring, event organisation or strategic leadership, helps strengthen the ecosystem for everyone.
For Christoph, this spirit of reciprocity sits at the heart of open source.
"If you build digital solutions using an open-source project but choose to remain on the sidelines, you miss the opportunity to influence the tools you rely on," he explains. "Open source is built on shared knowledge, and contributing back is simply part of how we work."
That collaborative mindset is equally visible throughout 1xINTERNET's culture. 1xINTERNET’s UK Growth Manager James Tillotson sees open source as an extension of how the company works internally.
"We don't hoard knowledge," he says. "We share it to raise the baseline for everyone, which in turn allows us to keep innovating."
Rather than viewing contribution as something separate from day-to-day work, it's embedded in the way teams learn, collaborate and continuously improve.
One of the biggest misconceptions surrounding open source is that contribution somehow competes with client work. The reality, according to the team, is exactly the opposite.
James puts it bluntly: ""Contribution is client work."
When developers fix a bug in Drupal core or improve functionality that thousands of websites rely on, every client benefits, not just today, but for years to come.
Christoph agrees: "If you're not involved in building the technology, you're always reacting instead of leading."
Technology evolves quickly. Artificial intelligence, digital experience platforms, accessibility, security and content management continue to change at an unprecedented pace. Agencies that simply consume technology are forced to wait for innovation. Agencies that contribute help create it.
Baddý believes that's one of the company's greatest strengths.
"Contribution allows us to lead initiatives like Drupal AI, ensuring we aren't just consumers of the technology but creators of it."
Instead of adapting after the market changes, 1xINTERNET helps shape those changes from within.
Perhaps nowhere is that philosophy more visible than in Drupal AI. As Product Lead for Drupal AI, Christoph has been deeply involved in defining its roadmap, working alongside developers from around the world to build practical AI capabilities directly into Drupal.
For him, watching Drupal AI evolve from an ambitious idea into one of the platform's most exciting capabilities has been one of the defining milestones of the company's contribution journey.
"It's been incredible to collaborate with a global community to build something that will help shape the future of the web."
The significance goes beyond technical innovation. Because 1xINTERNET helps build Drupal AI, its teams understand the technology long before it becomes mainstream. They know what's coming, how it works and how organisations can use it responsibly.
James, who contributes to the Drupal AI Marketing Initiative, believes this creates a significant advantage for clients.
"Our clients have access to the latest innovations because we're involved in creating them."
Innovation isn't something clients wait for. It's something they experience alongside the people helping build it.
Although many clients may never see the code being contributed to Drupal, they experience its impact every day. Active contributors develop a much deeper understanding of the platform than those who simply implement it. Because the team understands Drupal's architecture, roadmap and future direction, they can make better long-term decisions for every project.
"Our clients receive stable and modern solutions without having to manage the underlying complexity," Christoph explains. "By maintaining our contribution status, we act as a direct pathway to web innovation."
That means fewer surprises, more sustainable architectures and platforms designed to evolve instead of becoming outdated. James believes clients increasingly recognise that value.
"They know we're not simply using Drupal, we're helping steer where it's going."
Contribution also creates something that's difficult to measure but incredibly valuable: trust.
When organisations invest in large scale digital platforms, they aren't simply buying technology. They're choosing partners who will help them navigate years of future development.
Being recognised as one of the world's leading Drupal contributors provides confidence that 1xINTERNET isn't standing on the outside of the ecosystem, it's helping lead it. Baddý has seen this become increasingly important during procurement processes.
More organisations now actively look for suppliers who contribute back to the technologies they depend on. Public sector organisations and enterprise businesses increasingly view contribution as evidence of technical excellence, long-term commitment and sustainability.
James has experienced this while expanding 1xINTERNET's presence in the United Kingdom. "When entering a new market where people don't yet know your brand, your contribution footprint becomes a global passport. The Drupal community already knows who you are."
That credibility opens doors long before a first meeting takes place.
For Christoph, contribution is also connected to a much broader movement taking place across Europe and beyond. As organisations become increasingly concerned about vendor lock-in, proprietary platforms and ownership of their data, open-source software is becoming strategically more important than ever. By contributing to Drupal, companies don't simply improve software, they strengthen an independent digital ecosystem that organisations can trust.
"Businesses increasingly want digital sovereignty," Christoph says. "By actively contributing to Drupal, we're helping build a secure and independent IT landscape that organisations can rely on."
It's a perspective that positions contribution not only as technical work, but as an investment in the future of open digital infrastructure.
Contribution doesn't only benefit clients. It also shapes the people who choose to work at 1xINTERNET. The company actively encourages employees to contribute code, maintain projects, organise events, mentor others and share knowledge across the community. For many developers, that's exactly the environment they're looking for.
"Top developers want to work on things that matter," James says. "We offer them a stage, not just a desk."
Christoph agrees. Many developers are motivated by solving meaningful problems that have an impact far beyond a single client project.
For Baddý, contribution creates something equally valuable: a culture of continuous learning. By collaborating with some of the best Drupal developers in the world, the entire team continually raises its own standards, creating an environment where innovation and professional growth go hand in hand.
Becoming a Top-Tier Drupal Contributor isn't viewed as a finish line. Instead, it's another milestone in a much longer journey. The company plans to continue investing heavily in Drupal AI, supporting the wider community, encouraging employees to contribute and helping organisations embrace open-source innovation with confidence.
Christoph hopes to make Drupal AI even more accessible through practical demonstration environments that allow organisations to experience its capabilities with a single click.
James wants to strengthen the connection between enterprise organisations and the open-source community, demonstrating that open source can successfully support even the most ambitious digital transformation projects.
Baddý remains focused on investing in people, community leadership and the long-term health of the Drupal ecosystem.
Ultimately, becoming a Top-Tier Drupal Contributor isn't really about rankings, badges or recognition. Those are simply the visible results of years of consistent investment.
The real achievement is building a company where contribution is part of everyday work, where sharing knowledge is expected, collaboration is celebrated, and innovation is something created together rather than consumed.
For 1xINTERNET, contributing to Drupal has never been about giving something away. It's about helping build a stronger platform, a stronger community and better digital experiences for everyone who depends on Drupal.
Because when the platform grows stronger, so do the organisations, developers and communities that build upon it.
Drupal's volunteer Security Team has protected millions of sites for more than 20 years and its process is world-class. Bandwidth among the security engineers has always been the limiting constraint. This spring that constraint met a new kind of pressure: AI-assisted analysis is finding latent vulnerabilities at an accelerating pace.
The Drupal AI Security Initiative adds funded security capacity in response. It is funded through Alpha-Omega's Security-Engineer-in-Residence (SEIR) program, coordinated by the Drupal Association, and works alongside the volunteer Security Team, which continues its normal process throughout.
This post introduces the initiative and reports on our first six weeks. The short version: the funded fractional team model is working and has already evolved our understanding of where we want to focus next.
Drupal's attack surface is what it has always been. What has changed is the cost of finding bugs. AI-assisted analysis makes discovery dramatically cheaper. AI can produce security issue reports at a volume and can discover exploit details at a speed that any volunteer effort struggles to absorb. Our advisory data shows the rate of discovery accelerating (our next post will work through what the data suggests in detail).
The initiative builds on the lessons of the Drupal 8 Accelerate Initiative, which showed that throughput efficiency depends on funding the whole contribution workflow, not just one part of it.
The Drupal security team needs fixes, not just findings of potential issues. As fixes are developed, they are collaboratively reviewed. An engineer cannot mark their own fix complete. Funding one full-time engineer would likely produce findings faster than volunteers could review them, and they would queue. So we’re using the grant to fund a fractional team that covers the full path from discovery to merge on both the project and infrastructure side for Drupal:
Drew Webber (@mcdruid) is the Fixer. He applies AI-security expertise directly to Drupal's code: scanning, writing patches, building experimental tooling, and then submitting contribution-ready work across Drupal core and the contributed-project ecosystem.
Greg Knaddison (@greggles) and Michael Hess (@mlhess) are Reviewers: They triage submissions, review patches, advance issues, and provide the RTBC status a fixer cannot grant themselves. Both come from the existing Security Team, and the grant helps subsidize the work they would otherwise do on volunteer time.
Neil Drumm (@drumm) handles infrastructure, focusing on Drupal.org itself. The package distribution, build pipelines, and update mechanisms are a high-consequence, specialized surface on their own.
Tiffany Farriss (@farriss) and Tim Lehnen (@hestenet) provide program support and coordination for the Drupal Association.
Our current grant has two three-month phases: Clarity (understand the problem) and Attention (fix issues and harden the process).
We're using the funding and AI tooling to find, validate, triage, and resolve vulnerabilities faster than before, including proactively, across core, contrib, and our own infrastructure. In six weeks, the team has made contributions to more than 10 published advisories and CVEs and filed more than 30 issues. This work includes SA-CORE-2026-005, a critical PHP object-injection issue reachable via JSON:API that arrived as an external report and was coordinated to a fast release, alongside triage and remediation across dozens of findings and hundreds of inbound requests. The team also worked on rapid response/urgent issues off-hours; in one case, AI-assisted review helped find and fix a significant issue in Drupal.org code.
We're also building reusable tooling and automation prototypes that increase throughput and make our security archive searchable and actionable. That includes five skills and a set of opengrep static-analysis rules, each targeting a vulnerability class, and local, open-weight tooling that processes about 40,000 historical security-mailbox emails to assign metadata like CWE mapping and flag duplicates (keeping sensitive data local). One key project outcome will be delivery of working tools the Security Team can continue to use after the initiative ends.
Drupal’s grant is one of several parallel Alpha-Omega grants across open source ecosystems. Being part of this cohort has allowed us to compare notes and share tooling, successes and failures with other open source projects. So far we’ve collaborated most directly with Volker Dusch, who leads the equivalent effort at the PHP Foundation, and with colleagues at the Open Source Technology Improvement Fund (OSTIF), who shared their report-validator protocol for separating real findings from noise. That protocol feeds straight into our intake, and into the report standard we want to co-create next.
The counts are perhaps not the most interesting part. We've resolved more security issues (10) than the minimum number (8) our proposal had committed to over the entire six-month project. We had assumed the meat of the task would be finding and fixing vulnerabilities. It turns out that the more interesting challenge will be adapting Drupal's security process to the volume and nature of higher-quality-than-expected AI-generated and AI-assisted reports.
So far that adaptation has happened downstream, after an issue has been reported. Shepherding issues to a fix, filing CVEs, automating that filing, and automating the analysis of published advisories are important and help scale the response process. But it is all at the bottom of the funnel. The opportunity we would like to explore is higher up, at intake, where issues arrive.
We've started exploring what that might look like. In discussions with core maintainers, some design principles emerged: AI stays limited to a single triage activity per issue and no bot noise on every commit and merge request. Ideally, early intake tooling would pre-filter inbound security issue reports and run a gated check that confirms whether they include enough context and reproduction detail before they reach a human.
The next six weeks will build on what is working and push the intake question in two directions. The first is triage. The volume of incoming security issues is expected to keep growing and AI-assisted triage of that queue is an area to explore. We are interested in looking at how modern tooling can sort and deduplicate incoming issues so human attention can be focused where it's actually needed.
The second is the report itself. A clear issue report helps the Security Team and maintainer community move faster; a vague or bloated one slows everyone down. We want to explore and define what a useful AI-generated or AI-assisted security report should contain and draft a working standard, co-created with the Security Team and maintainers. If you are a maintainer or security reporter and have examples of good (or bad) AI-generated reports, please share them in Drupal Slack #security-discussion.
Six weeks of supplemental funding has already made a couple things clear. The roles the Drupal ecosystem depends on (security work as well as release management) need a durable, community-owned funding model, not one-time support. And we need to keep talking and collaborating across ecosystems like this.
Huge thank you to Alpha-Omega for the support, funding and for access to AI tooling from Anthropic that enabled several of the findings above; to the Linux Foundation; and to the Drupal Association for coordination. And of course, none of this works without the two decades of effort from Drupal’s amazing Security Team.
