Artificial intelligence is posing a practical question to Drupal. If AI agents can help plan, build, inspect, and change websites, how easily can they work with Drupal when faster platforms are easier to start?

The Drupal AI Initiative made that question more explicit on 25 June 2026, when it split its work into two streams: Inside AI and Outside AI. Inside AI focuses on tools used within Drupal, including assistants, page-building, and in-product workflows. Outside AI focuses on agents and external tools that need to start with Drupal, connect to it, inspect it, change it, verify it, migrate into it, or launch it.

The shift matters because AI changes how platform choices are made. Human teams may choose Drupal for structured content, permissions, workflows, revisions, and long-term governance. An AI coding agent may judge the same platform by a shorter test: whether it can install, configure, understand, and verify a working site in one session.

Dries Buytaert tested that tension directly when he asked an AI coding agent whether it would recommend Drupal for a site-building task. The agent ranked Drupal third, behind a Next.js and headless CMS stack and WordPress. It did not say Drupal lacked capability. It said Drupal carried more “session-time risk” because setup, module selection, documentation, training data, and frontend choices made the first working session harder to complete confidently.

That is the useful problem for the community to address. Drupal’s AI work cannot depend only on adding visible AI features inside the CMS. It also has to make Drupal easier for external agents and agent-assisted developers to understand, call, inspect, and modify without losing the controls that make the platform valuable.

TDT has also covered this from the workflow side. A report on Drupal orchestration primitives looked at how ECA, FlowDrop, Maestro, and Drupal core are being discussed through shared workflow terms such as triggers, steps, conditions, workflows, and runs. The unresolved question is data handoff: how work moves between Drupal tools, across workflow systems, and out to agents or external automation without breaking governance.

This is where Drupal’s older strengths may become newly important. Revisions, moderation states, permissions, access control, structured content, multilingual architecture, and publishing review are not only CMS features. They are the controls that external AI systems may need when generated content, configuration changes, or workflow actions have to be checked before they reach production.

The test for Outside AI will not be the terminology. It will be about whether Drupal can reduce first-session friction that leads agents to choose simpler tools, while still giving organisations control over review, rollback, audit, and publishing. That means clearer documentation, faster setup paths, reliable examples, machine-readable interfaces, and real feedback from agencies and developers using AI in delivery work.

The curated story list for this edition follows the editor’s note. Readers can also follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook, or join the publication’s Drupal Slack channel at #thedroptimes.

Kazima Abbas
Sub-editor
The Drop Times

The last remaining reason to compile your CSS has just disappeared.

CSS Style Queries have reached Baseline support across all major browsers, and they unlock something we've wanted for years: reusable, stateful design tokens that work entirely in native CSS.

The syntax

At its most basic, style queries allow you to add CSS rules to a nested element, based on a parent’s CSS variable.

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:

• Developers new to Drupal. They ask an AI agent to build a website, and the agent chooses what to build on. Agents reach for whatever they can spin up in seconds, so the opportunity is to make Drupal that easy to install, configure, and use.
• Experienced Drupal developers. They already know Drupal is the right tool, and they want agents to take on more of the work. For Drupal agencies, Outside AI should turn AI into a stronger advantage: helping teams move faster, win more work, protect profitability, and get more value from their Drupal talent.
• External agentic systems and workflow automation tools. These systems coordinate work across many tools, but when they touch content, they need a trusted system of record for workflows, permissions, revisions, and publishing. Rather than rebuilding that governance elsewhere, they should call into Drupal.

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.

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.

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.

The Browser Tab Apocalypse

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 Experiment: Can AI Build a Real Drupal Module?

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?

Why Claude Sonnet 4.5, Not Opus?

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.

The Human-AI Collaboration: How We Actually Built It

AI didn't build this module alone. This was a collaboration, and understanding the dynamics matters.

What AI did (the heavy lifting):

• Generated all entity boilerplate following Drupal 11 patterns
• Implemented three complete plugin systems (ContentFetcher, CategoryRule, MediaProvider)
• Wrote 187 tests (132 unit + 55 kernel) with proper fixtures and mocks
• Wrote the documentation (README, CHANGELOG, API docs)
• Fixed all PHPCS and PHPStan violations autonomously
• Debugged test failures systematically (13 failures across 3 test suites, all resolved)
• Generated field configurations, Views configs, and taxonomy vocabularies

What I did (the professional supervision):

