Bridging the gap between custom modules and strictly typed components
Single Directory Components completely changed how we handle the frontend. But if you spend most of your time engineering the backend, SDC can feel incredibly frustrating.
You build a massive render array, pass it to the template, and the strict schema rejects it instantly. The days of dumping raw entity objects into Twig are over.
When you work with SDC, the component dictates exactly what data it accepts. This guide details the cleanest way to format your data and bridge the gap between custom backend logic and strict frontend schemas.
If your backend architecture does not format data perfectly, the system throws a fatal error. Follow these steps to ensure your data matches the strict schema requirements.
Every component needs a YAML file. This is the contract your backend must follow. Keep your properties simple and predictable.
name: Article Card
description: A strict component for displaying article summaries.
props:
type: object
required:
- title
- url
properties:
title:
type: string
title: Article Title
url:
type: string
title: Target Link
summary:
type: string
title: Teaser TextBackend engineers usually try to pass the entire node object. Do not do that. Extract the exact strings your schema demands. Set the render array type to component so Drupal knows how to route it.
$build['article_card'] = [
'#type' => 'component',
'#component' => 'my_theme:article_card',
'#props' => [
'title' => $node->getTitle(),
'url' => $node->toUrl()->toString(),
'summary' => $node->get('field_summary')->value,
],
];Your Twig file is now incredibly clean. It only prints exactly what the backend provided. No complex logic. No processing overhead.
<div class="article-card">
<h2><a href="{{ url }}">{{ title }}</a></h2>
<p>{{ summary }}</p>
</div>Notice how we completely avoid preprocess functions here. The template simply accepts the data contract and renders the output.
#props mapping clean by handling all complex business logic in the controller rather than the template.This strict separation keeps your backend logic secure and your templates highly predictable. Adapting to Single Directory Components requires a mindset shift for backend developers. But it is the absolute best way to scale enterprise software without creating a massive technical debt trap for future engineers.
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.
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.
Ajit Shinde, Sr. Drupal Developer and a longtime open source contributor, built the workspace tools in the Tool Belt module so AI agents in Drupal work under the same staging and review rules as human editors.
AI assistants can already generate content, update fields, and perform administrative tasks in Drupal. The more interesting question is not whether an AI can perform these operations, but how we allow it to do so safely and predictably.
Earlier this year, Tag1 joined the Drupal AI Initiative as a Gold Certified Partner, and our first contribution is extending Workspaces so AI agents work under the same staging, review, and rollback framework as human editors. The workspace tooling in this post is part of that governance work.
To get Workspaces talking to AI agents, we built a new module called Tool Belt on top of Drupal's Tool API. The Tool API does the underlying work, so it's worth understanding first.
The Tool API provides the system that allows Drupal to expose structured, callable operations to AI agents. It defines how tools are described, how inputs are validated, and how results are returned.
In short, it turns Drupal functionality into well-defined actions that an AI can safely invoke.
Tool Belt builds on that.
Tool Belt provides ready-made tools that AI agents can use to perform common Drupal operations. Instead of asking a language model to understand Drupal internals, we give it a controlled set of capabilities.
I worked mainly on workspace-related tools, which ship as the Tool Belt - Workspace submodule (tool_belt_workspace). These allow an AI workflow to:
Imagine an editor asks:
Editor: Create an article announcing our upcoming Drupal event.
This requires more than generating text. The AI must decide:
Tools turn each of those decisions into explicit, controlled operations the agent must call, rather than leaving it to guess.
Drupal Workspaces allow changes to be grouped and reviewed before publishing. This is especially useful for AI-generated content.
Instead of always creating a new workspace, the agent can:
After creating the article, the assistant can generate a temporary preview link. This allows editors (and stakeholders) to review staged content without exposing it publicly.
A workspace may contain multiple changes. Before publishing, the assistant shows a summary:
Assistant: This workspace contains the new article and related updates. Do you want to publish these changes?
This ensures publishing is always intentional.
If the result is not useful, the workspace can be reverted or deleted, with explicit confirmation to avoid mistakes.
A typical workflow looks like this:
It helps to separate responsibilities:
Below are the actual prompts used in this setup.
This agent uses the other two agents (content agent and workspace agent) as tools.
## Role
You are the Orchestrator for a Drupal 11 AI site. You own every word the user sees. You never do content or workspace work yourself — you route it to two specialists and turn their machine-readable results into user-facing replies:
* Workspace Agent — workspace lifecycle: create, reuse, switch, publish, revert, delete, preview links, tracked changes.
* Content Agent — creating and editing content entities (any bundle, primarily nodes).
Specialists never talk to the user. They return a success result, a `blocked: need <X>` line, or a failure. You translate those into an answer or exactly one question.
## Scope
In scope: content creation/editing, workspace staging, preview links, publishing, and the lifecycle actions above. Out of scope: users and roles, site building and fields, moderation workflows, emails, configuration, anything else. For an out-of-scope request, reply in one sentence stating what you can do and that this request is outside it — do not call a specialist.
## The one approval question
A "task" is one user goal you carry from its first message to completion. Before the first content write of a task (create, edit, or save a content entity), ask exactly ONE approval question combining:
* the rough structure you plan to write: bundle, title, and a one-line outline per field (never full body text), and
* the staging choice: stage in a workspace, or go live now?
If the user already stated the staging choice (they named a workspace, asked for a new one, or said live), ask only for structure approval.
When this question applies:
* Ask it BEFORE calling any agent for a write. Only read-only checks may precede it.
* Never ask it for read-only requests, or for lifecycle actions on an existing workspace (publish, revert, delete, switch, preview) — those have their own rules below.
* Ask it once per task. After the user approves, run the routing sequence to completion with no further approval question, and do not re-ask unless the user changes direction.
This limit governs the APPROVAL question only. A specialist `blocked:` clarification (see Blocked results) and a destructive-action confirmation (see below) are separate and are not counted against it — you may still ask those.
## Task mode
From the staging choice, fix one task mode for the request and keep it:
* live — the user chose live.
* stage — the user chose staging or named/requested a workspace.
Reuse-vs-create is the Workspace Agent's decision, not yours: it reuses the active non-live workspace, or creates one when Live is active. Only if the user explicitly asked for a new/fresh/separate workspace, say so in your setup instruction and the Workspace Agent will create one regardless of the active workspace. Never present a reused workspace as newly created.
## Routing
Run each step at most once per task and track what is done.
Per task, the Workspace Agent gets AT MOST TWO calls, in this order: one workspace SETUP call, then one PREVIEW-LINK call after the content exists. Never create a second workspace for the task, never repeat setup, and never request the preview more than once. A read-only check does not count. A later explicit lifecycle request (publish, revert, delete, switch) is a NEW task, routed normally.
The preview link must be generated AFTER the content is created so it can redirect straight to the new page — the setup call establishes the workspace, the content call yields the node ID, and only then do you ask for the preview. Never request the preview before you hold the node ID.
Whenever you call the Content Agent, include the user-approved structure and state that the user already approved it, so it does not re-present it.
### stage
1. Call the Workspace Agent to establish the workspace for this task ONLY — do not ask for a preview yet. Suggest a short label for a new workspace; state the label when the user explicitly asked for a new one.
2. Call the Content Agent for the content work. Capture the node ID it returns.
3. You MUST now call the Workspace Agent a second time for the preview link, passing the redirect target `/node/<ID>` using the node ID from step 2. This call is mandatory — the only way to obtain a preview URL is from this tool result. Do not skip it, do not answer the user before it returns, and never invent, assume, or describe a preview link you have not received from this step.
4. The Workspace Agent's preview result contains the preview URL as plain text. Copy that URL VERBATIM — character for character — as the FIRST line of your reply, as plain text with no markup around it (see the Preview link format rules in Output). If step 3 did not run or returned no URL, you have NO preview link: omit it entirely and add one short line saying the preview could not be generated.
### live
* Call the Content Agent directly; do not create or reuse a workspace. Read-only workspace checks are still allowed.
### Later lifecycle actions
Route publish, revert, delete, and switch to the Workspace Agent for that specific action, subject to the confirmations below.
## Destructive confirmations
Confirm before executing, even when the request was explicit — one confirmation each. If the user already confirmed in the same message, proceed.
* Publish: first get the tracked-changes summary from the Workspace Agent, confirm while showing what will go live, then publish.
* Revert: confirm naming the workspace label and ID, then revert.
* Delete: confirm naming the workspace label and ID, then delete.
## Task continuity
A reply that answers your most recent question continues the current task with the same task mode. Do not restart workspace setup unless the user explicitly changes direction.
## Blocked results
When a specialist returns `blocked: need <X>`, ask the user exactly one natural-language question carrying any options the specialist provided (e.g. a list of matching nodes). When answered, resume the same task with the same task mode. This is a clarification, not a new approval question.
## Failure handling
* Never retry blindly. Retry a specialist step at most once, and only with corrected input.
* Exception: never retry the Workspace Agent setup step. If setup fails, do not call the Workspace Agent again for this task — a retry would create a second workspace. Stop and surface the failure per the rule below.
* If a step fails twice, stop: state in one sentence what succeeded and what failed, include the actionable error output, and offer up to three next steps.
## Output
Keep replies short and operational.
### Preview link format
The Workspace Agent returns the preview URL as plain text (e.g. `https://cms.ddev.site/workspace-preview/W7MIUT5l2ByB`). Your job is only to RELAY it — copy that URL to the FIRST line of your reply exactly as received, as plain text. Do NOT wrap it in a markdown link or an HTML anchor, and do NOT alter, shorten, or retype it — just the raw URL on its own line.
* Correct: `https://cms.ddev.site/workspace-preview/W7MIUT5l2ByB`
* Wrong — and forbidden: any `<a ...>` tag · a markdown link `[Preview the page](...)` · descriptive text with no URL · substituting a URL of your own.
If the Workspace Agent returned no URL, write NO preview link and NO preview link text at all; instead add one short line stating the preview could not be generated.
### Staged-content reply
After staged creation/edit, the reply is: the preview URL relayed verbatim as plain text (per the format above) on the first line, then one short line naming the page (title and node number). Do NOT include the workspace label or workspace ID, and do NOT offer to publish, ask about going live, or suggest any next step — end after stating what was created. A standalone preview reply carries the URL only — no workspace label, workspace ID, or node links.This agent uses tools like tool:tool_belt:entity_field_value_definitions and tool:tool_belt:entity_field_values.
## Role
You are the Content Agent for a Drupal 11 AI Site. You report to the Orchestrator, never directly to the user. You create and edit content entities (any bundle), primarily nodes.
## Tool execution rule
Use the entity tools to do the work; do not describe what you would do. Do not call tools speculatively. If you are missing information a tool requires, return a `blocked: need <X>` line rather than guessing.
## Site schema (authoritative — do not guess field names)
* Bundle `article`: `field_body` (text_with_summary), `field_tags` (entity reference → taxonomy vocabulary `tags`), `field_test` (string).
* Bundle `page`: `field_content` (rich text), `field_description` (REQUIRED), `field_featured_image` (entity reference → media), `field_tags`.
* Rich-text format: `content_format` is THE rich-text format on this site. `basic_html` and `full_html` do NOT exist — never use them. Set `content_format` on text-with-format fields.
* Always confirm exact fields with `entity_field_value_definitions` for the resolved bundle before setting configurable fields; the schema above tells you what to expect, the tool tells you what is actually there.
## Structure approval
If the Orchestrator's instruction already states the user approved the structure, do NOT ask again — proceed. Only if it does not, return `blocked: approval needed — proposed structure: <bundle, title, one-line-per-field outline>` and stop. The Orchestrator owns all user dialogue.
## Create workflow
1. `entity_field_value_definitions` for `entity_type_id` = `node`, `bundle` = requested type — the single source of truth for which fields exist, which are required, and what format each expects. If the bundle is unknown, `entity_type_list` can enumerate bundles; if still unresolved, return `blocked: need the content type`.
2. `entity_stub` for `node` + bundle, with the user-provided title in `base_fields`. Set `status` to published.
3. For each field, `field_set_value` (entity object from step 2, machine `field_name`, value in the expected format). Only set fields that exist for the bundle. Generate suitable HTML body content (not Markdown) when the user asked for content about a topic but gave no body. If a required field is missing and cannot be reasonably generated, return `blocked: need <field>`.
4. `entity_save` with the final entity.
## Edit workflow
1. Load: `entity_load_by_id` when a node ID is given. If only a title is given, `entity_load_by_property` with property `title` — note this returns property maps, NOT entity artifacts, so read the matching ID and then re-load with `entity_load_by_id` to get a usable entity. If multiple match, return `blocked: need which node — <list id/title>`.
2. `entity_revision_add` on the loaded entity — MANDATORY before changing fields, so the edit is a new revision.
3. `entity_field_value_definitions` for the resolved bundle (use `entity_metadata` first if the bundle is unknown).
4. `field_set_value` for each field the user wants changed; reuse the existing valid text format, never guess a new one. Do not touch fields the user did not mention unless required for a valid save.
5. `entity_save`.
## Graceful failure
If any tool fails, stop, return the tool error output as-is, and offer up to three concrete next steps (confirm bundle, provide required field, provide node ID, check permissions). Never retry the same failing call with the same inputs.
## Output contract (to the Orchestrator, not the user)
* Success (create): the numeric node ID (state it as `node ID <N>` so the Orchestrator can build `/node/<N>`), bundle, title, and the saved status.
* Success (edit): the numeric node ID (as `node ID <N>`) and a short list of fields changed.
* Blocked: a single `blocked: need <X>` line carrying any options the Orchestrator will need (e.g. the list of matching nodes).
Do not add preview links, workspace labels, or edit links — the Orchestrator assembles the user-facing reply.This agent uses tools like tool:tool_belt:workspace_create_and_switch and tool:tool_belt:workspace_preview_link.
## Role
You are the Workspace Agent for a Drupal 11 AI Site. You report to the Orchestrator, never directly to the user.
You handle only workspace operations and workspace lifecycle actions. You do not create or edit content entities such as nodes or media. If asked for content work, return `blocked: content operations must be routed to the Content Agent`.
## Tool execution rule
Use the available workspace tools to perform actions; do not describe what you would do. Do not call tools speculatively.
Every invocation is INDEPENDENT and STATELESS. Decide what to do from THIS instruction alone — never from what an earlier invocation did, and never carry over a plan from a previous call. The Orchestrator may call you several times in one task (e.g. setup, then later preview); each call is a fresh, self-contained request.
Classify the instruction into exactly ONE action, then call ONLY the tools that action's allowed set permits (see the Allowed tools per action table). Any tool NOT in that set is forbidden for this invocation — do not call it for context, convenience, or to "finish the job." Calling a tool outside the action's set is the primary failure mode: it produces wrong state and can be fatal (e.g. creating or switching a workspace during a preview or publish call).
If the instruction is ambiguous or names no recognizable action, return `blocked: need <what is unclear>` — never guess by calling a mutation tool.
## Allowed tools per action
For each action, call ONLY the tools listed. `workspace_exists` is additionally allowed with ANY action solely to resolve a label to an ID (Label resolution). Nothing else is ever implied.
| Action (what the instruction asks for) | Tools you may call — and NO others |
| --- | --- |
| Setup / establish workspace for staging | `workspace_get_active`, then `workspace_create_and_switch` (only per the stage rules below) |
| Preview link | `workspace_preview_link` ONLY. Never create, switch, or check active. |
| Publish | `workspace_tracked_content`, then `workspace_publish`. Never create or switch. |
| Revert | `workspace_revert` ONLY. |
| Delete | `workspace_delete` — plus `workspace_switch` (to Live) FIRST only if deleting the active workspace. Never create. |
| Switch | `workspace_switch` ONLY. |
| Read-only check (active/exists) | `workspace_get_active` and/or `workspace_exists` ONLY. Never mutate. |
## Workspace tools reference
| Tool | When to use |
| --- | --- |
| `tool_belt:workspace_get_active` | Report the current workspace. Returns `has_active`, `workspace`, `is_live`. Being on Live is a normal success state. |
| `tool_belt:workspace_exists` | Resolve a label to an ID, or verify a workspace exists. Labels are not unique; the first exact match wins. |
| `tool_belt:workspace_create_and_switch` | Create a new workspace and switch to it in one call. The canonical way to start staging. During staging setup, call this only when Live is active or the user explicitly asked for a new workspace — otherwise reuse the already-active workspace. Works regardless of the currently active workspace (no need to switch to Live first); `parent` accepts a parent workspace ID only; the active workspace is never implicitly the parent. |
| `tool_belt:workspace_switch` | Switch to an existing workspace by ID. Omit the `workspace` input to switch to Live. |
| `tool_belt:workspace_tracked_content` | List what changed in a workspace. Use before publishing. Defaults to the active workspace when the input is omitted. |
| `tool_belt:workspace_publish` | Publish all tracked content in a workspace to Live. Defaults to the active workspace when the input is omitted. Only top-level workspaces can be published. Destructive. |
| `tool_belt:workspace_revert` | Revert a previously published (closed) workspace. Requires the WSE module. Destructive. |
| `tool_belt:workspace_preview_link` | Generate a shareable preview link. Default expiry is 8 hours; pass `expiry` only when the user requested a specific duration. Pass `redirect_url` (an internal path such as `/node/<ID>`) to make the preview open directly on that page rather than the workspace root. The URL is a bearer capability — anyone holding it can view the workspace. |
| `tool_belt:workspace_delete` | Delete a non-active workspace. Destructive. |
## Mode behavior
This section is the SETUP action only — it applies solely when the instruction asks you to establish the workspace context for staging. It NEVER applies to a preview, publish, revert, delete, switch, or read-only instruction; for those, ignore this section entirely and follow only that action's row in the Allowed tools table and its Action flow. A preview instruction arriving after setup is a preview action, not setup — do not re-run any of the steps below.
The Orchestrator passes one task mode: `live` or `stage`. Never choose or change the mode yourself.
### stage
* Call `tool_belt:workspace_get_active` first — its result decides what follows
* If a non-live workspace is already active: use it. Do NOT call `tool_belt:workspace_create_and_switch`. Do not switch. Return its label and ID and state clearly that it was reused, not created.
* Only if Live is active: call `tool_belt:workspace_create_and_switch` with the provided label, or derive a short label from intent such as `Draft <bundle> <short title>` or `Update <bundle> <short title>`. Return the new label and ID and state clearly that the workspace was newly created.
* Exception: if the instruction states the user explicitly asked for a new workspace, call `tool_belt:workspace_create_and_switch` even while another workspace is active — do not switch to Live first; creation does not depend on the active workspace
* Call `tool_belt:workspace_create_and_switch` at most once per invocation. If it fails, verify the rollback (see below) and then return a `blocked:` or failure result. Never call `tool_belt:workspace_create_and_switch` a second time in the same run — not with a different label, not after any rollback check. A failed create is terminal for this run.
* If the create call fails: call `tool_belt:workspace_exists` with the label to verify the rollback actually removed it (the failure message "The workspace was not created." can be false); report an orphan workspace if one is found
* Setup establishes the workspace only. Do NOT generate a preview link during setup — the preview is a separate, later instruction (issued once the content exists so it can redirect to the new page). Return the workspace label and ID.
### live
* Do not create or reuse a workspace. Perform read-only checks only if the Orchestrator asks for them.
## Label resolution
When given only a workspace label, resolve it first: one `tool_belt:workspace_exists` call converts the label to an ID (labels are not unique; the first exact match wins). If it returns `exists = false`, return `blocked: need the workspace ID — label "<label>" did not resolve`. Prefer IDs everywhere and always capture the ID from tool results.
## Action flows
### Switch
* Call `tool_belt:workspace_switch` with the workspace ID (resolve a label first, per Label resolution)
* To return to Live: call `tool_belt:workspace_switch` with the `workspace` input omitted
### Publish (explicit request only)
* Call `tool_belt:workspace_tracked_content` for the target (omit `workspace` for the active one). If there are no tracked changes, do not publish and report that there is nothing to publish.
* Call `tool_belt:workspace_publish`
* If it fails because the workspace has a parent, report that only top-level workspaces can be published
### Revert (explicit request only)
* Call `tool_belt:workspace_revert` directly (it reports not-found with a friendly message)
* On failure, explain that revert requires the WSE module and a previously published (closed) workspace, and include the tool error output
### Preview link (explicit request only)
* Call `tool_belt:workspace_preview_link` directly (omit `workspace` for the active one). No confirmation round-trip; state the expiry in the result.
* If the instruction names a target page or path (e.g. `/node/<ID>`), pass it as the `redirect_url` input so the preview opens directly on that page instead of the workspace root. Accept an internal path only; if given a bare node ID, format it as `/node/<ID>`.
* Return the `preview_url` verbatim as plain text (see Output contract → Preview). Do not wrap it in markdown or an HTML anchor — just the raw URL.
* If it fails because of a missing module, explain that the WSE Preview module is required
### Delete (explicit request only)
* If the target is the active workspace: first call `tool_belt:workspace_switch` with the input omitted (switch to Live), then `tool_belt:workspace_delete`
* Otherwise call `tool_belt:workspace_delete` directly
## Error interpretation
* `Tool plugin access denied.` from switch, publish, delete, preview, or tracked-content ALSO means "workspace not found" — re-check the ID before reporting a permission problem
* Branch on message content, never on success status alone: "No workspace found ...", "has no changes to publish", and `exists = false` are informative results, not errors to retry
* Never retry a failed mutation with the same or different inputs; in particular a failed `tool_belt:workspace_create_and_switch` is terminal for this run — do not attempt it again with any label
## Output contract
### Success
* Workspace actions: the workspace label and ID, plus what happened (created, reused, switched, published, reverted, or deleted)
* Preview: as the FIRST line, the exact `preview_url` string from the tool result, as plain text on its own line — copied verbatim, with no surrounding markup, no markdown link, and no HTML anchor. Follow it with the expiry on the next line. Do not include the workspace label or ID, node links, or edit links in a preview response. If you did not receive a `preview_url`, return the failure instead.
### Blocked
* One line: `blocked: need <what is missing>` (for example the workspace ID for an unresolved label, or which workspace to publish). The Orchestrator owns all user dialogue.Tool Belt is not just about adding capabilities, it is about controlling them.
With the right setup, you can ensure that:
Tool API provides the foundation. Tool Belt provides the tools. Workspaces provide a safe environment.
Together, they enable AI-assisted workflows that respect Drupal's editorial process while improving efficiency.
The result is not just smarter automation, but governed automation, where AI helps and humans stay in control.
Bringing governance to AI-driven changes is Tag1's starting contribution to the Drupal AI Initiative, and this workspace tooling is where it begins.
read moreLast week, PreviousNext joined forces with fellow Drupal Certified Partners Annex, Morpht and Salsa Digital for a shared booth at the Public Sector Network's Government Innovation Showcase in NSW. We came together to show government agencies what Drupal has to offer, including Drupal CMS, AI, security, and content governance.
Drupal Certified Partners don't usually share a stand, so this was something special. PreviousNext, Annex, Morpht and Salsa Digital came together to present a single message about what Drupal delivers for the public sector.
Several attendees commented on this directly, with consistent feedback on how collaborative the presence felt.
This mattered because most people in the room already knew Drupal. Thanks to OneCX's presence across the NSW government, there was no need to explain what Drupal is or how PreviousNext support it. That freed up conversations to go deeper, into real problems agencies are trying to solve and how recent innovations in Drupal can help address them.
The day's sessions reinforced a theme that's top of mind for many of our government clients: how to use AI responsibly without losing sight of the people doing the work.
These conversations line up closely with how we think about AI at PreviousNext: as a tool that supports senior expertise and speeds up repeatable work, always with human oversight and clear governance. It's also a direction the wider Drupal community is investing in with the Drupal AI Initiative and its 2026 roadmap.
Beyond the sessions, the day was about connecting with the people shaping digital government in NSW. We caught up with contacts from Digital NSW, Blacktown City Council, and the Department of Customer Service, among others, and heard firsthand where agencies see Drupal fitting into their future plans.
It was also a chance to spend time with the broader DrupalSouth community, including the team helping coordinate partner presence at events like this one. Conversations like these are exactly why we stay involved in the wider Drupal community.
We're expecting the larger Digital NSW government conference later in the year to bring even more opportunities to connect. We'll be there and look forward to building on the relationships we started at this event.
Want to know more about how PreviousNext works with government agencies on Drupal? Get in touch with our team.
This article explains why I use OpenCode as the stable local harness around replaceable remote AI models. The core distinction is simple: my agents, permissions, skills, and workflow should remain mine, while model providers such as Anthropic, OpenAI, OpenRouter, or Z.ai stay external and swappable. I also describe why one-time configuration matters in practice: the same setup can be reused in the OpenCode terminal, CodeNomad, IntelliJ IDEA, PhpStorm, Zed, and Buzz through ACP. The point is not novelty. It is privacy, sovereignty, provider independence, and not rebuilding the same harness every time a new interface shows up.
Many organizations want to run A/B tests but either don’t know where to start or are discouraged by the high cost of enterprise-grade experimentation platforms like Optimizely or VWO. The good news: if your website runs on Drupal, there’s an approachable, flexible, and cost-effective alternative that can be built right into your existing Drupal instance.
A/B testing is a method for comparing two or more versions of a webpage or user experience to determine which performs better. Visitors are randomly assigned to different versions (variants), and their behavior is tracked to measure effectiveness against a goal; such as conversions, engagement, or navigation success.
In this post, I’ll share how we implemented A/B testing for Oberlin College & Conservatory to test two versions of a homepage design using the community-contributed A/B Test JS module and why it’s a powerful approach for teams that want accurate testing without engaging with another vendor or purchasing software.
If your site is on Drupal, the A/B Test JS module is a lightweight, highly flexible tool for running front-end A/B tests. It does require writing or editing JavaScript (or knowing someone who does like cough cough Aten Design Group), but provides enormous flexibility.
The module has two core concepts:
Let’s break them down. I've also included some example code if helpful for getting started.
Every test in A/B Test JS begins with a condition, a JavaScript function that returns true or false. A condition is simply the set of rules for when a user should be included in the experiment.
A condition can trigger based on:
For our client, Oberlin, the requirement was to only run the A/B test for users who are off campus.
To accomplish this, we created a simple API endpoint that returned whether the user was on- or off-campus based on IP address. Our condition function queried this API and only ran the test when the user was off campus.
This let Oberlin’s marketing team measure external user behavior from prospective students without affecting on-campus experiences.
Once a condition is met, users are randomly placed into one of the test’s experiences. You can configure:
Experiences are written in JavaScript and can modify virtually anything on the page. Here are some powerful experience actions you can set up:
If you can do it in JavaScript, you can test it.
Oberlin wanted 50% of off-campus users to see:
And 50% of off-campus users to see (our control):
The A/B Test JS module assigns users, sets a cookie, and ensures their experience persists across sessions throughout the test window.
For accurate experiment analysis, each variant triggers custom analytics events. Oberlin uses both Google Analytics 4 and Microsoft Clarity, which integrate easily with the A/B Test JS module.
// Send variant information to Microsoft Clarity // Example: clarity("set", "ab_test", "variantA"); clarity("set", "ab_test", testVariant); // Push A/B test event to Google Tag Manager / GA4 window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: "ab_test_view", test_name: "oberlin_nav_homepage_test", variant: testVariant, // Helpful for later analysis timestamp: new Date().toISOString() });
ab_test_view) makes GA4 funneling much easier.With custom events firing, Oberlin can now analyze how real users respond to experience changes by tracking these metrics:
The A/B Test JS module is a flexible, developer-friendly approach to A/B testing that avoids costly subscription tools while still offering the rigor teams need to make data-driven decisions.
For Oberlin College, it enabled:
After a month of testing the two variables, their marketing team was able to make decisions about homepage content based on heatmap insights, clicks, scroll depth, and time on the page.
If you’re running Drupal and want to start experimenting, this module may be one of the most valuable additions to your stack. Reach out to us if you'd like help planning your next round of experiments.
Cost anxiety
Last month, on a client project, I ran out of my monthly 10,000 Copilot Credits allotment (which costs approximately $100 USD). Limiting developers to 10,000 Copilot Credits per month is probably not enough for enterprise development, yet these limitations forced me to think about how best to use my tokens, specifically which models to use them with.
Token anxiety
Watching these credits being consumed was anxiety-provoking, especially as the context window filled up quickly while I desperately tried to get the AI to fix the creation of the Drupal model that had skidded off the rails. In just 2 hours, I consumed 2,000 credits, which forced me to research how best to get the most out of my credits/tokens. The most immediate mistake I made was spending 2 hours in one session, which created a huge context window that was being compacted as more and more tokens were consumed with each request and response. The biggest mistake I made was choosing the wrong model to begin with and, more specifically, using only one model and only one tier.
Choosing a model
The big three LLMs that I use are: Claude from Anthropic, GPT from OpenAI, and Gemini from Google.
Since Claude Code was the first coding harness to produce acceptable code, it is the default for many developers, but damn, Claude is expensive.
Gemini is said to be the cheapest model, but frankly, my one-off experiment didn't generate acceptable code. Simply put, I can live with an LLM getting a method's parameter order or data typing wrong, but when they start inventing nonexistent methods, I am out.
GPT has become my go-to model because the code is decent, readable, and refactorable.
Last week, OpenAI showed they were aware of the cost challenge when they adjusted their GPT 5.6 pricing, with the publication of advancing the...Read More
read moreWhen 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.
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.
Public software is easiest to celebrate at launch, when a service is delivered, a repository is published, and an institution can point to visible progress. Its harder test begins after the original contract ends. Security response, documentation, upgrades, knowledge transfer and operational ownership must continue even when the delivery team or supplier changes. The EU Open Source Strategy, published by the European Commission on 3 June 2026, treats procurement, deployment, maintenance and governance as parts of the same software lifecycle.
Public procurement should therefore test continuity rather than initial delivery alone. Buyers need to know whether data, configuration and documentation can be transferred; whether another supplier can operate the service; whether publicly funded improvements can be reused; who will handle vulnerabilities and dependency updates; and how long transition support will remain available. An open licence can widen the range of possible suppliers, but that choice remains theoretical when system knowledge, access procedures or maintenance budgets stay with the incumbent. Avoiding lock-in requires both legal permission and the practical capacity to act on it.
The strategy proposes an Open Source Maintenance Instrument, dependency analysis, stewardship support and common security baselines for public repositories. These measures recognise that testing, release management, vulnerability response and documentation are infrastructure work rather than incidental volunteer activity. Drupal 7 reached end of life on 5 January 2025, but its source code remained available after community releases, fixes and security advisories ended. LocalGov Drupal offers a concrete model of organised stewardship by bringing councils and suppliers into shared product governance, technical maintenance and a cooperative structure intended to support financial sustainability.
Public money should produce more than software that can still be downloaded after the original team leaves. Contracts should fund security work, upgrades, current documentation, supplier handover, upstream contribution and governance across changes in vendors and budget cycles. Europe’s open-source ambitions will achieve little if institutions publish more code without retaining the capacity to operate, improve and transfer it. Public code becomes infrastructure only when responsibility survives delivery.
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 Kazima Abbas.
read moreAuthor: 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.
The Brand Guardrail: Localised Nuance & Centralised Brand Voice
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 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.
The Brand Guardrail: Localised Nuance & Centralised Brand Voice
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.
How should development teams adopt AI without sacrificing code quality or collaboration? In this Talking Drupal Cafe, Stephen Cross is joined by Mike Miles and Jim Birch to discuss practical strategies for integrating AI into Drupal development teams. They explore AI coding assistants, team policies, code review, agent workflows, governance, and real-world lessons from using tools like Claude Code and GitHub Copilot in production environments.
For show notes visit: https://www.talkingDrupal.com/cafe020
TopicsJim Birch is Director of Engineering and AI Practice Lead at Kanopi Studios, where he leads engineering teams and oversees the company's responsible adoption of AI. Jim is also a Drupal CMS committer, and Recipes Initiative Coordinator, and is a Google Cloud Certified Generative AI Leader.
Michael MilesMike Miles is a technical leader and speaker with more than 20 years of experience in web engineering, open-source development, and digital platform delivery. As the Director of Web Development at MIT Sloan, he leads the team responsible for the development, maintenance, and growth of the school's public digital properties.
Mike regularly speaks at technical conferences on topics including modern web development, Drupal, technical leadership, testing, delivery practices, and practical AI adoption. He is also one of the organizers of New England Drupal Camp.
Stephen CrossStephen Cross has been a Drupal developer for over 20 years and founded Talking Drupal in 2013. As founder of Second Signal Media, he combines his passion for open source and media production to share conversations that help the Drupal community learn and grow.
GuestsMichael Miles - mikemiles86
Jim Birch - thejimbirch
Stephen Cross - stephencross
ResourcesCourses https://anthropic.skilljar.com/ https://academy.openai.com/pages/courses
Skills https://kanopi.github.io/cms-cultivator/ https://kanopi.github.io/delivery-record/
read more
This is the first post in a series of posts looking at migrating content from a Jadu site into a Drupal site running the LocalGov Drupal (LGD) distribution. The site I was migrating content into was the new site for Central Bedfordshire, and whilst other implementations of Jadu may differ from what I describe here, it should be enough information for you to understand the process.
Jadu is a proprietary CMS application that is mostly written in PHP. Back in 2011 I went to a talk by one of the developers from Jadu at the PHPNW11 conference, so I was aware of the system. That talk, by the way, was interesting as they built a system called Phalanger that allowed PHP (and Jadu) to be run on a .NET environment. That project is now called PeachPie and it looks like it is still under active development.
LocalGov Drupal is a Drupal distribution that combines Drupal, some configuration, and a collection of modules with the aim of making it easier for councils to create websites. The functionality provided includes content pages, news pages, bus timetables, and waste collection systems. What's more, it's maintained by a vibrant community of people.
In this article we look at how the Jadu API is used to get hold of site content, and what we can do in Drupal to facilitate the migration of this content. We then look at a simple part of the migration as an introduction to the whole process. This won't be an introduction to the migration API as I will skip over some of the fine details of the API to keep things brief.
First, let's look at the Jadu API.
philipnorton42 read moreGabor asked in Slack about how people contributing to Drupal manage multiple different Drupal versions, and different contributed module branches, when using AI agents:
You have a supplier spreadsheet with a category column that reads Animals > Dogs > Food, and you want Drupal to end up with a real taxonomy tree: Animals, with a child Dogs, with a child Food, each level created only if it does not exist yet, and every product referencing the leaf of its own path.
Neither Drupal core nor Feeds does that on its own. Feeds Tamper Term Hierarchy does: it reads the path out of the column, creates the taxonomy terms that do not already exist, and respects the hierarchy between them. It has been on drupal.org since 2021 and reached its first stable release, 1.0.0, this week.
The interesting part is not the splitting. Any parser can split a string on a delimiter. The interesting part is deciding, for each segment, whether the term you are looking at already exists, and that turns out to be a question about identity that most import tooling gets wrong.
Take a small catalogue:
sku,name,category
1001,Rope leash,Animals > Dogs > Accessories
1002,Dry food 3kg,Animals > Dogs > Food
1003,Dry food 1kg,Animals > Cats > FoodThe tree you want out of it:
Animals
├── Dogs
│ ├── Accessories
│ └── Food
└── Cats
└── FoodThere are two terms called Food in that tree. One is the dog food category, the other is the cat food category, and they have to stay separate. If they collapse into one, every dog product and every cat product point at the same category, your faceted search stops making sense, and the client finds out before you do.
Now ask what “does this term already exist?” means while the third row is being imported. Food exists, in the sense that a term with that name is already in the vocabulary. It is the wrong one. The right answer is that Food under Cats does not exist yet, even though Food under Dogs does.
That is the whole problem in one sentence: in a hierarchy, a term is identified by its name together with its parent, not by its name. A lookup that ignores the parent will happily hand you a term from a different branch.
This is why Feeds’ built-in term autocreation cannot be pressed into service here. It matches by name within the vocabulary, because for a flat vocabulary of tags that is exactly right. Give it a path and it does something reasonable and useless: it looks for a term named Animals > Dogs > Food, does not find one, and creates a single term with that literal name, greater-than signs included. One flat term per distinct path.
The fix follows from the diagnosis. Rather than looking up each segment in the vocabulary, look it up among the children of the segment resolved just before it:
Animals is looked up among the root terms.Dogs is looked up among the children of Animals.Food is looked up among the children of Dogs.Walking Animals > Cats > Food takes a different turn at step two, finds no Food under Cats, and creates one. Two terms, same name, different parents, which is what the source data described all along.
So how does the plugin know which Food is the right one? It does not. The path tells it, one level at a time, and the only thing carried between levels is a single term ID. This is the loop, with the caching and the options stripped out:
$parent = 0;
foreach ($names as $name) {
$terms = $storage->loadByProperties([
'name' => $name,
'vid' => $vocabulary,
'parent' => $parent,
]);
$term = $terms ? reset($terms) : $this->createTerm($name, $vocabulary, $parent);
// The term just resolved becomes the parent of the next lookup.
$parent = (int) $term->id();
}
return $parent;$parent starts at 0, which is how Drupal spells “no parent, this is a root term”. Every lookup is constrained by it, and the last line of the body is what makes the walk work at all.
Trace Animals > Cats > Food through it and the three queries are (Animals, parent 0), (Cats, parent 1), (Food, parent 5). Trace Animals > Dogs > Food and the third one is (Food, parent 3), which is why it finds the dog food term instead of creating a second one. Neither of them ever asks “is there a term called Food?”, which is the question that would produce the wrong answer.
One honest caveat: Drupal does allow two sibling terms with the same name under the same parent. If your vocabulary already contains such a pair, reset() picks whichever the storage returns first. The plugin cannot disambiguate what the data itself does not distinguish.
Two further properties fall out of this for free.
The import becomes idempotent. Re-run the same feed and every segment resolves to the term created the first time, so nothing is duplicated. Add a row with a new leaf under an existing branch and only the leaf is created. That matters because supplier feeds are re-imported nightly, and an import that duplicates its own output is worse than no import.
And the created terms carry the hierarchy, not just the labels. You get a tree you can render as a menu, use in a facet, or attach access rules to, rather than a flat list of strings that happen to contain angle brackets.
With Feeds, Feeds Tamper and Feeds Tamper Term Hierarchy installed, on a feed type with a CSV parser:
>, and spaces around each segment are trimmed, so A > B and A>B behave identically.Step 2 is worth dwelling on for a moment, because getting it wrong produces a failure that does not look like one.
The plugin creates the terms itself and returns the ID of the last one in the path. If the mapping is left on its default of matching by term name, Feeds receives that number and does the only sensible thing with it: it looks for a term called 23, does not find one, and creates it. The import reports success. The log is clean. The vocabulary contains a perfectly correct hierarchy, built by the tamper, sitting next to a handful of terms called 23, 25 and 26, which are the ones your content actually references.
We reproduced exactly that on a clean Drupal 11 site while preparing this release. If your categories are numbers, this is why.
Sources often pack several categories into one cell:
sku,name,categories
1001,Rope leash,"Animals > Dogs > Accessories, Animals > Cats > Toys"That works, by combining two plugins in the right order. Tamper runs its plugins as a pipeline, and when one of them turns a single value into several, the ones after it run once per value:
,.>.The Explode produces two paths, the hierarchy plugin runs twice, and the field receives two term IDs. Reverse the order and the hierarchy plugin is handed the whole cell, treats the comma as part of a term name, and you get a category called Accessories, Animals.
Creating missing terms is the right default for a first import into an empty vocabulary. It is the wrong default when the taxonomy is curated and the feed is a third-party file you do not control, because then a typo at the supplier silently becomes a category.
1.0.0 adds an option for that. Uncheck Allow terms to be auto created and the plugin stops inventing terms: a path that does not fully exist is skipped instead. A supplier renaming Accessories to Accesories shows up as skipped rows rather than as a quietly duplicated branch.
This one came from a support request by someone who wanted precisely that behavior, and from an implementation contributed by someone else two years ago. It sat in the queue until this release, which is on us.
The opposite case also happens. The vocabulary already holds Animals > Dogs > Food and the source only carries Dogs > Food, because whoever exported it dropped the top level.
By default the first segment has to be a root term, so Dogs > Food creates a second, unrelated Dogs at the root. Correct by the rule above, unhelpful in practice.
Match the first term anywhere in the hierarchy relaxes that first lookup only: the first segment may match a term at any depth, and everything after it resolves underneath whatever it matched. Dogs > Food then attaches to the existing branch.
It is off by default and should stay off unless you need it, because it trades away exactly the identity rule this post is about. When several terms share a name at different depths the first match wins, and which one that is depends on term IDs rather than on anything meaningful.
Feeds Tamper Term Hierarchy 1.0.0 works with Drupal 10 and 11. It depends on Tamper and core’s Taxonomy module, and on Feeds Tamper if you are driving it from Feeds, which is the common case but not the only one: it is an ordinary Tamper plugin and works anywhere Tamper plugins run.
composer require drupal/feeds_tamper_term_hierarchyThe release exists because people kept filing issues against it. The autocreate option, the partial path matching, the Drupal 11 compatibility and the dependency cleanup were all reported, and in three cases implemented, by ethant, bbu23, longwave, damienmckenna and kazah. Their names are on the commits.
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.
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 $1.5 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.
Custom Formatters is old. I started it in 2009, my first year building seriously for Drupal, and shipped it through Drupal 6 and 7. Then in late 2016, not long after the first Drupal 8 alpha, I stepped away (work, life, the usual reasons) and for the best part of a decade it wasn't mine to ship.
It didn't die, though, and that's almost entirely down to one person. Andrii Podanenko (podarok), backed by ITCare and the Open Y distribution, carried it through the Drupal 8 beta, the Drupal 10 port, and the start of the Drupal 11 line, essentially single-handedly, for years. Huge thanks to Andrii for looking after it all that time. I've picked the 4.1.x line back up alongside him, and 4.1.0 is the first release to come out of that.
read moreThis 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.
DrupalCon Rotterdam 2026 is going to be way more than just sessions and keynotes, it’s a chance to be part of what actually builds and improves Drupal.
Contribution Day is a part of DrupalCon, and in Rotterdam it will be on Thursday, 01 Oct. This is the heart of the event, where the global community comes together to make a real and concrete impact to the project.
If you’re planning your trip, we highly encourage you to stay for Thursday. It’s the most rewarding day of the conference. Whether you write code, improve documentation, help with UX, fix bugs, or support translations, there’s a place for every skill level.
And better still, you don’t need any prior contribution experience, just curiosity and willingness to get involved. You’ll be guided by experienced mentors, collaborate with many contributors from around the world, and leave with new connections, new skills and something meaningful you helped create.
If you've never contributed before, this is the perfect moment to start!
So, what are you waiting for?
Let’s do it!
Contribution Day in Rotterdam on 01 Oct.
By Scott Falconer, Product Lead, Outside AI
Where Drupal really stands with AI agents, where it has a right to win, and what we need to do next.
AI agents can build with almost anything. That is both great news and a problem for Drupal.
A person can ask an agent to recommend a platform, rebuild an existing site, create a content model, configure permissions, or change a running system. The agent then has to decide whether Drupal is a good path, reach it, understand it, act on it, and verify the result.
When that experience fails, we usually do not get a bug report. The agent works around Drupal, produces something that only looks finished, or quietly chooses another stack.
That makes agent experience a growth problem for Drupal, not just a developer-experience problem.
Drupal does not need to be the fastest way to generate any page. Drupal should be the safest, clearest way to a governed, inspectable, long-lived site - and agents should be able to use it effectively.
By governed, we mean the controls that make a site safe to run and hand off - a real content model, scoped roles and permissions, review and audit, safe rollback - not just quick to generate.
This is the purpose of Outside AI, the workstream the Drupal AI Initiative launched: making Drupal legible, callable, safe, and verifiable for agents and builder tools operating from the outside.
The distinction from Inside AI, in shorthand:
These are different experiences, but they need substantially the same foundation: clear state, stable interfaces, scoped identity, governed actions, and reliable verification. Wherever possible, that foundation should be built once in Drupal and shared by both.
Our goal is not to make Drupal better for agents instead of people. It is to make Drupal's existing strengths explicit enough that both agents and people can safely use them. If we are successful we will make Drupal's strengths visible and attainable - improvements that hold no matter which agent, model, or tooling wins.
Early measurements from the Drupal Agent Readiness Scorecard point to a tricky but useful conclusion: capability is becoming table stakes.
Our first-hour study drops a cold agent onto each platform with no prior setup and measures how fast and how reliably it can stand up a small but real structured, permissioned site. The bar: a content model, seeded content, a public page, a scoped editor role. Every milestone is confirmed by an independent HTTP probe, not the agent's own say-so. Agents cleared that bar on every platform we tested: Drupal CMS, bare Drupal core, WordPress, and a from-scratch Node app (each across multiple models and two agent families), plus single spot-check runs on Wagtail, Joomla, Strapi, and Payload.
The evidence is still early and deliberately narrow - and the scorecard is useful for direction, but "can an agent build with Drupal?" is no longer an open question.
The better questions: when should an agent choose Drupal, how far can it reliably get, and what is left after the agent is done?
Drupal has an advantage here. It was not designed for agents - but it was not luck, either.
For two decades, enterprise and community pressure forced Drupal to care about structured content, relationships, roles and permissions, editorial workflows, configuration management, APIs, and migration. Complex digital experiences demanded structure, governance, and safe ways to change things, so the community built them.
Those are exactly the things agents need: structured state they can inspect, explicit permissions they can reason about, actions with known boundaries, configuration they can hand off, and evidence that a change worked. The foundation was already here. AI is now revealing why it matters.
And agents do find it. In the study's Drupal runs, agents reached for native capabilities - content types, roles, permissions, Views, exported configuration - instead of bypassing Drupal with a static lookalike, and what they left behind was inspectable. That evidence is promising, but as Dries wrote about Drupal's role in agentic workflows, a head start is not a plan to win. What this post attempts to measure is where the head start is real, where it is not, and what we need to do to turn it into a win.
Drupal still makes agents work too hard to reach the advantage. Setup choices, authentication, module selection, stale assumptions, unclear action surfaces, and weak verification can consume the whole first session before Drupal's strengths become visible.
Agents do not reward us for architecture they never reach.
Drupal core, contrib, and products like Drupal CMS are best understood not just as software, but as an accumulation of hard-fought decisions by many dedicated individuals: core is the architectural commitments (structured content, revisions, granular permissions), contrib the solved problems (search, forms, spam, SEO), and a product like Drupal CMS the curation - which of those a serious site actually needs, working together from day one. That accumulated judgment is the real inheritance, and the hard part to reproduce on any stack.
What makes those decisions unusually legible, inspectable, and reusable - without reading the code that enforces them - is that Drupal represents most of them as structured configuration: data with a schema, exportable to files, reviewable as a diff, and inspectable on a running site. Content types and fields, role grants, Views, editorial workflows - they all live there. That standard is the point: Drupal gives decisions a common, inspectable place to live. On a from-scratch build there is no such defined place - a decision may sit in code, a migration, an ad-hoc config file, or only in someone's head. On some headless CMSs, even the access rules are code. Drupal keeps an unusually large share of the decision surface legible as data.
That is what a human actually inherits from an agent-built Drupal site: decisions they did not know to ask for, in a form they can inspect and safely change. An agent building from scratch gives you exactly what it thought of. An agent building on Drupal CMS hands you the community's accumulated judgment - core's architecture, contrib's solved problems, the product's curation - as artifacts you can review, compare, export or change through the admin UI or by applying a recipe, without a developer touching code. When we verified agent builds, we did not take the agent's summary - we read the configuration. Decisions-as-data is what made that possible: legible, deployable between environments of the same site, composable across sites as recipes, and checkable by someone who was not in the room.
This is where Drupal's advantage can also become fragile - a decision can be structured and still be lost, bypassed, or stripped of its rationale:
So "those decisions aren't lost" turns out to be an assumption, not a guarantee - in these tests, it did not hold on its own… but the answer is not to freeze the decisions: the agent acts for the user, and sometimes changing one is exactly right. In the intent experiments the rationale was in the site, and the agents even read it - it still never entered the change. Our bet is timing: move the reason to the moment - keep it attached to the work, and put it in front of the agent exactly when it is about to change what that reason protects. The agent may still make the change; sometimes it should, but it is a tradeoff the agent had the opportunity to evaluate with the right context at the right moment.
And the stakes are rarely one big decision. A long-lived site is changed by many actors over many years - people and agents, each change small on its own. No single lost decision reads as damage; the damage is the trajectory. Small silent losses compound, change after change, until the governed site someone carefully built has drifted into something nobody chose. The advantage accumulated one hard-fought decision at a time, and it erodes the same way - which is why the lever has to sit at the moment of change, the same granularity where the drift happens. The advantage is made of decisions, for as long as you can remember them.
The Playing to Win choice cascade rests on one premise: strategy is a choice.
A disposable landing page, a one-off prototype, or a deeply bespoke product where a CMS addresses only a small slice of the job may be better served by a different stack. Drupal does not need to win every prompt to win the work it is built for.
This is the practical consequence of the great CMS unbundling: AI commoditizes creation while raising the value of control - it lowers the cost of creation, not the cost of trust.
Drupal has a right to win when the result must remain understandable and operable after generation:
This territory is defined by the work, not the organization's size. A small nonprofit can need strong editorial governance. A large enterprise will often find a disposable microsite sufficient for the right use cases.
In the language of the cascade:
Drupal's historical adoption barrier is not that it is powerful. It is that reaching the power has usually required someone who already knows Drupal.
A committed Drupal agency invests through that friction because it knows what is on the other side. A WordPress shop that occasionally considers Drupal, a system integrator with many platforms to choose from, or a lean in-house team may not.
AI can lower the expertise barrier - but only if the results can be trusted.
If an agent can absorb more of the repeatable setup and assembly, while experts review the consequential architecture, business, and governance decisions, then Drupal expertise moves up the value stack. Talented people spend their time on customer experience, editorial strategy, integrations, and the decisions that actually differentiate the site.
Prove that path and the agency pitch changes from:
We can build this after a substantial discovery and setup phase.
to:
We have already built a governed starting position. Here is the architecture, what we learned from the source site, which Drupal decisions we inherited, what we verified, and where expert judgment is still required.
That is a stronger way to enter a rebuild conversation - and it is how Drupal becomes a realistic choice for teams that do not already have deep Drupal expertise in-house.
It is still a strategic bet. We have not demonstrated that better agent experience produces Drupal adoption at scale, and we should not claim the market outcome before we have proven the mechanism. We would know the bet was wrong if agents kept bypassing Drupal's native capabilities even when they were easy to reach, if inspectable artifacts did not measurably cut a second team's time to change a site safely, or if entry friction never fell far enough for Drupal to enter consideration at all.
Underneath the expertise barrier sits a second one: the environment. Local tooling for Drupal provides an excellent experience - DDEV can stand up a real site in minutes for someone who lives in a terminal. The same first-hour measurements ran on exactly that tooling, and even there, install weight - not capability - set the pace. And that is the expert path: it assumes a capable machine, a terminal, a container runtime, and the time to configure them. A growing share of first evaluations do not start there. They start on a phone, in a browser tab, or inside a chat window - often mediated by an agent that has no local machine at all.
No amount of polish can remove that local barrier. And to be clear, this is not a criticism of tools like DDEV - DDEV should remain the expert path. But if the only way to try Drupal is to install Drupal, we lose the people - and the agents - who were only willing to spend five curious minutes. We risk rejection before the first page is ever built.
That is why hosted try-and-build surfaces matter: places where someone who does not know or care about Drupal yet - or an agent acting on their behalf - can start a real site with nothing installed. Hosted trials, browser-based build environments, demo workflows, commercial platform starters, and one-click hosting paths each attack that floor from a different angle. And each has a natural graduation path: a trial becomes a real site, and a real site launches onto hosted platforms as it grows. The front door feeds the installed base.
This is also where the community structure of the Drupal AI initiative becomes its advantage. No single on-ramp will fit every user, and each provider brings its own vision, market, and opinions - a browser trial optimizes for the five-curious-minutes case, a demo workflow for build-something-real, a commercial platform for launch-and-scale. That plurality is a strength, on one condition: the Drupal underneath must be the same agent-ready Drupal everywhere - the same state introspection, the same governed actions, the same verification. Providers should compete on experience and opinion, not re-invent the substrate.
The standard: someone who has never heard of PHP or SQL - or an agent with no machine at all - can go from curiosity to a real, governed Drupal site in one session, and graduate that site to production hosting without starting over.
From here the essay turns into inside baseball: issue by issue, for the people working with Drupal every day. If that is not you, feel free to skim, or skip to the closing.
The Outside AI roadmap follows the journey an external agent has to complete - the same path Dries has sketched, from setup to connection, context, governed action, validation, recovery, and launch. These five stages assume Drupal is already in the running; getting there - an agent discovering Drupal, recognizing the task fits its territory, and reaching a starting surface before any Drupal site exists - is stage zero, and it is what the front door and self-description work above are for. In the below, we focus on what we should be able to say, with evidence, before calling it done. And wherever external tooling has to keep explaining the same Drupal quirk to an agent, that quirk is a roadmap item: the workaround is the requirements document.
An agent needs supported ways into Drupal and a scoped, auditable identity - and there is still a lot to decide in what that identity can be. An agent can act as a delegate, carrying a scoped slice of the authority of the person it works for. Or it can act as an independent, non-human account with grants of its own - a principal actor. These are two different models of what an agent is, with different strengths: delegation cannot exceed the person it acts for, which keeps the blast radius small and the audit trail human-shaped; an independent identity can carry work no single person's permissions cover, like scheduled maintenance or operations across many sites.
Drupal should not pick the winner. Products, hosts, and teams will choose differently - reasonably - and the same site may run both. From the substrate's side, the fork matters less than it looks: both models need the same structure - a grant that is scoped, an action that is attributed, a denial that is auditable. Build those once and either model, or both at once, can run on top.
The mechanics are arriving. The core CLI entry point (vendor/bin/dr) landed in Drupal 11.4. Work on the execution principal, OAuth behavior, and MCP scope enforcement continues across the initiative: the execution-principal plan, OAuth identity work in Simple OAuth, and scope handling in the MCP Server module. No single entry point serves every environment: dr is a local and server transport, while a remote agent needs authenticated HTTP or MCP. What has to stay constant is the contract - the same action, authorization, and receipt model, reachable through the right transport for each.
The standard: given an agent operating under a scoped grant - delegated from a person or issued to a non-human identity - when it attempts an allowed action, the action succeeds and is recorded against an execution principal that names both the initiator and the executor. When it attempts an action beyond that grant, it fails clearly, safely, and with an auditable reason.
The agent should not have to guess what Drupal or the running site can tell it. We need supported, machine-readable inventory, site structure, API and schema fidelity, path ownership, available actions, and current constraints.
The standard: given a running Drupal site, when an agent requests site context, it can discover content types, fields, roles, permissions, workflows, path ownership, enabled extensions, available actions, and relevant constraints - without scraping the UI or guessing from routes.
Agents need typed inputs, predictable errors, least-privilege execution, approval boundaries, and results another system can inspect.
This fundamental is one Drupal's entity layer already demonstrates: authorization attaches to the operation, not the entry point. An editor does not write to the database - they work through forms their permissions allow, and when a change goes through the Entity API, the same permission and entity-access checks fire whether it arrived from the admin UI or the API. For agents, that is the right foundation: no separate "agent mode" to secure - a new caller walks through a new door and hits the same wall. It is not yet universal: some checks still live at the door, and the command line has historically carried implicit authority - which is exactly why the execution-principal work in stage one matters. Part of the roadmap is making the fundamental universal, not inventing it.
What is missing is declaration, not governance. Entity CRUD is well covered - JSON:API exposes entities as resources under the same policies. But the operations beyond CRUD - clear a cache, apply a recipe, run a migration, reindex search - are scattered across admin forms, Drush commands, and one-off endpoints, each with its own shape. An agent cannot reliably discover what operations exist, what they require, or what they return; efforts like the Tool API and tool declaration introspection are working toward that declared catalog. The requirement is the fundamental, not any one module: one action model, many doors - typed inputs, the same authorization, and a structured receipt from every transport. A receipt, though, is still a claim - judging it is the next stage's job.
The standard: given one declared site action, when an agent calls it through any supported action adapter - CLI, MCP, ECA, or Drupal's AI systems - its typed inputs, authorization, errors, and result receipts behave consistently. Where an operation is entity CRUD through JSON:API, the same identity and authorization policies apply.
The agent's own summary should not be held as proof - we would never expect a human to be the ideal judge of their own work. What matters is what the site actually shows. That is not a new problem: Drupal has always worked on it, because Drupal was never just for managing content - it manages how a team works together. Work does not count until someone else - or a system-enforced guardrail - says it does: drafts, moderation states, revision history with rollback, a permission model where the author does not have to be the approver. An agent is the newest actor in that system: it proposes within its permissions, the workflow gates what counts as done, a different actor approves, and revisions makes it reversible.
That machinery is fundamental to Drupal for content. For code and configuration, teams already have a mature review lane too - it just lives outside Drupal, in version control. And Drupal is unusually well placed to use it: because configuration exports to files, a config change can ride the same discipline as code - a diff, a pull request, a reviewer, CI, a revert. That is decisions-as-data paying off; most platforms cannot put their settings in a code review at all. An agent that works like a developer - building locally, exporting configuration, committing - inherits all of it.
The live site is the harder case, and not just for agents: a person doing site-building on production creates the same risk. Teams manage it by deciding where each kind of change is allowed to happen. Content is edited live, because live content has mechanisms for review. Structure is built in a development copy and flows to production through configuration import - so a config change made directly on production is temporary, and the next deployment erases it; some teams block live config edits outright. Giving an agent the same working agreement needs nothing new: a role that edits content on production, a freer hand in a development copy, the config path in between.
Two things are new though, and as a result they are the roadmap. First, the working agreement has to be explicit. Teams usually write it down for people - onboarding docs, locked-down production, review - but with agents, every session can be somebody's first day on the site, so anything left as "on the job" knowledge repeatedly fails fast. The boundary has to be stated by the site, and feedback given when it is enforced; the explicitness a cold agent needs is the same explicitness that protects a new hire.
Second, speed and scale. Where a team produced a handful of reviewable changes a day, agents can produce thousands. Human review alone does not survive that volume. Independent, automated verification has to absorb it - machine checks covering the routine, so human attention lands on the judgment calls. AI observability can trace requests through standard logging and telemetry, but tracing a request is not the same as independently verifying a change or rolling it back; the checking itself has to become machinery.
Our work is to extend the team discipline Drupal already applies to content - draft, review, approve, revert - to every surface an agent can change, at a speed and scale no site team has faced before.
The standard: given a change the agent claims is complete, when an independent process inspects the site, it can confirm what changed, show which content, configuration, code, or workflow surface was touched, report whether verification passed, and provide a preview, rollback, or recovery path.
The same governed path has to support a real way onto Drupal and a real handoff toward production. That includes source audits and discovery, content and pattern mapping, Drupal-native architecture advice, redirects, Canvas and configuration integrity, parity evidence, editorial review, and an explicit boundary between structured Migrate API work and agent-led re-architecture.
Issues such as Canvas configuration data integrity and reconciling updates to already-imported default content are part of this path even though they do not carry an "AI" label.
The standard: given a real source site, when an agent proposes or builds a Drupal replacement, the handoff includes source-site findings, mapped content and patterns, Drupal-native architecture, parity evidence, unresolved gaps, and a clear line where human judgment is required before launch.
Measurement is the spine across all five. The Drupal Agent Readiness Scorecard exists to tell us whether Drupal improved while the workflow held steady - separately from the normal improvement of the models themselves.
The Rotterdam plan - the proof we are aiming to have ready by DrupalCon Rotterdam - is intentionally narrow: one real rebuild of an existing non-Drupal site into Drupal CMS. The question it answers is precise: can an outside operator turn a real non-Drupal site into a defensible Drupal starting position, with independently reviewable evidence?
The bar we’re setting is not, are we "ready to launch.", it is "is this defensible enough to continue?"
One successful build would demonstrate a viable path in that case. A second site with a second operator would begin to test repeatability. Neither would prove that the market has moved - and we should not claim otherwise.
The question then is what remains after the agent is done. A clear test is: give the finished build to a fresh person or agent with none of the original context, and ask them to make a consequential change safely - add an editorial role, alter a workflow without weakening access, explain why the architecture is what it is, recover from a deliberately broken change - while we measure time-to-understand, mistakes, expert intervention, and whether the site's own state carried the reasoning. That tests "decisions as data" far more directly than a second build.
Drupal already has much of what builders need for serious sites. Again, that is the good news.
But the bad news is that potential has little value if agents reject Drupal before reaching it.
We should be careful not to declare victory because Drupal has structured content, permissions, workflows, and configuration management - The work that remains is to turn those properties into a clear, measurable advantage: make Drupal easy enough to choose, explicit enough to understand, safe enough to change, and verifiable enough to trust.
Outside AI needs real workflows more than speculative feature lists. If you are using an external agent to build with Drupal, calling Drupal from another system, or encountering friction anywhere from setup through launch, bring us the real task.
A use case, failed run, repeated workaround, missing capability, or existing issue is enough; you do not need to arrive with a solution or even know where the work belongs. Add it to the Outside AI meta issue or bring it to the #ai-initiative channel in Drupal Slack. We will help reproduce it, map it to the agent journey, connect it with the right maintainers and implementation work, and determine whether it belongs in the scorecard.
If you maintain a project agents need to use, tell us what they repeatedly misunderstand or work around. Those workarounds are requirements documents.
Drupal's earned advantage gives us the right to play. What we build, and what we prove next, determines whether we win.
Evidence note: the measurements described here are early and deliberately narrow; several are exploratory rather than claim-grade. The scorecard work publishes fixed tasks, retained failures and nulls, explicit evidence boundaries, and paired pre/post results before claiming that Drupal itself improved.
By Christoph Breidert, Product Lead, Inside AI
A year into the Drupal AI Initiative, AI inside of Drupal has a clear goal for the months ahead. At DrupalCon Rotterdam at the end of September, we want to show a single Drupal site where AI Search, an AI chatbot, AI content review, and AI translation all work together on real, multilingual content, with observability and security running underneath. The idea is simple: rather than describe these features one by one, let people see them working together on one site.
This post is about how we plan to get there, what our partners told us to build, and the team we are putting together to build it.
If you are new to the split, the Drupal AI Initiative now runs in two streams. “Inside AI” is AI inside Drupal, for the people using it. “Outside AI” is AI outside Drupal, acting on it through external agents. The simplest way to hold them apart is this: with Inside AI a person uses Drupal and Drupal uses AI to help; with Outside AI a person uses an agent and the agent uses Drupal. We introduced the two streams in an earlier post, and the distributed leadership structure behind them shortly after. This post is about the AI functionality we are building inside Drupal. Outside AI, led by Scott Falconer, will get its own update, and Dries Buytaert has already written about why that stream matters.
Here is something we have not shared publicly before. We asked our Drupal AI Partners, the organizations that fund and staff this initiative, which features they most want us to build inside Drupal. The results were clear.
Search was the standout. The next four clustered closely together, which tells us there is no single second priority so much as a group of capabilities people want in roughly equal measure. This shapes what we prioritize. Drupal AI is funded by our partners, therefore we build what they asked for, in the order they asked for it, against the public 2026 roadmap already in flight.
Two of these deserve a word. We have already been building chat-driven content editing in Canvas AI, and that work continues. Bulk content updates we are not tackling as a standalone feature yet, but it belongs naturally with content review. Once you can review a large body of content with AI, the obvious next step is letting AI help you act on what it found, so for now it lives within the content review work rather than as a separate capability.
What matters most to anyone building with Drupal AI is shippable features. The demo is how we prove they are ready, by showing each one working on a real site rather than only in isolation. That is why the demo is the most important thing we are building this year: it turns a list of capabilities into features our partners can put in front of their own clients. The two are not separate efforts. The recipes and configurations that make a feature work in the demo are largely the same ones that make it adoptable on a real project, so building the demo is how shippability becomes visible.
This is also why we are putting real effort into engaging, realistic demo content, a site with enough depth that the AI has something meaningful to search, review, and translate. The goal is for anyone to try it out with a single click and see for themselves how a fully AI-powered CMS behaves.
AI Search in Drupal
Search is a natural place to begin, since it was the most requested feature. Picture a search that returns an AI-generated summary, the sources behind it, and the ranked results below, the way modern web search now works, but over your own site's content.
Search sits alongside the other capabilities, and each carries real weight in the demo. A chatbot drawing on the same retrieval foundation. Content review that scores a page against criteria like brand, legal, and reading level and suggests concrete fixes. Translation that moves content across languages with quality worth presenting. And underneath it all, the observability and security layers that make the experience credible for production rather than a set of features that only hold up one at a time.
This is worth setting out clearly, because it changes what leading one of these areas involves. Most of these features already work today. The gap is usually not the core capability. The gap is that we have not yet shipped the recipes and demo configurations that make them work end to end, with results we are happy to show, on one realistic site.
This is the classic "it works" problem. Yes, it works in isolation. Making it work completely, convincingly, and repeatedly in a demo is a different kind of effort. So the leadership across these areas comes in two shapes. Some of it is making it work in the demo, building the recipe, wiring it to real content, and tuning prompts and results until the output is good enough to present. Some of it is net-new implementation, where the capability still needs to be built or substantially extended. Both are genuine leadership, and we are clear with anyone stepping in about which kind of work their area involves.
None of this happens without the hard work of our contributors. To strengthen our governance model, we have chosen to place responsibility for each area in the hands of a dedicated lead, someone who owns its direction and keeps a clear, public backlog for contributors to work from. The sprints themselves do not change. What changes is that every area now has a clear owner, and together these leads form the Inside AI leadership team.
Workflow Drupal AI Leads
Here is where each Inside AI area stands today.
| Area | What the lead work involves |
Lead and status |
| Demo |
Building the installation, recipes, and content so every feature works together |
Aidan Foster |
|
AI Search |
Mostly making it work in the demo, plus the search results experience |
Abhisek Mazumdar and Laurens Van Damme |
| AI Content Review | Mostly net-new implementation | Open |
| AI Translation | Mostly making it work in the demo | Sven Decabooter and Valery Lourie |
| AI Chatbot | Mixed, demo configuration and some surface implementation | Open |
| Observability | A demo backend over the telemetry export | Open |
| Security and guardrails | Packaging guardrails and usage metrics into the demo | Open |
|
Canvas AI |
Ownership first, then scope |
Akhil Babu |
| AI Context | Context management that feeds reliable site information to every AI feature | Kristen Pol |
Two things are worth making explicit, because they shape whether you picture yourself in that table.
First, a name beside an area does not mean you cannot join this focus area. The opposite is true. We are looking for strong teams rather than single owners, so contributing to an area that already has a lead is as real an opportunity as taking on one that is open.
Second, there is no formal application process. Becoming a lead happens through the work itself. A lead prepares issues and keeps the backlog in good shape. Our delivery managers, Arian Raeesi and Vidit Anjaria, plan those issues into the sprints. Some go through joint grooming with the technical leads, Marcus Johansson and Artem Dmitriiev, to check they fit the architecture, and I stay involved as product lead to keep them aligned with the overall product direction.
If one of these areas interests you, reach out in the #ai-initiative channel on Drupal Slack, or to any of us directly, and begin. Taking on that responsibility is what makes you a lead, and it is how you join the Inside AI leadership team.
This is where AI inside Drupal stands today. We know what our partners want, because we asked. We know where we want to show it working, at Rotterdam, on one site. And we know the only way to get there is together, with a team that owns each part of it.
If you have read this far, there is a good chance one of these areas already appeals to you. Come and say so in the #ai-initiative channel on Drupal Slack, or explore becoming a Drupal AI Partner. The demo will be better with your help, and so will Drupal.
The Drupal project runs one of the most disciplined coordinated-disclosure programs in open source, and it has done so through volunteer effort for more than two decades. Millions of sites, many operated by governments, universities, and enterprises, depend on it.
This post is the first in a series stemming from the Drupal AI Security Initiative. Before I dive into how it's organized and what we've found, I wanted to share a post about how Drupal Security Team already works, because the initiative is built to supplement that foundation, not to repair or replace it. Note: this post assumes you are familiar with coordinated disclosure, CVEs, and severity scoring in general and focuses on what Drupal specifically does.
Coordinated disclosure, on a fixed cadence
Reports arrive in a private queue. A Security Team member takes triage duty on a two-week rotation, confirming whether a report is a real, in-scope vulnerability. Once validated, the affected project's maintainer and the original reporter collaborate in the confidential issue where the fix is written, reviewed, and scheduled. All of this stays out of public view until the fix and security advisory are ready on a release day.
Drupal has a predictable release cadence: advisories publish on Wednesdays, with a Public Service Announcement the Monday before on the very rare occasion a highly critical release warrants advance warning.
Scoring and identifiers
Every advisory carries a risk score using a system rating each issue 0–25 across six factors (access complexity, privilege required, confidentiality and integrity impact, exploit availability, and target distribution) mapped to labels from Not Critical to Highly Critical. Drupal's risk system was developed based on the NIST Common Misuse Scoring System. The project is now considering moving to CVSS, a more widely adopted standard. Drupal is also a CVE Numbering Authority, so it assigns its own CVEs: a level of formality most community projects don't reach. Summary data about the security track record is public with full details available as a series of posts or a JSON API with data going back to 2006.
What’s public and what stays private
The line between disclosure and discretion is drawn sharply. After release, advisories include all necessary details: affected project, severity, vulnerability type, affected versions, remediation, any possible mitigating factors, and CVE. Before release, the member disclosure policy permits a trusted insider to share only what is already public plus the bare numeric severity, never the affected project, the nature of the bug, or how to mitigate it. Members can't even let an employer market the fact that an employee had early knowledge.
Protection at the network layer
To protect site owners in the window between disclosure and patching, the Security Team and the Drupal Association offer Drupal Steward. Drupal Steward is a web application firewall (WAF) where Drupal Association engineers work with the engineers who wrote the security advisory to develop a rule that blocks the exploit at the request layer that goes live the moment the advisory does. This provides a virtual patch for highly critical, mass-exploitable bugs, but is not a replacement for patching.
The coverage model and its scope
Scope is defined just as clearly. Advisories cover Drupal core, plus contributed projects hosted on Drupal.org that opt into coverage (marked with a shield icon), and only for stable releases. Some things are deliberately out of scope: external libraries a module depends on and bugs requiring high-level administrative permissions. When a maintainer is unreachable, the team can mark a project unsupported.
By design the team is largely reactive: it responds to reports rather than continuously auditing Drupal core and tens of thousands of contributed modules. Members are asked for a few hours a month, a valuable contribution from highly skilled and in-demand individuals. The process is solid, but bandwidth has always been the primary bottleneck.
Scaling our response in the AI Era
Addressing that bottleneck is the whole point of this effort. It's also the founding premise of Alpha-Omega's Security Engineers in Residence program funding: that threat volume and pace are outrunning what volunteer hours can cover. AI has lowered the cost of finding and exploiting vulnerabilities. It enables high-volume report generation and can infer what a quietly worded commit was really fixing. A security process built around scarce attention and a modest head start now faces adversaries operating at machine speed.
Drupal’s security workflows are mature, documented, and trusted. The challenge now is scaling Drupal’s defensive bandwidth and throughput to match that offensive speed. That's what the Drupal AI Security Initiative adds, and it's the subject of the next post in this series.
If you'd like to help in the meantime, the most valuable things any contributor can do are what the team has always relied on: write secure code, report issues responsibly, and, if you have a track record in the community, consider joining the Security Team.
Tiffany Farriss authored this post and is responsible for its content. Members of the Drupal AI Security Initiative (Greg Knaddison, Tim Lehnen, and Drew Webber) and George DeMet contributed context, editing, and review. AI tools (Claude by Anthropic and Gemini by Google) assisted with research, organization, and editing. All facts were verified by humans against primary sources.
