fidzu : Drupal

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

29 Jun 2026 3:31pm GMT

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.

29 Jun 2026 12:29pm GMT

Our 36th monthly UI Suite meeting (June 18, 2026) was a packed one. Despite the early-summer heat in Paris and a few people already on holiday, the team walked through a string of releases, demoed a brand-new starter kit, and gave a first live look at AI agents building Drupal pages on their own. Here's everything that happened.

29 Jun 2026 9:30am GMT

For Drupal teams, emerging tools now touch page building, editing expectations, translation consistency, hosting choices, and debt management. Kortrijk speakers place those shifts inside practical project decisions.

26 Jun 2026 4:04pm GMT

Drupal's workflow tools are being described less as rivals and more as complementary layers. The open question is whether shared primitives can make them compose safely for AI-driven and human-reviewed work.

26 Jun 2026 11:05am GMT

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.

25 Jun 2026 3:44pm GMT

25 Jun 2026 3:26pm GMT

For Drupal teams, small technical choices often decide how maintainable a site becomes. DrupalCamp Kortrijk speakers are using that practical layer as the entry point for sessions on configuration, performance, CSS and editorial work.

25 Jun 2026 3:03pm GMT

Maintainer burnout threatens Drupal's 50,000+ contrib modules. How vibe coding with AI is becoming a lifeline for open source.

25 Jun 2026 1:38pm GMT

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.

25 Jun 2026 11:06am GMT

Three Players, One Direction: ECA, FlowDrop, and Maestro

Jürgen Haas Thu 25 Jun 2026 - 13:00

25 Jun 2026 11:00am GMT

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.

25 Jun 2026 9:22am GMT

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

25 Jun 2026 12:00am GMT

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.

24 Jun 2026 6:40pm GMT

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.

24 Jun 2026 5:45pm GMT

When Paragraphs-based content models grow deep, Drupal teams can inherit slower rendering, heavier databases, and harder migrations. Custom Field maintainer Andy Marquis explains where field-based structured data offers a leaner alternative, and where Paragraphs still belongs.

24 Jun 2026 4:31pm GMT