• Created the Product Requirements Document with the 3-phase roadmap
• Made all architectural decisions (entity structure, plugin patterns, security model)
• Decided on module naming (checked drupal.org availability, chose "LinkStash")
• Identified critical security requirements (SSRF protection, XSS prevention)
• Reviewed and corrected AI assumptions when they didn't match Drupal realities
• Ran the actual tests in DDEV (AI can't access Docker environments)
• Caught edge cases AI missed (like the DNS rebinding vulnerability in SSRF protection)
• Made final calls on trade-offs (documented limitations vs. complex solutions)

When I Had to Intervene: The Learning Moments

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.

The Development Speed

The numbers are worth a look:

• Calendar time: Friday/Saturday to Sunday (February 7-9, 2026)
• My active time: 10-20 hours of supervision, decision-making, and testing
• AI sessions: Multiple sessions totaling ~200-250K tokens
• Code generated: 8,000+ lines across entity classes, plugins, services, tests, and configs
• Test suite: 187 tests written and debugged to 100% pass rate
• Documentation: 1,800+ lines (README, CHANGELOG, module intro HTML)

Here's what "one weekend" actually delivered:

• Complete entity system with 12 fields
• Three working plugin systems with 8 plugin implementations
• Browser bookmarklet with popup fallback logic
• Automatic metadata fetching with SSRF protection
• Smart auto-categorization based on 5 domain-matching rules
• YouTube and oEmbed video embed support
• Two Views (list + detail) with exposed filters
• 187 tests (100% passing, ~85% code coverage)
• Zero PHPCS violations, PHPStan Level 1 clean
• Complete documentation ready for drupal.org submission

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.

The Numbers: What Did This Actually Cost?

Let's break down the economics.

Time investment:

• Human time: ~15 hours (let's split the 10-20 range)
• AI compute time: Maybe 30-45 minutes total across all sessions
• Calendar time: One weekend

Token usage:

• Estimated total: 200-250K tokens (spanning multiple sessions)
• Breakdown by task (from progress.md):
  • Project setup: ~10K tokens
  • Entity/field architecture: ~14K tokens
  • Major features (8-10): ~15K tokens each
  • Test suite (187 tests): ~30K tokens
  • Code review + fixes: ~15K tokens
  • Documentation: ~20K tokens

Actual costs (Claude Sonnet 4.5 pricing):

• Input tokens: ~$3 per million tokens
• Output tokens: ~$15 per million tokens
• Rough estimate: $3-$5 total for the entire project

Traditional development cost (rough estimate):

• Senior Drupal developer: $100-$150/hour
• Time required (solo): 40-60 hours (conservative)
• Traditional cost: $4,000-$9,000

The AI-assisted approach wasn't just faster; it was two to three orders of magnitude cheaper while maintaining professional quality standards.

The Future: Where Do We Go From Here?

Building v1 in a weekend was exhilarating, but it's just the beginning. The roadmap has two more phases.

Phase v2 (enhanced features):

• Browser extension for Chrome/Firefox (deeper integration than a bookmarklet)
• Import/export (JSON, CSV, HTML bookmark files)
• Link health checking (detect broken links via cron)
• Duplicate detection and merging
• Collections system (folders, boards, groups)
• Full-text content archival (Wayback Machine style)

Phase v3 (advanced capabilities):

• AI-powered auto-tagging using actual page content (not just domain matching)
• Smart recommendations based on browsing patterns
• Multi-site synchronization for users with multiple Drupal sites
• Drupal Recipe for one-click installation
• Social features (public collections, sharing)

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.

Was It Fun? (Spoiler: Yes, Incredibly)

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."

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.

Not 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.

Critical 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.

A highly critical advisory with a 48-hour window

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.

Coordinating across every client

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.

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.

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.

How 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:

• One, select vendors who sustainably participate in the projects they use.
• Two, include an explicit open source maintenance line item in every contract—a cost-recovery expense that shifts the burden off pro-bono maintainers.
• Three, require timely upstream release of all non-sensitive bug fixes and features.

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.

Drupal joins workflows beyond the CMS

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.

External workflows call Drupal-native workflows

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.

The best end-to-end experience will win

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:

• A developer may prefer an external coding agent like Claude Code.
• A marketer may prefer a Drupal-native experience that keeps them close to previews, translations, moderation, and publishing.
• A campaign manager may need an external workflow that coordinates email, social media, analytics, DAM, and CMS.

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.

A head start is not a plan to win

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.

I Keep Evaluating Alternatives to Drupal. I Keep Choosing Drupal. Here Is the Actual Reasoning.

Why I Bother Looking at All

There 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.

Where the Alternatives Are Genuinely Better

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.

Where They Keep Falling Short

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.

The Four Reasons I Keep Choosing Drupal

When I strip away the noise, four things keep Drupal as my default for the work I actually do.

1. The content modeling is genuinely better

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.

2. Long-term maintenance and stability

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.

3. Ecosystem and community depth

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.

4. Migration and enterprise-scale capability

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.

What This Means in Practice

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.

Closing Thought

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.

Today 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

• Introducing Agent Management
• Origin Story Claude Credits
• Scrum Meets AI Retention
• Handoff Protocol Filesystem
• Why Handoffs Work So Well
• Examples and Human Loop
• Agent Roles and Model Costs
• Choosing Models by Task
• Not Drupal Specific
• Works With Any Model
• Scrum Sprints For Agents
• Human Cognitive Overload
• Tuning Autonomy Levels
• Setup And Handoff File
• Updating Customized AMS
• Persistent Memory Artifacts
• Demand Better Summaries
• Solo Power With Agents
• Roadmap And AMS Trio

• Stanford Web Camp - Agile for Agents – Managing Robots The Way We Manage Humans.
• AMS
• Robert Douglas spec kitty
• xdebug tui
• ams-trio

Luke McCormick - cellear

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to use AI to suggest related content on your Drupal site? There's a module for that.
• Module name/project name:
  • AI Auto-reference
• Brief history
  • How old: created in June 2023 by Scott Euser (scott_euser) or Soapbox
  • Versions available: 1.0.0-rc4
• Maintainership
  • Actively maintained
  • Security coverage - opted in, needs stable release
  • Test coverage
  • Number of open issues: 4 open issues, 1 of which is a bug
• Usage stats:
  • 19 sites
• Module features and usage
  • AI Auto-reference works with any reference fields, so it could find suitable taxonomy terms, nodes, etc
  • It does that by rendering a specified view mode, so it should with any kind of complex layout approach you may have implemented on your site
  • It will also automatically shorten your content to fit within your AI model's token window, which you can also configure
  • The module extends Drupal's main AI module, which means you can select which model to use, and probably means you can also use guardrails, and all the other powerful features that come with that ecosystem
  • Ai Auto-reference comes with default prompts, but you can also edit those if you really want to make sure you're squeezing out every drop of relevance
  • You can also choose for which fields in each content type you want to generate suggestions, as well as whether you want the suggestions should be automatically applied, or whether you want them manually reviewed
  • As mentioned on the project page, you can already have AI suggest things like tags using the AI module without this project, but this may be a better choice if you want to make sure the recommendations stick to an existing set

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