Earlier this week, in "Drupal's role in agentic workflows", I argued that Drupal's AI future has two parts: helping people with AI inside Drupal, and helping agents use Drupal from the outside.
So we are splitting Drupal's AI strategy into two workstreams. Inside AI is led by Christoph Breidert, who has been driving that work already. Outside AI, the new workstream, is led by Scott Falconer.
The easiest way to think about the difference: 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 launched the Drupal AI Initiative one year ago, in June 2025, with a published strategy. A year later it spans 32 organizations and more than 50 contributors, shipping against a public 2026 roadmap through two paid delivery teams.
So far, most of that work has focused on Inside AI, though much of the foundation also supports Outside AI.
Outside AI will serve three kinds of users:
If we are successful, agents will recommend Drupal to new users, help Drupal developers move faster, help agencies win more work, and use Drupal as the trusted layer for content management and governance.
Thank you to everyone who helped bring the Drupal AI Initiative to this point. Together, the community has turned an ambitious idea into real momentum.
I'm excited about what comes next! Want to get involved? Join the #ai-initiative channel on Drupal Slack.
read moreBy the Drupal AI Initiative
A year ago, we launched the Drupal AI Initiative with a published strategy and a bet that AI would matter enormously to Drupal's future. Today the initiative spans 32 organizations and more than 50 contributors, shipping against a public 2026 roadmap.
As the work has grown, it's become clear that our AI strategy needs to cover two distinct areas. While innovation and product development remain core goals across everything we do, we are organizing our day-to-day execution into two workstreams: Inside AI, led by Christoph Breidert, and Outside AI, a new stream led by Scott Falconer.
The unified AI initiative leadership team - made up of the existing initiative members - will continue to shape our overarching roadmap, while Christoph and Scott ensure that vision is executed. We will outline this leadership team and other key supporting roles in an upcoming post.
The core difference: Inside AI brings AI tools into the Drupal interface to assist the people using it. Outside AI makes Drupal the platform external AI agents reach for and act on. Dries Buytaert recently published an article on Launching Drupal's Outside AI workstream.
Inside AI is AI inside Drupal, for the people using it: assistants, in-product workflows, page-building, and the rest of the user-facing surface. This is the work the initiative has been driving for the past year, and it continues against the 2026 roadmap already in flight.
Outside AI is AI outside Drupal, acting on Drupal. A person, agency, host, or developer is using an external agent or builder tool, and that agent needs to start with Drupal, connect to Drupal, inspect Drupal, change Drupal, verify Drupal, migrate into Drupal, or launch Drupal.
You'll see public roadmaps from both streams. Inside AI continues against its existing 2026 roadmap; Outside AI will publish its own outcomes and milestones, with a first proof of direction targeted for DrupalCon Rotterdam. Where both streams need the same capability, the answer is usually one shared Drupal contribution, not two parallel builds.
The initiative is open, and both streams need contributors - whether you write code, test against real agent workflows, work on documentation, or bring a use case from your own agency or organization.
Not sure where to start? Come say hello in Slack and we'll help you find a first contribution.
By the Drupal AI Initiative
A year ago, we launched the Drupal AI Initiative with a published strategy and a bet that AI would matter enormously to Drupal's future. Today the initiative spans 32 organizations and more than 50 contributors, shipping against a public 2026 roadmap.
As the work has grown, it's become clear that our AI strategy needs to cover two distinct areas. While innovation and product development remain core goals across everything we do, we are organizing our day-to-day execution into two workstreams: Inside AI, led by Christoph Breidert, and Outside AI, a new stream led by Scott Falconer.
The unified AI initiative leadership team - made up of the existing initiative members - will continue to shape our overarching roadmap, while Christoph and Scott ensure that vision is executed. We will outline this leadership team and other key supporting roles in an upcoming post.
The core difference: Inside AI brings AI tools into the Drupal interface to assist the people using it. Outside AI makes Drupal the platform external AI agents reach for and act on.
Inside AI is AI inside Drupal, for the people using it: assistants, in-product workflows, page-building, and the rest of the user-facing surface. This is the work the initiative has been driving for the past year, and it continues against the 2026 roadmap already in flight.
Outside AI is AI outside Drupal, acting on Drupal. A person, agency, host, or developer is using an external agent or builder tool, and that agent needs to start with Drupal, connect to Drupal, inspect Drupal, change Drupal, verify Drupal, migrate into Drupal, or launch Drupal.
You'll see public roadmaps from both streams. Inside AI continues against its existing 2026 roadmap; Outside AI will publish its own outcomes and milestones, with a first proof of direction targeted for DrupalCon Rotterdam. Where both streams need the same capability, the answer is usually one shared Drupal contribution, not two parallel builds.
The initiative is open, and both streams need contributors - whether you write code, test against real agent workflows, work on documentation, or bring a use case from your own agency or organization.
Not sure where to start? Come say hello in Slack and we'll help you find a first contribution.
When a CMS is too hard to use, teams paste text into graphics and upload them as images. The page looks right - but search engines and AI answer engines cannot read that content at all.
See what image-based content costs you in SEO, GEO, accessibility, and day-to-day management - and how structured Drupal components fix it page by page.
read moreECA, FlowDrop, and Maestro all draw boxes and connect them with arrows, so people keep asking whether three Drupal workflow modules means a split community. Not quite. Dries Buytaert, Randy Kolenko, Shibin Das, and I are writing a shared orchestration design spec, disagreeing productively in writing. One axis explains all three: how much state a run carries. ECA reacts statelessly to any Drupal event across the whole request surface. Maestro holds a durable process that can wait days for human approval. FlowDrop spans the axis with a typed, inspectable dataflow graph that runs sync, async, or stateful from one definition, and Shibin is refining it toward strictly serializable data, ideal for building complex AI agents. Nothing is frozen. The word "orchestration" itself is contested in the spec glossary. Composition already ships: maestro_eca_task lets a Maestro process hand off to ECA. The bigger vision, ECA reacting to content, calling a FlowDrop AI flow, then routing through Maestro for human approval, is a picture we are building toward, not a release. But bridges are the start, not the finish. The real work is building a shared foundation, common primitives and APIs so the three tools stop reinventing the same concepts under different names. The spec's vocabulary synthesis shows the embarrassing similarity: Trigger, Step, Condition, Workflow, Run. The keystone is a defined contract for handing data between steps and between tools, one that works beyond Drupal's border for AI agents and external systems. Three tools is the right number because the stateless-reactive and instance-stateful ends pull architectures in opposite directions. Specialization beats a mediocre merger.
If your CMS needs a two-hour training session before anyone can use it, the CMS has a UX problem. The fix is not better training. It is a system that doesn't need any.
See the Drupal admin UX patterns, staging-first handover approach, and how Edenred Polska's marketing team started building production pages with no formal training at all.
read moreAt Tag1, we believe in proving AI within our own work before recommending it to clients. This post is part of our AI Applied content series, where team members share real stories of how they're using Artificial Intelligence and the insights and lessons they learn along the way. Here, Dénes Szabó (Drupal Developer) built LinkStash, a production-ready Drupal 11 bookmarking module, in one weekend using Claude Sonnet 4.5.
You know the feeling. It's Tuesday afternoon, you have 47 browser tabs open across three different browsers, and somewhere in that digital haystack is that one article you absolutely need to reference. Chrome has the documentation you bookmarked last week. Firefox has the GitHub issues you were reviewing. Safari has... honestly, you can't remember what Safari has anymore. Your browser's "Reading List" feature is laughing at you. Your bookmarks folder looks like a digital hoarder's attic. And don't even get started on those "bookmark this page to read later" services that require uploading all your data to someone else's server.
As a Drupal developer, I looked at this chaos and thought: "I could fix this. I have the technology. I have the skills. I have... absolutely no time to actually build it because I'm too busy managing 47 browser tabs."
So naturally, I decided to see if AI could help me build it in a weekend instead.
The goal was ambitious but clear: build LinkStash, a personal bookmarking tool, as a production-ready Drupal 11 contrib module suitable for release on drupal.org. Not a prototype. Not a proof-of-concept. A real, tested, documented, standards-compliant module that follows all of Drupal's best practices and passes the strict quality requirements for the official repository.
The feature list was substantial: entity system with full CRUD operations, browser bookmarklet for one-click saving, automatic metadata fetching with SSRF protection, smart domain-based auto-categorization, video embed support for YouTube and Facebook, Views integration with filters, 100% PHPCS compliance, PHPStan Level 1 static analysis, and a full test suite. Oh, and proper documentation including README, CHANGELOG, and API docs.
You know, just a light weekend project. What could possibly go wrong?
Here's where it gets interesting. Everyone assumes you need the biggest, most powerful AI model for serious development work. But I deliberately chose Claude Sonnet 4.5 instead of Opus, and here's why: it's way cheaper, significantly faster, and (here's the kicker) equally clever for code generation.
For structured development tasks with clear requirements, Sonnet 4.5 absolutely shines. It understands Drupal architecture, follows coding standards precisely, writes comprehensive tests, and generates production-quality code. The speed difference is noticeable: responses come back in seconds instead of tens of seconds. When you're iterating on test failures or fixing PHPCS violations, that speed compounds into serious time savings.
The cost difference? Even more dramatic. We're talking roughly one-fifth the cost per token. Over the course of building LinkStash, which consumed an estimated 200-250K tokens across multiple development sessions, Sonnet 4.5 probably cost around $3-$5 total.
That's less than a fancy coffee, for a complete, production-ready Drupal module. Let that sink in.
AI didn't build this module alone. This was a collaboration, and understanding the dynamics matters.
What AI did (the heavy lifting):
What I did (the professional supervision):
The most surprising part wasn't what went smoothly; it was where AI stumbled and needed human expertise.
The constant mystery. AI kept trying to use EntityStorageInterface::SAVED_NEW, but that constant doesn't live in that interface. It's a global constant in core/includes/common.inc. I had to explicitly correct this: "This constant does not exist in this interface. It's defined in common.inc. Fix it." The AI course-corrected immediately.
The access control saga. All seven access tests were failing despite correct permissions and entity ownership. AI tried using AccessResult::allowedIf(), which should work, but didn't in Drupal 11's kernel test environment. After systematic debugging, I suggested trying explicit conditionals instead. That fixed it instantly; it was a behavioral quirk AI wouldn't have discovered alone.
The vocabulary ID confusion. Tests were creating a tags vocabulary, but the actual config created linkstash_tags. AI confidently wrote tests that failed due to this mismatch. Human pattern recognition caught it: "You're testing against the wrong vocabulary ID."
The YouTube ID format. AI used 3-character test IDs (abc, xyz), but YouTube video IDs are exactly 11 characters using base64url encoding. The regex pattern [a-zA-Z0-9_-]{11} doesn't lie. Once I pointed out that YouTube IDs are standardized at 11 characters, AI immediately generated valid test data.
These weren't AI failures; they were collaboration points. AI had the speed to generate code and tests. I had the domain expertise to catch subtle Drupal-specific issues. Together, we debugged faster than either of us could alone.
The numbers are worth a look:
Here's what "one weekend" actually delivered:
The security model deserves a callout: SSRF protection blocks private IP ranges, local thumbnail storage prevents IP leaking, and all data is isolated per user. All three plugin systems are also fully extensible, other developers can add custom content fetchers, categorization rules, and media providers. The module ships with sensible defaults but is built for extension.
Could I have built this solo in a weekend without AI? Absolutely not. The test suite alone would have taken days. Could AI have built this without supervision? Also no. Those subtle Drupal-specific issues required experienced judgment calls.
But together? We shipped a release-ready beta in 48 hours.
Let's break down the economics.
Time investment:
Token usage:
progress.md):
Actual costs (Claude Sonnet 4.5 pricing):
Traditional development cost (rough estimate):
The AI-assisted approach wasn't just faster; it was two to three orders of magnitude cheaper while maintaining professional quality standards.
Building v1 in a weekend was exhilarating, but it's just the beginning. The roadmap has two more phases.
Phase v2 (enhanced features):
Phase v3 (advanced capabilities):
The best part? Now that the architecture is solid and the plugin systems are proven, adding these features becomes incremental. Each new feature is just another plugin implementation or service extension. The hard architectural work is done.
Nobody warns you that AI-assisted development is fun.
There's something magical about describing what you want, for example, "Now we need a plugin system for content fetchers that can pull metadata from any URL with SSRF protection," and watching structured, working code appear in seconds. Then catching a subtle bug, pointing it out, and watching the immediate course correction. It feels less like programming and more like conducting. You're directing the architecture and reviewing the output, not typing every curly brace.
The debugging sessions were particularly entertaining. When all seven access tests failed, AI and I became detective partners:
Me: "Add debug assertions before the access check. Let's see if the user actually has permissions."
AI: Adds assertions. "Okay, permissions confirmed. User owns the entity too."
Me: "So why is
AccessResult::allowedIf()not working?"AI: "Let me try explicit conditionals instead..."
Me: "That... actually fixed all seven tests. Interesting."
That back-and-forth, that collaborative debugging energy, reminded me of pair programming with a really fast typist who never gets tired but occasionally needs you to remember obscure Drupal API behaviors.
The satisfaction of running ddev composer run-tests and seeing "187 tests, 846 assertions, OK" flash green? That hit the same way shipping your first module to production does. Except this time, we'd done it in a weekend instead of a month.
If there's one takeaway from this experiment, it's this: AI is an amplifier, not a replacement.
I couldn't have built LinkStash in a weekend alone. But AI couldn't have built it without me either, not to production quality, not with proper security considerations, not with the architectural decisions that make it extensible and maintainable.
What AI gave me was force multiplication. Instead of typing boilerplate entity code, I specified requirements and reviewed output. Instead of writing 187 tests manually, I described what needed testing and verified the results. Instead of formatting documentation, I outlined structure and AI filled in details.
I stayed in the driver's seat for architecture, security, and critical decisions. AI handled the mechanical work of code generation, test writing, and standards compliance. Together, we shipped something neither of us could have done alone in the same timeframe.
And honestly? For a problem that's been in the back of my mind for months, "I really need a better bookmarking solution," going from idea to a release-ready beta in one weekend feels like the future.
Now if you'll excuse me, I need to actually use LinkStash to bookmark all the tabs I've accumulated while writing this blog post. The irony is not lost on me.
LinkStash is available at drupal.org/project/linkstash. Built with Claude Sonnet 4.5 via Claude Code. Source code, documentation, and contribution guidelines are available in the project repository.
Development metrics: 1 weekend, ~15 human hours, ~240K AI tokens, $3-5 compute cost, 8,000+ lines of code, 187 tests, 0 PHPCS violations, live on drupal.org.
If you're weighing whether AI can carry real weight on your next Drupal contrib module, or you want to talk through where human oversight still has to stay in the loop, let's start a conversation! We'd love to hear from you.
This post is part of Tag1’s AI Applied content series, where we share how we're using AI inside our own work before bringing it to clients. Our goal is to be transparent about what works, what doesn’t, and what we're still figuring out, so that together, we can build a more practical, responsible path for AI adoption.
Image by Mahmoud Ramadan from pexels
The real deliverable of a component-based CMS is not the paragraphs. It is the moment your client stops asking for "a new page" and starts asking for "a new component."
See the four phases of the component mindset shift, what changes in the agency relationship, and how Edenred Polska went from planning to abandon Drupal to commissioning new components on a regular basis.
read moreNot every login wall is an intranet. Often the people you most want to serve privately are clients, partners, and sales agents - not employees.
Learn how to architect a Drupal extranet with gated content, per-user dashboards, role-based access, and the security, caching, and SEO decisions that keep partner data private.
read moreCritical security vulnerabilities don't wait for a convenient time. They arrive on their own schedule, and how quickly your team responds can mean the difference between a routine update and a serious exposure.
On May 18, the Drupal Security Team issued PSA-2026-05-18, a pre-announcement for a highly critical security release affecting every supported branch of Drupal core. The advisory scored a 20 out of 25 on the security risk scale. No authentication required, no special access needed. The release window was two days later, on May 20, between 17:00 and 21:00 UTC.
The Drupal Security Team urged site owners to reserve time for immediate updates because exploits could be developed within hours or days. They took the unusual step of providing best-effort patch files even for end-of-life versions of Drupal 8 and 9 because the potential impact was that significant.
If you're running a site that processes orders and manages customer data, you can’t put something like this off until the next sprint.
When the pre-announcement landed, we reached out to all of our support clients and worked directly with their teams to determine priority, assess whether the vulnerability applied to each site's specific configuration, and plan accordingly.
Read more read more
You can build a beautiful paragraph system and still watch it fall apart the first time an editor stacks two white sections together. Spacing is the detail that quietly decides whether a component-based layout feels polished or broken.
Compare three approaches to Drupal Paragraphs spacing, see a concrete Twig and CSS implementation with margin and padding controls, and learn which real-world scenarios editors run into on production sites.
read moreHelping your website content be found, shared, and understood clearly and responsibly.
When you publish website content, the work does not stop at the page itself. Search engines, social platforms, and browsers all rely on behind-the-scenes information to understand what your content is about and how it should appear to people looking for it.
In Drupal, the Metatag module gives content editors a way to shape that understanding. You do not need to be a developer to use it effectively as part of your day-to-day content work. Editing and reviewing metatags is generally straightforward for content editors.
Installing the module and establishing site-wide defaults typically requires a developer or someone with Drupal experience. Tasks such as adding the module, enabling it, and defining default values are usually handled during site setup. Once that foundation is in place, content editors can focus on the quality and context of their content rather than technical implementation details.
This article explains the most common Metatag settings you will encounter, what they do, and when they matter.
The Metatag module lets you manage information about your content that is not visible on the page itself, but is visible to:
You can think of metatags as context. They help external systems understand your content and present it accurately to people who depend on those systems to find trustworthy information.
As a Drupal content editor, the metatag fields you will work with most often appear directly on the content editing screen alongside the rest of the page fields.
You will typically see them:
Many of these fields are pre-populated using defaults established during site configuration.
These fields control how a specific piece of content appears in search results and social shares. You will not need to adjust them for every page. Understanding what they do helps you make informed decisions for high-visibility content, time-sensitive information, or pages likely to be shared widely.
You may also hear references to "Metatag settings" or "Metatag configuration." These live in the Metatag module's administrative settings rather than on individual content pages.
This configuration is used to:
Because these settings affect the entire site, they are typically managed by developers or site administrators. Content editors generally do not need to interact with this area as part of their regular workflow.
Understanding this distinction helps establish clear ownership: developers maintain the framework, while editors focus on content quality and accuracy.
The page title appears in browser tabs and is often used as the main headline in search results.
This is one of the clearest signals search engines use to understand what a page is about. It is also the first thing many people see when deciding whether to click.
Summer Programs for Kids | City of Example
A short summary that often appears below the page title in search results.
While it does not directly affect rankings, it helps people decide whether a page is relevant to them.
Explore fun and educational summer programs for children ages 5–12. Registration now open.
The canonical URL tells search engines which version of a page should be treated as the primary one.
This helps search engines identify the authoritative version of content when similar or duplicate pages exist.
In most cases, this is handled automatically. You usually will not need to change it.
Instructions that tell search engines whether they should:
These settings help ensure that search engines surface the right content while excluding pages that may be temporary, incomplete, or intended for limited audiences. Used thoughtfully, they support clarity, trust, and consistency across the site.
These settings control how your content appears when it is shared on social media. Clear, accurate previews help people quickly understand what they are being asked to read or click.
The headline shown in social previews when the page is shared on social platforms.
This does not have to match the page title exactly. You can use more conversational language if it helps provide useful context.
A short summary shown beneath the title in social previews.
Focus on clarity and relevance. This text helps people decide whether the content is useful to them.
The image displayed alongside the title and description in social feeds.
A clear, relevant image helps your content stand out and be understood at a glance.
You may notice additional fields that are rarely needed on a page-by-page basis. These metatags are typically managed at the site level rather than by individual content editors.
In most Drupal sites, advanced metatags are:
This approach promotes consistency across the site while reducing the risk of configuration drift and unintended changes.
As a content editor, you generally do not need to edit these fields. They are managed for you so you can focus on creating and maintaining clear, useful content.
Modern search engines largely ignore this field. You can usually leave it empty unless your organization has a specific reason to use it.
The Content Language metatag communicates the language of the page to search engines, browsers, and assistive technologies.
This is usually set automatically based on the site's configuration. During site setup, a developer or site builder defines the site's default language and any additional supported languages in Drupal's language settings.
Drupal applies the appropriate language metadata to each page based on:
You typically do not need to manage this field directly. It is handled automatically to help ensure content is interpreted and presented correctly across devices, platforms, and accessibility tools.
These fields are often used for:
They are usually managed globally rather than by individual editors.
For teams responsible for Drupal configuration, governance, or ongoing platform maintenance, the following resources provide additional detail:
Drupal Metatag module documentation (Drupal.org)
Official documentation covering available metatag types, defaults, and configuration options:
https://www.drupal.org/docs/contributed-modules/metatag
Working with images in metatag fields
A helpful explanation of how metatag image fields work with Drupal Media and tokens:
https://mark.ie/blog/adding-tokens-for-metatag-image-fields-when-using-drupal-media-entity
These resources are most useful for developers and site builders, but they can also provide helpful context for editors interested in understanding how content is presented across platforms.
Most Drupal sites provide sensible metatag defaults, which means editors rarely need to complete every field. Even so, it is worth reviewing metatags for key landing pages, high-traffic content, major announcements, and pages that are likely to be shared externally.
Before publishing, take a moment to confirm that:
Metatags are not a substitute for clear content, good information architecture, or strong governance. They are supporting metadata that helps search engines, social platforms, browsers, and assistive technologies interpret content consistently. When paired with well-structured content and thoughtful editorial practices, they help ensure information is represented accurately wherever people encounter it.
Having Drupal Paragraphs installed is not the same as having Paragraphs working. If your editors upload images instead of editing text and file developer tickets for every small change, the problem is usually the implementation - not the platform.
See what separates broken setups from empowering component libraries, the five principles behind editor-friendly Paragraphs, and how proper configuration drove a ~24% conversion lift without a rebuild.
read moreHow to align public policy and procurement to support the costs of our shared digital infrastructure
The modern world runs on open source software—trillions in economic value, and growing more essential to digital sovereignty by the day. Yet, beneath this foundation, the projects producing it are starved of capital. Open source simply does not have the structural resources it needs to be sustainable. The code is free, but the human and technical infrastructure required to maintain it is not.
A project like Drupal is no longer just a code repository; it is a full-scale utility provider. We deliver supply chain security, product management, and continuous integration pipelines. Our licenses waive all warranties and responsibilities—and yet enterprise scale demands we provide these services anyway, because no one else will. The core failure of our current model is that open-source funding is completely disconnected from these operational cost centers.
Because we lack a built-in mechanism to capture the value open source creates, we have accidentally engineered an extractive system. The Takers who consume open source without paying their fair share of its operational footprint are not acting out of malice; they are simply doing exactly what the market currently incentivizes them to do.
It is not inevitable that open source must be extractive. That is an architectural choice. To change the outcome, we must change the incentives. Using regenerative system design, we must re-engineer open-source models to capture enough resources from our outputs to continuously sustain our inputs. We must ensure that supporting open source the right way becomes both the easy way and the expected way.
Right now, supporting open source the right way is almost impossible for our largest users. Public procurement systems are designed to buy structured services from single vendors. They cannot write open-ended checks to decentralized communities. To bypass this "charity trap," we must transition to an operational cost framework and move the operating costs of open source off the donation sheet and directly into core operating budgets as a predictable, line-item consumption expense.
To make the easy way possible, open source foundations must clearly quantify and communicate our true technical and human costs. In Drupal, we know part of it. We provide $10 per site per year in consumable technical infrastructure, but our revenues only fund $7.50. The remaining $2.50 is pushed off as technical debt to the future. That gap says nothing about the release managers and security teams whose essential work is still mostly donated—that burden sits entirely outside this number. We must turn these technical and human maintenance costs into a transparent, billable utility, giving institutions a clear, legally compliant way to pay for what they consume.
But once we make it easy to pay for this utility, how do we make it the expected way?
That requires establishing two clear standards.
For the vendor ecosystem, we need a sustainable participation standard. In Drupal, we have a contribution credit system to visibly recognize our Makers, those who invest real capital, code, and labor into the project. This system also helps us to identify the Fakers, organizations that use sponsorship and marketing to signal commitment while funding and doing little-to-none of the actual work.
For public institutions and enterprise users, we need a sustainable use standard defined by three practices:
With these standards in place, Open Source Program Offices can work with procurement officers to differentiate the true Makers from the Takers and Fakers at the point of purchase. And, the market-making power of public purchasing operationalizes "Public Money, Public Code" into the norm.
Open source cannot thrive on the margins of volunteerism, but it doesn’t have to. Once public policy acknowledges open source maintenance as an operational cost rather than a charitable act, everything else follows. That's regenerative system design in practice: change the incentives, and the system begins to fund itself.
Adapted from a June 23, 2026 presentation by Tiffany Farriss at the Sovereign Tech Agency's Breakfast Reception during United Nations Open Source Week. Photo by Mike Gifford, licensed under CC BY-SA 4.0.
When we started working on the Drupal AI initiative in June 2025, I assumed most AI features would live inside Drupal.
By my DrupalCon Chicago keynote in March 2026, my thinking had changed. I framed the shift as "inside-out" versus "outside-in" and concluded that not every AI capability belongs inside Drupal. Some work is better done outside the CMS, where AI tools can move faster and connect back to Drupal when needed.
Last week, I explored these ideas in more detail in "AI and the great CMS unbundling". That post argued AI is making the CMS less central as a creation tool, but more important as a control layer: the place where content is structured, governed, reused, and published with trust.
This post picks up from there. If Drupal's role as the control layer is becoming more important, it needs to support AI-driven workflows that run inside Drupal, start outside Drupal, and move across both: external workflows that call into Drupal, and Drupal-native workflows that outside systems can safely rely on.
First, Drupal needs to work well with tools outside the CMS: coding agents like Claude Code and Cursor, and orchestration platforms like Salesforce Agentforce, n8n, and Activepieces.
I actually showed what this could look like in my DrupalCon Vienna keynote in October 2025. Here is a short clip of that:
It was a proof of concept demo, and we had some fun with it. But the pattern behind the demo mattered more than the demo itself: an external tool drove the work and handed tasks to Drupal, while Drupal returned structured content and state.
Watch the demo, and it will be easy to imagine the same pattern in a real marketing use case. Campaigns usually begin with a marketing brief and span many tools and channels: email, website landing pages, social media, paid media, and more.
An external agentic platform could generate campaign copy and ask Drupal to build a landing page. Drupal could map the copy to the right structured content type, place it into approved components with Drupal Canvas, save a draft, and flag any fields, metadata, or translations still missing before it can publish.
If Drupal reports a missing hero image, the agentic platform could search the digital asset management system (DAM), find an approved campaign image, and hand it back. Drupal could then attach it through its media model, supply or verify the required alt-text, confirm the page meets its requirements, and advance the draft through the editorial workflow.
This is a pattern that Drupal will need to support well. External platforms can coordinate work across the broader digital stack, but Drupal should remain the system that assembles, validates, governs, and publishes the content.
While the larger campaign workflow may live outside Drupal, there is an equally important case for Drupal-native workflows.
External agents are good at coordinating work across systems. But once a workflow needs to act on Drupal content or data, it should use Drupal's native content model, permissions, validation rules, moderation states, revisions, and publishing workflows rather than recreate them outside of Drupal.
That is where projects like ECA, FlowDrop, and Maestro become more important. They let Drupal turn site-specific processes into repeatable, multi-step workflows that outside systems can call.
For example, any of these three systems could power a single Drupal workflow that validates a draft, coordinates translations in five languages, assigns reviewers, and publishes the content only after all required approvals are complete.
Depending on the task, these internal Drupal workflows can be deterministic, AI-assisted, or fully agentic. Drupal can support that today.
An external agent should not have to manipulate Drupal from the outside, field by field or function by function. It should be able to ask Drupal to execute a Drupal-native workflow through a single external API call.
That is the other half of what I showed in the demo video above. Drupal was not just exposing content to an external agent. It was exposing custom Drupal-native ECA workflows that an external automation tool called.
That was powerful last fall at DrupalCon Vienna, but as agentic workflows become more common, this pattern will only grow in importance.
There is a natural tendency to debate what should live where. Should AI happen inside Drupal, or outside of it? Should workflows be Drupal-native, or managed by external platforms?
Those are useful questions, but the answer is not universal. AI and workflows should live where they create the best end-to-end experience. Sometimes that will be inside Drupal, sometimes outside Drupal, and often across both.
What "best" means depends on the use case, the user, and the requirements for speed, reliability, security, governance, cost, and human review. There will be best practices, but no single approach fits every case.
Who is doing the work shapes what "best" looks like:
Work will move across systems and people. The best end-to-end experience will come from doing each step where it can be done best, while making the handoffs feel invisible.
Understanding Drupal's role in these future workflows gives us clarity about where Drupal needs to go. Drupal needs to get better at supporting external orchestration, Drupal-native workflows, and the real-world hybrids that combine both.
What makes Drupal interesting is that it already has so much of the hard, unglamorous infrastructure these workflows need: structured content, granular permissions, revisions, rollback, JSON:API, and plenty more. These are exactly the capabilities agents need, and they're genuinely difficult to build well from scratch or retrofit.
Conceptual clarity and a strong foundation are wonderful things, but they are not enough to win.
When I asked whether AI coding agents would recommend Drupal, the issue was not Drupal's capability. It was whether agents could get from prompt to a working Drupal site quickly and easily enough. As I wrote in "Friction, abstraction and verification", agents tend to choose the path that gets them to a real, verified result with the least friction.
For experienced Drupal teams, the challenge is different. They have already chosen Drupal. They do not need an agent to recommend it. They need agents that help them build, validate, and ship quality work faster.
To turn Drupal's advantage into adoption, we need to improve both paths: helping agents choose Drupal for new builds, and helping existing Drupal teams ship better work faster. Both depend on making it easier for agents to work with Drupal from start to finish.
That means Drupal needs to expose the best practices, site context, tool definitions, constraints, and precise validation agents need to take the right actions and verify the result.
A lot of this is already underway across Recipes, Site Templates, Drupal AI, Drupal Canvas, ECA, FlowDrop, Maestro, MCP, and CLI improvements, to name a few.
But the goal is bigger than any one project. Drupal needs these efforts to add up to a clear, coordinated path for agents: from setup to connection, context, governed action, validation, recovery, and launch.
Special thanks to James Abrahams, Jürgen Haas, Randy Kolenko, Scott Falconer, and Shibin Das for their review and contributions to this blog post.
read moreThere is a failure mode among experienced developers where they defend their stack because switching would invalidate years of accumulated expertise. The sunk cost is real and the bias is real. The antidote is to take the alternatives seriously when the opportunity comes, build something real with them, and see whether they have caught up.
So when a project's requirements actually push me toward another tool, or when I am curious enough about a new one to spend real time on it, I do exactly that. I read the docs properly. I build a non-trivial prototype. I model a real content structure, not a blog with three fields. I look at what production would actually require. Then I compare honestly.
This post is the result of those evaluations. It is not a Drupal sales pitch. It is the reasoning of someone who has genuinely used the alternatives and keeps finding that, for the work I do, the decision still holds.
Let me start here, because a post that only praises Drupal is not credible.
The modern headless stacks are genuinely better at greenfield speed. If I am starting a small-to-medium project with a clean content model and a React frontend, Sanity or Payload will get me to a working state faster than Drupal will. The developer experience is smoother. The frontend integration is more natural. The mental overhead is lower. For a certain class of project, they are simply the better choice, and I have recommended them when that was the case.
Custom Next.js builds give you total control. No framework opinions to fight. No contrib modules to maintain. For a team with strong frontend engineers and a genuinely unusual set of requirements, building from scratch can be the right call.
These are real advantages. I am not going to pretend otherwise. If your project is greenfield, your content model is simple, and your team is React-native, the alternatives deserve serious consideration and might win.
Here is the pattern I keep hitting. The alternatives are excellent at greenfield and start to strain the moment the content model gets genuinely complex.
A blog with posts and authors is easy in any of these tools. A content structure with deeply nested relationships, polymorphic references, conditional fields, revision workflows across content types, and the kind of editorial complexity that real enterprise content demands is where the headless tools start showing their age, and where Drupal's entity and field system pulls ahead.
This is the single most consistent finding across every round of re-evaluation I have done. The tools that win the demo lose the complex content model. Drupal that loses the demo wins the complex content model. And in the kind of work I do, the content model is almost always complex.
When I strip away the noise, four things keep Drupal as my default for the work I actually do.
Drupal's entity and field system is the best content modeling foundation I have worked with, and I have worked with most of them. The ability to define content types with arbitrary fields, reference entities polymorphically, attach fields to anything, build view modes for different rendering contexts, and have all of it integrate cleanly with revisions, translations, and access control is not matched by the headless alternatives.
The headless tools model content as documents with schemas. That works beautifully until your content is not really document-shaped. Drupal models content as entities in a relational graph, which is harder to learn and more powerful when the structure gets complex. For the content I work with, that power is the difference between a clean implementation and a pile of workarounds.
I have Drupal sites I built years ago that still run, still update, still get security patches, and still make sense to a developer opening the codebase for the first time. The upgrade path from Drupal 8 forward has been genuinely good, and the project takes backward compatibility and security seriously in a way that matters when you are responsible for a site over years rather than months.
The headless ecosystem moves faster, which is exciting and also exhausting. Tools get acquired, change pricing, deprecate APIs, or simply lose momentum. Betting a long-lived enterprise site on a venture-funded SaaS CMS means betting on that company's roadmap and survival. Drupal is not going to get acquired and pivot. That stability has real value when the site needs to live for a decade.
Twenty years of contrib modules, documentation, Stack Exchange answers, and accumulated community knowledge is a moat that is easy to undervalue until you need it. When I hit an unusual problem in Drupal, someone has almost certainly hit it before and written about it. The depth of the ecosystem means most problems are solved problems.
The newer tools have enthusiastic communities, but they do not have twenty years of accumulated edge-case solutions. When you hit the unusual problem in a younger ecosystem, you are often the first one there, which means you are solving it from scratch.
Drupal's Migrate API and its broader enterprise tooling (multilingual, workflow, content moderation, granular permissions, multisite) are built for the scale and complexity that enterprise content operations actually have. I have migrated large, messy, legacy content estates into Drupal, and the tooling for that work is mature in a way the alternatives have not matched.
When a project involves moving hundreds of thousands of pieces of content from a legacy system, with all the data-cleaning and field-mapping and URL-preservation that entails, Drupal has the tools and the patterns. Most of the alternatives assume you are starting fresh, because greenfield is where they shine.
The honest synthesis is this. Drupal is not the right answer for every project, and I do not pretend it is. For greenfield projects with simple content models and React-native teams, the alternatives are often better and I will say so.
But for the work I actually do, which involves complex content models, enterprise requirements, long-lived sites, and frequently the migration of large legacy content estates, Drupal keeps winning the evaluation. Not because I am attached to it. Because every time I take the alternatives seriously and build something real with them, I hit the same wall: they are excellent until the content model gets hard, and then Drupal pulls ahead.
The decision is not "Drupal is best." The decision is "Drupal is best for this kind of work," and the kind of work I do keeps being that kind.
The reason I stay aware of the alternatives is that the day one of them closes the gap on complex content modeling, long-term stability, and enterprise migration, I want to know about it before my competitors do. So far that day has not come. The headless tools keep getting better at the things they were already good at, and keep not solving the things Drupal is good at.
Maybe that changes. Maybe Payload or whatever comes next builds a content modeling system that matches Drupal's entity API while keeping the modern developer experience. If it does, I will notice, because I pay attention. Until then, the choice keeps making itself.
If you have moved from Drupal to one of the alternatives and it held up on a genuinely complex content model, I would be curious to hear about it. That is the case I keep expecting to find and keep not finding, and I would rather learn it from you than from losing a project.
read moreToday we are talking about AI, Agents, and A System to manage them with guest Luke McCormick. We'll also cover AI Auto-reference as our module of the week.
For show notes visit: https://www.talkingDrupal.com/558
TopicsLuke McCormick - cellear
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
Governance, infrastructure funding, and release maintenance define this week’s Editor’s Pick as the Drupal Association keeps self-nominations open for its 2026 At-Large Board Election and introduces the Drupal Sustaining Members Program. The updates connect elected representation, recurring support for shared project infrastructure, security remediation, and final testing for Drupal 11.4.0-rc2.
The election will fill one community-elected seat on the Drupal Association Board. The seat opens as Alejandro Moreno completes their 2024–2026 term. Candidates must self-nominate, and nominations close on 30 June 2026 at 23:59 UTC.
Candidates will be announced on 7 July 2026. The Get to Know the Candidates period runs from 7 July to 21 July 2026, followed by voting from 22 July 2026 at 00:00 UTC to 14 August 2026 at 23:59 UTC. The new board member will be announced on 26 August 2026.
Voting eligibility depends on individual Drupal Association membership. Members must have an active membership by 21 July 2026 at 00:00 UTC, at least 24 hours before voting opens. The schedule gives prospective candidates and voters clear deadlines for participation before the election enters its voting phase.
The Drupal Sustaining Members Program creates a recurring funding path for organisations that depend on Drupal. The association says contributions support Drupal.org, code repositories, software packaging and distribution, the Composer package endpoint, issue tracking, contribution workflows, continuous integration and testing, Automated Updates, Project Browser infrastructure, and security response systems. The programme frames shared infrastructure as an operational responsibility rather than an incidental benefit of open-source use.
The programme follows Acquia’s Fair Trade Initiative, which directs 2% of eligible Acquia partner Drupal deals to the Drupal Association. Together, the two efforts point to a more predictable funding model for infrastructure used across the Drupal ecosystem.
Maintainers should also review Drupal security advisories published on 17 June 2026. The Drupal core advisories cover improper validation, server-side request forgery, cache poisoning and open redirect, a gadget chain, and PHP object injection. Contributed project advisories were also published for Plotly.js Graphing, Flag attendance field, and Formatter Field.
Drupal 11.4.0-rc2 is available for final testing ahead of the Drupal 11.4.0 stable release window. Release candidates are not supported for production sites, but they allow developers, maintainers, translators, and site builders to test compatibility before the stable release. Sites using Media oEmbed URL discovery may also need to review media_oembed_discovery_trusted_host_patterns in settings.php.
Drupal 11.4.x will receive security support until June 2027. Drupal 11.3.x will continue to receive security support until December 2026. Those support windows give site owners a near-term basis for upgrade and maintenance planning.
The DropTimes also held its June Open Townhall as part of its monthly community coordination format. The session covered editorial updates, contributor coordination, community feedback, and coverage planning. It reflects TDT’s continuing effort to align editorial priorities with Drupal community activity and reader input.
Upcoming Drupal events include DrupalCamp Tokyo 2026 on 27 June 2026 in Tokyo, DrupalCamp Kortrijk 2026 from 29 June to 30 June 2026 in Kortrijk, Drupal Camp Asheville 2026 from 10 July to 12 July 2026 in Asheville, and Decoupled Days 2026 from 6 August to 7 August 2026 in Montréal.
The week’s updates place governance, funding, security, release readiness, editorial coordination, and community participation in the same frame. Community members considering board service can review the election process before nominations close. Organisations that rely on Drupal can assess whether recurring infrastructure support fits their open source contribution model.
Additional developments from across the Drupal ecosystem were published during the week. Readers can follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook for ongoing updates. The publication is also active on Drupal Slack in the #thedroptimes channel.
Allen Jason
Junior sub-editor
The Drop Times
AI makes execution cheap. It makes context, coordination, governance and sovereignty more valuable.
The CMS is being unbundled into a control plane and an execution plane. Follow that logic across the full customer experience and something else becomes visible: the DXP is being rebundled as the shared control plane for an organisation’s digital promise.
As you know and have experienced personally, AI has been replacing human interaction in support situations, and in some cases doing a decent job. It generally does a good job with questions about DDEV.
But getting answers to questions is not the only purpose of support. It's also a great way to communicate problems and ambiguities to project maintainers.
We want you to ask us questions! We live for your questions. We miss the fact that you've been absent from Discord, #ddev in Drupal Slack, and the issue queue. When you ask, it helps us to understand what your struggles are and how DDEV can get better. DDEV's strength has always been the community's willingness to engage and share their needs and frictions and hopes for the project.
As you know, Stack Overflow has been displaced by AI. There aren't new answers going up there, because people use the AI answers and don't improve anything for the future. But DDEV is not static and its future depends on you and your needs. If we don't hear you ask about those, we can't react to your experience.
Join us in all the support channels!
Upsun has finished transferring the DDEV trademark to the DDEV Foundation — a milestone for the DDEV project's long-term independence and health. This is a generous and important step for DDEV. (At one time before Upsun/Platform's involvement, we were ready to fork and rename the project due to trademark issues.) Read our announcement↗ and see Upsun's generous response↗ as well.
joomla project type. Community member renekreijveld also maintains the ddev-joomla↗ repository, which provides scripts and tooling for extended Joomla workflows.New community-built GUI tools have appeared for DDEV:
Bob McDonald (UltraBob) presented "Pre-Flight Checklist: Local Code Quality for Drupal Developers" at Stanford WebCamp, covering the ddev-drupal-code-quality add-on for running Drupal.org CI checks locally before pushing. View session↗.
Community member Bill Seremetis (bserem)'s "From Chaos to Consistency" DevOps talk from DrupalDevDays Athens 2026 is now on YouTube. The talk covers how DDEV add-ons work as a file/feature delivery mechanism for standardizing team projects. Watch on YouTube↗ • Slides↗.
DDEV Sponsorship Data Story — A new post on ddev.com tells the story of how a LinkedIn message from Anoop John at TheDropTimes turned into live, auto-updating sponsorship displays across DDEV properties and a public data feed. Read it↗
Open Source AI Contributions — Amber Matz wrote about the complexity AI-generated contributions are bringing to open source projects, using a conversation with Randy as a central example. Worth a read for all maintainers and contributors and AI users. Read↗
The DDEV board and community are working on updated sponsorship tiers and improved communication around them. Discussion at ddev/sponsorship-data#42↗ and ddev.com#647↗.
The first-ever DDEV Foundation Board meeting was held on June 17!
The next DDEV advisory group meeting is July 1, 2026 at 8:00 AM US Mountain / 10:00 AM US Eastern / 16:00 CEST. Add to Google Calendar • See the agenda.
Sponsorship is at 84% of the goal, thank you to everyone who has contributed!
April 2026: ~$9429/month (79% of goal)
June 2026: ~$10,075/month (84% of goal)
If DDEV has helped your team, consider sponsoring. → Become a sponsor↗
Contact us to discuss sponsorship options that work for your organization.
Compiled and edited with assistance from Claude Code.
read moreViews is one of the most important modules in Drupal. After the field system, it is the tool you reach for most often as a site builder. You use it to build content listings, create blocks, power admin screens, and feed components into Drupal Canvas.
In the video above, you’ll learn how to build a Views page, customize fields with image styles and rewrite tokens, expose filters and sorts, configure pagers and infinite scroll, expose a view block as a Canvas component, and create a backend admin page.
read moreLocalGov Drupal Camp 2026 was held on 11th and 12th June in the city of Sheffield in the north of England. I drove over the Pennines from my home in Cheshire to attend the camp for the two days.
LocalGov Drupal, in case you weren't aware, is a Drupal distribution that is set up in a way that makes it easy for councils to publish their content. Since it's built on Drupal the sites can also make use of the many Drupal modules available. There are also lots of additional LocalGov Drupal modules that integrate with waste collection systems, bus timetables, election results, and many more.
Last year, LocalGov Drupal was being used by 57 council websites across the UK. This year, that figure has jumped to 73! A fantastic achievement, with that number only set to get bigger.
The camp itself consisted of a Wednesday night social night, a day of talks and other sessions, followed by a day of workshops and sprints.
The social on Wednesday night was held at the National Videogame Museum in Sheffield city centre. On entry we got a couple of free drinks, and there was plenty of pizza to go around (perhaps too much pizza!).
This was amazing venue to have a social! After spending a while catching up and chatting with lots people we went into the museum itself and played some games for a while. 4 player Pacman and Ultimate Chicken Horse were particular favourites from the evening.
philipnorton42 read moreJust two months after the milestone release of Drupal AI 1.3.0, we are thrilled to announce that Drupal AI 1.4.0 is officially here!
With the 1.x branch reaching a high level of maturity and stability, we are excited to transition into a more predictable, bi-monthly minor release cadence. Moving forward, the Drupal community can look forward to a steady, reliable stream of improvements, new integrations, and expanded platform capabilities.
Drupal AI 1.4.0 represents a major evolutionary step, focusing heavily on extensibility, scalability, normalization, and preparing the broader ecosystem for the next generation of AI-powered digital experiences.
Let's dive into what's new in this release.
One of our primary themes for 1.4.0 is giving contributed module developers the tools they need to extend and enrich Drupal AI. We want to make extending this module as seamless as writing a simple prompt.
Contrib modules can now extend the markdown editor experience directly. The newly available Document Loader integration, for example, allows content creators to load content from virtually any document type directly into their editor workflow.
This architectural improvement opens the door for the community to build richer editor experiences and provider-specific tooling without requiring any modifications to Drupal AI core.
To radically accelerate development speed and reduce boilerplate code, we are introducing both AI "skills" and drush generate commands that allow developers to rapidly generate:
For teams utilizing coding agents or AI-assisted development workflows, these new skills can automatically generate integrations that strictly follow Drupal AI best practices—saving hours of development time.
Image showcasing Slack Chat Processor together with the Webform Agent.
One of the most significant architectural milestones in 1.4.0 is the introduction of normalization for chat systems - an abstraction layer that decouples chat interfaces from their underlying AI processors, so integrations are no longer tightly bound to specific implementations.
This opens the door to immediate, practical use cases: the newly introduced Slack Chat processor lets team members communicate with Drupal AI agents directly through Slack.
More broadly, it lays the groundwork for the upcoming AI Agents processor release and makes it significantly easier to build, package, and reuse conversational, multi-channel AI experiences across providers and platforms.
Handling content at scale is one of Drupal's core strengths, and in 1.4.0 we are supercharging this capability. AI Automators can now execute any configured rule or AI type directly as a Views Bulk Operation (VBO).
This integration unleashes massive efficiency gains for content editors and site administrators. Instead of running AI operations page-by-page, teams can trigger complex, AI-driven workflows across hundreds or thousands of entities simultaneously.
Site builders can now configure Views to bulk-execute tasks such as:
This is a massive usability win for teams responsible for maintaining and optimizing large, enterprise-scale content repositories.
Enterprise-grade operations demand high availability. Drupal AI 1.4.0 lays the crucial architectural groundwork for robust failover and redundancy support across your entire AI stack.
The module's architecture is now fully equipped to handle advanced failover processes. In the near future, site builders will be able to use powerful tools like ECA (Events, Conditions, Actions) to configure custom AI routing logic, unlocking enterprise-ready scenarios, such as:
This represents a significant step toward securing permanent, enterprise-grade reliability for AI in Drupal.
The guardrails feature introduced in 1.3.0 has received a massive upgrade in this release, making Drupal AI safer and more production-ready for large-scale, public-facing deployments.
In 1.4.0, guardrails can now:
The input length limit is a vital security layer designed to prevent "denial-of-wallet" attacks, where malicious actors attempt to spike your API costs by sending exceptionally large, resource-intensive prompts to your providers.
Furthermore, our new real-time streaming guardrails represent a unique solution that very few AI frameworks—and virtually no other CMS platforms—can offer out of the box.
Ultimately, Drupal AI 1.4.0 is less about flashy UI features and more about strengthening our platform's foundational architecture for the future.
With normalized chat interfaces, failover-ready systems, hardened security guardrails, deep VBO integrations, and stateful provider capabilities, this release solidifies Drupal AI as a more reliable, more extensible, and more enterprise-ready platform — built for the open web.
Update your modules, explore the new Drush generators, test out the Slack integrations, and let us know what you build!
For details on the roadmap or to get involved in the initiative, visit our project page on Drupal.org.
Just two months after the milestone release of Drupal AI 1.3.0, we are thrilled to announce that Drupal AI 1.4.0 is officially here!
With the 1.x branch reaching a high level of maturity and stability, we are excited to transition into a more predictable, bi-monthly minor release cadence. Moving forward, the Drupal community can look forward to a steady, reliable stream of improvements, new integrations, and expanded platform capabilities.
Drupal AI 1.4.0 represents a major evolutionary step, focusing heavily on extensibility, scalability, normalization, and preparing the broader ecosystem for the next generation of AI-powered digital experiences.
Let's dive into what's new in this release.
One of our primary themes for 1.4.0 is giving contributed module developers the tools they need to extend and enrich Drupal AI. We want to make extending this module as seamless as writing a simple prompt.
Contrib modules can now extend the markdown editor experience directly. The newly available Document Loader integration, for example, allows content creators to load content from virtually any document type directly into their editor workflow.
This architectural improvement opens the door for the community to build richer editor experiences and provider-specific tooling without requiring any modifications to Drupal AI core.
To radically accelerate development speed and reduce boilerplate code, we are introducing both AI "skills" and drush generate commands that allow developers to rapidly generate:
For teams utilizing coding agents or AI-assisted development workflows, these new skills can automatically generate integrations that strictly follow Drupal AI best practices—saving hours of development time.
Image showcasing Slack Chat Processor together with the Webform Agent.
One of the most significant architectural milestones in 1.4.0 is the introduction of normalization for chat systems - an abstraction layer that decouples chat interfaces from their underlying AI processors, so integrations are no longer tightly bound to specific implementations.
This opens the door to immediate, practical use cases: the newly introduced Slack Chat processor lets team members communicate with Drupal AI agents directly through Slack.
More broadly, it lays the groundwork for the upcoming AI Agents processor release and makes it significantly easier to build, package, and reuse conversational, multi-channel AI experiences across providers and platforms.
Handling content at scale is one of Drupal's core strengths, and in 1.4.0 we are supercharging this capability. AI Automators can now execute any configured rule or AI type directly as a Views Bulk Operation (VBO).
This integration unleashes massive efficiency gains for content editors and site administrators. Instead of running AI operations page-by-page, teams can trigger complex, AI-driven workflows across hundreds or thousands of entities simultaneously.
Site builders can now configure Views to bulk-execute tasks such as:
This is a massive usability win for teams responsible for maintaining and optimizing large, enterprise-scale content repositories.
Enterprise-grade operations demand high availability. Drupal AI 1.4.0 lays the crucial architectural groundwork for robust failover and redundancy support across your entire AI stack.
The module's architecture is now fully equipped to handle advanced failover processes. In the near future, site builders will be able to use powerful tools like ECA (Events, Conditions, Actions) to configure custom AI routing logic, unlocking enterprise-ready scenarios, such as:
This represents a significant step toward securing permanent, enterprise-grade reliability for AI in Drupal.
The guardrails feature introduced in 1.3.0 has received a massive upgrade in this release, making Drupal AI safer and more production-ready for large-scale, public-facing deployments.
In 1.4.0, guardrails can now:
The input length limit is a vital security layer designed to prevent "denial-of-wallet" attacks, where malicious actors attempt to spike your API costs by sending exceptionally large, resource-intensive prompts to your providers.
Furthermore, our new real-time streaming guardrails represent a unique solution that very few AI frameworks—and virtually no other CMS platforms—can offer out of the box.
Ultimately, Drupal AI 1.4.0 is less about flashy UI features and more about strengthening our platform's foundational architecture for the future.
With normalized chat interfaces, failover-ready systems, hardened security guardrails, deep VBO integrations, and stateful provider capabilities, this release solidifies Drupal AI as a more reliable, more extensible, and more enterprise-ready platform — built for the open web.
Update your modules, explore the new Drush generators, test out the Slack integrations, and let us know what you build!
For details on the roadmap or to get involved in the initiative, visit our project page on Drupal.org.
Join us THURSDAY, June 18 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)
We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!
All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.
This free call is sponsored by NTEN.org and open to everyone.
Information on joining the meeting can be found in our collaborative Google document.
Drupal 12 is coming later this year. As with previous major releases, the contributed ecosystem will require updating for breaking changes . Thousands of modules and themes will need their deprecated API uses updated before they are ready. Doing that by hand, across all of contrib, would cost the community an enormous number of hours.
That is the job the Project Update Bot exists to do. We have refreshed it, and it now targets Drupal 12 readiness: it scans contributed projects automatically and opens issues with patches that fix deprecated API uses for you.
If you are a maintainer, you should already know the bot. For the Drupal 12 cycle, our rector rules grew to cover more than 80% of the deprecated API uses introduced in that release. Using our proven toolset: Gábor Hojtsy's Upgrade Status for the analysis, and Drupal Rector for the fixes, now maintained primarily by SWIS and the glue that puts it all together Project Analysis.
Two things improved this round. Rule coverage is more complete, some of that came from AI-generated rector rules based on Dries Buytaert's drupal-digests. And submodule dependencies are now resolved during analysis. In the earlier cycles we scanned submodules but not their dependencies, which caused failed scans and false errors. That is fixed now, so results are cleaner and considerably more accurate.
Patches arrive as either GitLab or Drupal.org issues. The two work a little differently, and every issue the bot opens explains how to apply the patch, pause the bot, or close it. You stay in control of your project throughout.
If you have questions or want to help, we are in #d12readiness on Drupal Slack. And if a patch looks wrong, tell us so we can fix the rule for everyone, open an issue in the Drupal Rector or project_analysis queue.
The bot builds on a lot of other people's work in Upgrade Status, Drupal Rector and drupal-digests. Thanks also to the maintainers who let us test the refreshed bot on their repositories.
This blog post summarizes the key insights from the CX Decoded podcast episode featuring Dries Buytaert, the founder of Drupal and Executive Chairman of Acquia.
In the fast-moving world of digital experience, few names carry as much weight as Dries Buytaert. As the creator of Drupal, he has spent over two decades navigating the evolution of the web. But in his latest appearance on the CX Decoded podcast, Dries issued a candid warning: AI isn’t just another tool - it is a fundamental disruption that is stress-testing every business model in its path.
During the conversation, Dries broke down the "Stable Triangle" of open source and explored why the rise of AI is creating a period of both incredible excitement and existential fear.
For 20 years, the Drupal ecosystem has relied on three balanced sides:
AI is currently hitting all three sides simultaneously. It is changing user expectations for what a CMS should do, challenging the hourly-billing model of agencies, and flooding the contributor community with "AI slop."
One of the most provocative points Dries made was the distinction between a contribution and a can-tribution.
Because AI lowers the barrier to entry, anyone can now generate a thousand lines of code and submit it to an open-source project. This sounds like a win for innovation, but Dries warns of "AI slop" - low-quality, AI-generated code that lacks context or security rigor. For human maintainers, reviewing this influx of code is exhausting.
The takeaway: Just because you can contribute doesn't mean you should if you don't understand what the AI has produced. Quality and accountability must remain human-led.
The agency world is facing a reckoning. If an AI can generate a website or a specific feature in seconds, charging by the hour becomes a race to the bottom.
Dries argues that agencies must evolve. Their value will no longer be in the "writing of code," but in strategic configuration, high-level architecture, and accountability. In an AI world, clients aren't paying for labor; they are paying for a partner who can guarantee that the AI-generated solution actually works, is secure, and achieves business goals.
Dries also touched on the "broken deal" between publishers and AI companies. Currently, AI crawlers extract value from publishers' content to train models, often giving nothing back in return - no traffic, no revenue, and no attribution.
He highlighted a potential shift toward marketplace models (similar to what companies like Cloudflare are exploring) where publishers can set terms for how their data is used. For mid-sized publishers, this might be the only way to survive the "extraction economy."
The podcast concluded with a sobering example: Tailwind Labs. Dries used this as a "canary in the coal mine" for business models. When the thing you sell (like a CSS framework or specific design components) can be perfectly specified and generated by an AI prompt, your original value proposition disappears.
Dries’s message to CX leaders and developers is simple: Prototype fast with AI, but build for the long term with a robust CMS. AI is an incredible accelerator for those with expertise, but a dangerous trap for those looking for shortcuts. To survive the stress test, businesses must move away from selling "tasks" and start selling "results and reliability."
To hear the full conversation, check out the CX Decoded podcast episode on CMSWire.
Author and photos: Martin Anderson-Clutz
Originally posted on Acquia.com blog
Enterprise AI is about cost management; Drupal's AI Summit shows community-driven acceleration. Drupal: the best CMS for the agentic web.
Attending a massive tech gathering like apidays New York 2026 provides a fascinating macro-lens view of where our industry is heading. With ten co-located conferences happening simultaneously, the event served as a perfect melting pot for the cross-pollination of ideas across different sectors of software architecture. Yet, while APIs served as the undeniable common thread weaving through nearly every presentation, stepping between the mainstream enterprise tracks and the co-located Drupal AI Summit felt like walking into two entirely different worlds.
The contrast highlighted a critical tension in technology today: the corporate race to manage costs and practical enterprise constraints, versus an open-source community’s agile, collaborative push toward a truly agentic web.
In the main apidays sessions, the initial euphoric hype around generative AI has clearly given way to hard-nosed engineering pragmatism. The prevailing sentiment among enterprise builders boiled down to two foundational rules:
While these insights are incredibly valuable for infrastructure stability, the mainstream talks frequently veered toward selling proprietary products rather than exploring open topics, and genuine, collaborative case studies were rare. The most inspiring apidays session that stood completely apart from the product pitches focused on AGTP (Agent Transfer Protocol), presented by Chris Hood of Nomotic. AGTP is a proposed application-layer communication protocol designed to be a peer to commonly used standards like SMTP and HTTP, but architected from the ground up specifically for communication between AI agents. I'll talk more about AGTP more in an upcoming post.
Stepping into the Drupal AI Summit offered a completely different energy, characterized by an optimistic tone and solutions rooted entirely in freely available, open-source tools.
Standing room only at the Drupal AI Summit in New York City
Where the broader enterprise tracks viewed APIs as rigid backend guardrails to keep AI contained, the Drupal tracks explored how these emerging agentic capabilities can transform actual user and author experiences. This was the core focus of my own presentation, "AI-driven DXP: New Horizons for Marketers".
While the enterprise is busy worrying about model optimization, the digital experience platform (DXP) ecosystem is looking at how agentic AI fundamentally redefines how marketing teams create, manage, and orchestrate content. In an AI-driven DXP, the traditional boundaries of content management melt away. Instead of treating the CMS as a passive repository, an ecosystem built on agentic AI allows marketers to deploy autonomous workflows that can intelligently adapt experiences, connect disjointed data sources, and scale personalization without requiring manual engineering oversight.
The summit beautifully balanced these high-level, future-forward visions of marketing horizons with real-world challenges that development teams are solving today.
Unlike the abstract trend-decking found elsewhere, the Drupal sessions were rich with actual deployment stories. The sessions demonstrated how the Drupal community is leveraging its enthusiastic embrace of agentic AI to "maintain our edge". A standout example included a highly practical, real-world case study showing how teams are using autonomous AI agents to seamlessly migrate an existing WordPress site into Acquia Source CMS.
In sum, the contrast between the mainstream enterprise tracks and the Drupal AI Summit highlights a significant divergence in the evolution of the agentic web. While the broader industry focuses on cost management and proprietary guardrails, Drupal has found itself as the best CMS for AI. Drupal holds a significant advantage in today's agentic landscape thanks to its mature tooling for structured content, robust enterprise governance features, and an enthusiastic, collaboration-driven community. This unique combination of open-source agility and enterprise-grade architecture ensures that Drupal remains at the forefront of transforming user and author experiences in an AI-driven world.
All sessions from Drupal AI Summit NYC are now available to watch on YouTube.
We have a number of summits and conferences during the year. Visit our events calendar for more details.
The Drupal Association is responsible for the massive infrastructure that keeps the Drupal ecosystem moving forward. From protecting and upgrading Drupal.org to coordinating global events, managing community programs, and providing resources to our vital Security Team, our work requires reliable funding.
Acquia’s Fair Trade Initiative changes the paradigm by embedding funding directly into the transactional deal flow of the new Acquia Partner Program. When an Acquia partner closes an eligible Drupal deal, 2% of that transaction is automatically directed to the Drupal Association to support our core mission. This ensures a sustainable model that aligns Drupal’s commercial growth with continued investment in its underlying infrastructure.
What makes this model truly exceptional is how it aligns incentives across the board:
We want to extend a massive #DrupalThanks to Acquia for their visionary leadership, and to all the Acquia partners who are now automatically driving the future of the Drupal project with every deal they close.
Together, we aren't just building digital experiences; we are building a sustainable, open web for everyone.
[2026-05-27] Drupal AI Learners Club organizers Amber Matz and Angie Byron joined the Talking Drupal podcast for a lively ;) discussion that ranged from the AI Best Practices for Drupal project, the controversy and tension around AI within the Drupal community that ultimately led to the formation of the Club, and what the "vibe" is like.
[2026-04-05 / 2026-04-08] The Drop Times posted a story announcing our little Club's inaugural meeting on April 8, as well as a recap of the session!
