From "I'll Get to It" to Done: Modernizing File Upload Secure Validator

I’ve been meaning to clean up the File Upload Secure Validator project and get it ready for Drupal 12 for a while now. This small, focused module has been around for nearly a decade. Despite its simplicity, it continues to serve more than 10,000 reported sites, and adoption has only accelerated with the introduction of Drupal AI. With the help of Cline and Claude, I finally did a full overhaul of the codebase: switching to Drupal 11-only support, expanding the automated test suite, and positioning the project for Drupal 12.

A Decade-Old Module Meets Drupal 12

This was the kind of maintenance work I kept putting off, the same feeling I get when I need to sit down and do my taxes. I knew the project needed cleanup and modernization, but I wanted a little push and some company in doing the work. The missing motivation and sense of camaraderie were, in many ways, the biggest challenges.

On top of that, I had a clear vision for how I wanted to extend the test suite, and I knew it would be time-consuming. Time, or the lack of it, was a major factor, especially for this kind of detailed, behind-the-scenes work on an open source module.

Turning a Wish List Into a Working Plan

To move things forward, I turned to Cline and Claude to help plan the future of the module. I started by writing down a list of "wishes" for the project: the improvements I wanted to see in the code, tests, and overall quality.

Cline turned that list into a detailed execution plan. It also generated questions about the approach, which led us into a few iterations before we settled on the final course of action. That planning process gave structure to the work and made it much easier to tackle in focused sessions.

All of the changes happened in the project's repository on the 2.2.x branch, with the final result released as version 2.2.1 on Drupal.org.

From Red CI Pipelines to Green Across the Board

Before this overhaul, the project had accumulated a number of issues:

• Multiple GitLab CI failures
• Drupal 11.3+ deprecation warnings
• Unit test failures (including static method and TranslatableMarkup issues)
• Limited test coverage
• 383+ PHPCS violations
• CSpell errors
• PHPStan attribute errors

After the overhaul, the picture looks very different:

• All GitLab CI tests passing
• Zero deprecation warnings
• 23 tests with 164 assertions
• 0 PHPCS errors and 0 warnings
• 0 CSpell errors
• 0 PHPStan errors
• 100% CI quality checks passing

This overhaul gave me the "manpower" and momentum I was missing to push the project forward. Just as importantly, it gave me confidence that I can continue supporting this module in the future.

AI-Amplified Maintenance for Critical Dependencies

Maintaining and supporting open source libraries can often become demanding because of limited time and resources. In client projects, dependencies on under-maintained open source projects can increase the effort required to maintain or upgrade the client's own platform.

Partners like Cline and Claude can change the game in an advantageous way. Such a change can help teams keep critical open source dependencies up to date, improve quality, and reduce risk without requiring a huge amount of extra human capacity.

Bring practical, proven AI adoption strategies to your organization, let's start a conversation! We'd love to hear from you.

This year's conference coincides with Drupal's 25th anniversary, which feels like the right moment to take stock of where we've been and where the platform is headed. We've been building and contributing to Drupal since its earliest days, and the work the community is doing right now, particularly around AI integration, Workspaces, and modern developer tooling, is some of the most exciting we've seen.

We're bringing three sessions to DrupalCon Chicago this year, covering testing, enterprise content staging, and what happens when you point AI at a seriously complex migration.

Drupal Test Traits: Learn by Example

Moshe Weitzman | Tuesday, March 24 at 9:00 AM | Salon A-1

Moshe will kick off our session lineup with Drupal Test Traits (DTT), the open source testing framework he built that takes a fundamentally different approach to testing content-heavy Drupal sites. Rather than spinning up empty databases and populating them with mock data, DTT tests against your actual site content, so you're validating the things that actually matter to your editors and visitors. Expect practical examples drawn from Massachusetts' mass.gov testing suite.

Workspaces Is Revolutionizing Drupal Core

Fabian Franz & Peta Hoyes | Wednesday, March 25 at 3:00 PM | Salon A-4

Fabian and Peta will present on Workspaces, one of Tag1's major contributions to Drupal core and the foundation for true enterprise content management in Drupal. If you've followed our recent work on the Drupal AI Initiative, you already know that Workspaces is the governance layer we're extending to manage AI-driven changes, but the session goes well beyond AI, covering site-wide content staging, publishing workflows, rollbacks, translation management, A/B testing, and more. If your organization has outgrown single-item content moderation, this is the session for you.

Migrate Smarter: How a Structured AI Methodology Unlocked a Complex Drupal 7 to 11 Migration

Marco Molinari | Wednesday, March 25 at 3:00 PM | Salon A-5

Yes, we know, we're double-booked. How awkward! Marco's talk on AI-assisted migration covers how he used BMAD (Breakthrough Method for Agile AI-Driven Development) to migrate an Italian humor site (132K nodes, 100K newsletter subscribers, 18 custom modules, 93 contrib modules) from Drupal 7 to Drupal 11. What makes the session valuable is Marco's candid assessment of where AI-assisted development delivered real acceleration and where human expertise was still irreplaceable.

Come See Us (and Try Something New)

You'll find us at the big orange Tag1 booth on the expo floor with coffee in the morning, cool drinks in the afternoons, and comfy seating all day. Come recharge with us!

We're also offering a special sneak peek of Tag1's Drupal AI site builder. It can generate multi-page sites with real content, multilingual support, and layout customization, all using Plus Suite, Workspaces and Drupal best practices. If you catch Fabian and Peta's Workspaces session, the demo is a natural next step to see that content staging infrastructure in action. And if you've read our recent post on joining the Drupal AI Initiative, this is where that work comes to life. Come play with it, and tell us how you're using AI on your own sites.

On Tuesday evening, we'll have two tables at the Drupal 25th Anniversary Gala. We're looking forward to great food, a special anniversary beer, live music, and a chance to celebrate 25 years of Drupal with the people who built it. We'd love to see you there.

See you in Chicago!

I'm proud to share that Tag1 has joined the Drupal AI Initiative as a Certified Gold Partner and Maker, committing dedicated engineering time to help shape how AI works inside Drupal. We've been building Drupal since day one, and we're excited to be part of its most consequential evolution in years. We plan to contribute across multiple areas of the initiative, but we’re starting by bringing governance to AI-driven changes because that's the necessary foundation for all of it.

The Governance Gap

AI tools that generate content and alter site layout and configuration are getting more capable by the day. But capability without governance is a problem, especially for organizations with compliance requirements, editorial review processes, and production sites that can't afford surprises.

You wouldn't give a new team member free rein to change your website on their first day. It doesn't matter how talented they are. The same logic applies to AI agents: they need a sandbox to work in and a human to review before anything goes live. Letting agents make changes to your website without review, approval, or an audit trail isn't bold; it's reckless.

Tag1 contributed the solution to this problem to Drupal core. Workspaces already gives teams the ability to stage content and configuration changes in isolation, review them, and publish when ready. It's the enterprise content governance layer of Drupal. Extending that same model to AI agents is the obvious move.

What Tag1 is Building

We’re starting by extending Workspaces within the AI Initiative so that AI agents operate under the same governance framework that human editors do. The goal is that agents propose changes in isolated branches, humans review/approve, and every action is auditable and reversible. It's how we think AI should be applied everywhere: practical, tested, and built in the open.

We're starting with the underlying architecture, defining the interface contracts that ensure AI tools and other subsystems work correctly within Workspaces. This is the kind of unglamorous infrastructure work that makes everything else possible. If the contracts are right, any AI tool that follows them gets governed staging, review, and rollback for free. If they're wrong, nothing downstream works reliably.

The Tag1 team has been contributing to Drupal's architecture for over two decades. This work is a continuation of that commitment, getting the foundations right so the rest of the ecosystem can build with confidence.

Governance for Every Drupal Site

AI governance built into Drupal core means every site benefits. An agency building on Drupal CMS gets the same governance primitives as a Fortune 500 running a custom installation. The framework is designed to be agent-agnostic, so it works regardless of which AI tools an organization chooses to deploy. The governance layer doesn't care whether the change came from a chatbot or a custom automation. It cares that the change was reviewed and approved before it hit production.

Drupal has always been good at balancing rapid change with shared standards. The current wave of AI adoption is the latest version of that challenge, and open source collaboration is still the best way to get it right. Adding governance by extending Workspaces is just the start, and we’ll have more to share as the work progresses.

Let's Talk

If you're thinking about content governance in Drupal, or working through how to keep AI agents safe and auditable on your sites, we'd love to hear from you. We test everything in our own engineering and operations before we bring it to clients - that's our AI Applied philosophy - and the best solutions come from real conversations about real problems.

A Small Fix That Wasn’t So Simple

My first contribution to the Drupal Metatag module started with what looked like a simple issue: fixing broken external documentation links. The task was logged as Issue #3559765 Fix broken links in the Meta tags section , and at first, it seemed like a quick cleanup job. But the deeper I looked, the more it revealed about the fragility of open source documentation, and how AI can speed up the repetitive parts of technical contribution work while still requiring careful human judgment.

Broken links may not sound exciting, but they highlight a widespread challenge in open source maintenance. Documentation links age fast. Websites vanish. URL structures change without warning. And because the Metatag module contains dozens of plugin files pointing to different sources, even a small fix meant a lot of detail work.

How AI Accelerated the Research Phase

To begin, I scanned the src/Plugin/metatag/Tag/ directory, which contains over 30 plugin files. This was where AI added real value, not by writing code, but by making the background research faster and more structured. I found six that had broken or unreliable links:

• SetCookie.php: Link to metatags.org was returning 404
• Rating.php: Link to metatags.org was broken, though the RTA link worked
• Google.php: Google webmasters link returned 404
• Expires.php: Link to csgnetwork.com calculator had connection errors
• Standout.php: Google News documentation was broken (404)
• NewsKeywords.php: Google News documentation was broken (404)

For each broken link, I needed to verify the issue, find a reliable replacement from an authoritative source, confirm it worked and was stable, then update it in the code without disrupting formatting or introducing linting errors.

Finding Every Link

Checking each file manually would have been tedious. Using AI, I generated efficient grep patterns for discovering URLs across the whole directory, like this suggestion that matched multiple URL styles: https?://|www\. That one line let me identify every external link across 30+ plugin files in minutes.

Verifying What Was Broken

The next challenge was figuring out which links actually worked. Instead of opening them one by one, AI recommended using a simple curl command to automatically test HTTP status codes:

curl -s -o /dev/null -w "%{http_code}" "https://example.com"

This approach let me quickly categorize links as 200 (working), 404 (broken), or 301 (redirects), giving me a precise list of which needed attention.

Finding Better Sources

When replacing links, AI helped search for credible alternatives, suggesting sources like MDN, W3C, IETF, or Google Search Central. It also helped compare multiple options and recommend the best one.

When AI Needed a Human Touch

Despite its efficiency, AI couldn’t make every decision. Some choices depended on contextual understanding, deciding whether a replacement even made sense.

Google News Documentation

Two plugin files, Standout.php and NewsKeywords.php, both referenced Google News documentation that no longer existed. AI surfaced generic help pages, but none were relevant. Since the tags were already marked @deprecated, I chose to remove the links entirely. This was a judgment call informed by understanding the code’s context and the importance of avoiding misleading or obsolete references.

Content Rating (RTA) Documentation

In Rating.php, the existing RTA link technically worked but wasn’t reader-friendly. The AI proposed a few options, but ultimately, I picked Wikipedia’s page on content rating systems. It included the RTA standard, offered better context, and felt more accessible, a human decision about user experience, not just URL accuracy.

What This Taught Me

Several clear themes came out of this contribution:

• Third-party documentation is fragile. Even long-established sources like metatags.org and csgnetwork.com can disappear or restructure, breaking countless references.
• Redirects can cause silent problems. A 301 redirect still “works,” but introduces slower load times and unnecessary chains. Direct links are cleaner.
• AI excels at repetitive verification. Checking and verifying dozens of URLs took minutes instead of hours.
• Context remains human. AI found replacements but couldn’t know when removing links made more sense or why accessibility might matter more than originality.
• Authoritative sources reduce maintenance. Linking to MDN, IETF, or W3C means fewer headaches for future maintainers and reviewers.

The Outcome

The final patch replaced or removed all broken documentation links:

Fixed with authoritative replacements:

• SetCookie: MDN documentation
• Google: Google Search Central
• Expires: IETF RFC 1123
• Rating: Wikipedia

Removed (no suitable or relevant replacements):

• Standout : Google News documentation removed
• NewsKeywords: Google News documentation removed

The workflow became smoother, faster, and easier to reproduce. Using AI to handle repetitive validation tasks allowed me to focus my attention on decisions that actually required human reasoning.

A Better Way Forward

This contribution showed how AI can accelerate contribution workflows without replacing the thoughtful judgment that open source development depends on. By blending AI-assisted discovery with context-aware decision-making, contributors can move faster and still produce work that’s accurate, accessible, and maintainable.

Maintaining external documentation links might never be glamorous, but it’s a perfect example of how AI can make quality improvements faster and more sustainable, one verified link at a time.

Bring practical, proven AI adoption strategies to your organization, let's start a conversation! We'd love to hear from you.

How I Used AI to Tackle a Tricky Trash Module Challenge

I have been using AI for work for quite some time now for various personal projects. I was inspired and empowered by Tag1's internal AI workshop, and I started using it extensively for both internal projects and a challenging contrib module assignment. What surprised me most was not AI magically solving hard problems, but how much time it could save on the repetitive parts of the work, especially around writing and iterating on tests. I want to share what I discovered because some of it genuinely surprised me.

The Challenge of Adding Taxonomy Support to Trash

Wanting to find an issue to tackle with AI for my own learning experience, I picked up issue #3491947 to add taxonomy support to the Trash module. The Trash module provides soft-delete functionality for Drupal entities and, once configured, it lets you delete entities temporarily and restore them later or purge them permanently if needed. This sounds straightforward enough, but taxonomy terms have a wrinkle that makes things interesting. When you delete a parent term, Drupal core deletes its children too, and this hierarchical deletion creates real challenges for a trash and restore workflow.

This issue had been open for a while with some interesting discussion about the right approach, and I had actually started working on it earlier as part of Tag1's sponsored open source development. I had created an initial MR that enabled trashing terms, but the hierarchy problem was still unsolved, and I wanted to see how AI would handle the complexity.

The module maintainer, Andrei Mateescu (amateescu), had suggested an elegant approach in the issue queue: since cascading deletes happen in the same request, all the deleted terms would have the same timestamp, so we could use that deleted timestamp to restore child terms along with their parent. It sounded promising, and I wanted to test whether it would actually work. So I started down the path, expecting that if I could lean on the shared deleted timestamp, I might avoid storing extra hierarchy data myself.

First Steps: Planning with Cline

I started with the Cline extension for VS Code in a “Plan” mode (Figure 1).

Just for fun, I opened with a prompt asking to help me formulate a plan by going through the issue and studying the Trash module code. It could not access the issue directly, which is actually good from a security perspective, but Claude scanned my project and was able to find the Trash module in it, scanned through the code, and presented a decent understanding of how trashing works. I then explained the hierarchical deletion problem in detail, and the AI checked again and reached the same conclusion I had. When I shared Andreii’s suggestion about using the delete timestamp for restore, the AI presented a three-phase plan covering implementation, basic tests, and optional UX improvements.

At first glance it looked reasonable, but I spotted a major flaw immediately. The AI assumed that deleting a term would trash the parent and hard-delete the children, which is simply wrong. Once trash support is enabled, all terms being deleted move to trash including the children, and every bit of logic that followed was built on this broken assumption. This is exactly the kind of thing that makes working with AI both frustrating and fascinating. There were other misunderstandings (hallucinations) too. So, I decided to start fresh.

After a few trials, I used the following detailed prompt in a new session:

Assume a role of an expert Drupal developer developing a custom feature for the contributed Trash module on a Drupal site. We want the module to support "trashing" taxonomy terms, which is currently disabled.

Background/Current State:
The Trash module adds a deleted column to entity data tables to enable soft-delete/trash functionality.
Taxonomy term trashing is currently disabled via a code line that I can remove to re-enable it.
When a taxonomy term is deleted by default in Drupal, its children (if they have only one parent) are also deleted. This complicates restoration logic.

Goals:
Allow taxonomy terms to be trashed (not hard-deleted), leveraging the module’s infrastructure.
Enable correct restoration of trashed terms, including their child terms.

Technical Challenges:
Taxonomy Overview Page Tree Rendering:\n\nThe taxonomy overview page uses the buildTree function to load hierarchical term data via direct database queries. buildTree currently doesn’t account for the trashed (deleted) column, so trashed terms might break the vocabulary page (e.g., inaccessible, errors). Core updates to taxonomy API are not allowed (must solve without modifying Drupal core).

Restoration Logic for Hierarchies:
The existing trash implementation only restores single entities.
When a parent term is restored from trash, I need to also restore child terms that were trashed at the same time.
All terms trashed together share the same deleted value, which can be used to identify them as part of a single trash operation.

Please provide step-by-step guidance for:
Enabling trash support for taxonomy terms.
Where and how to safely re-enable support (removing the disabling line).
Modifying or extending buildTree (or its usage) without core changes to prevent errors from trashed terms.
Approach for filtering out trashed terms when rendering the tree.

If possible, suggest ways to hook, alter, or override tree loading, limited to contributed/custom code.
Implementing restoration logic for hierarchical terms.
How to batch-restore child terms if their parent is restored from trash.
Using the shared deleted value (timestamp/etc.) to identify child terms involved in the same operation.
Any Drupal hooks or architectural suggestions for this process.

I had to do several trial-and-error iterations to come up with this prompt. With that detailed context, the AI performed much better.

It enabled the trash support for taxonomy in configuration by identifying the code. It then tried to fix the listing page queries and failed. I pointed it to use query tags to tag the listing queries and alter them to check if the term is trashed. This was implemented swiftly. The AI implemented a Trash handler for taxonomy terms, which was actually a good decision I had not prompted. But its implementation had a fatal flaw in that it used a class-level array variable for storing the term hierarchy (static caching). This obviously will not work because delete and restore operations happen in separate requests with no persistence between them.

While testing, I found that the trash module automatically trashed the child terms if the parent is deleted. This was expected behavior.

The Discovery That Changed My Understanding

Through old-fashioned debugging and stepping through the deletion flow, I finally understood why the timestamp approach would not work, and it comes down to how Drupal core handles term deletions.

Say you have a hierarchy of terms A and B where A is the parent. When term A is deleted, Term::preSave is called and then the term is deleted. After that, Term::postDelete is called to delete the orphaned children. But here is the problem: When the child term B is about to be deleted, Term::preSave is called again, and that function resets the parent to root before the term gets trashed. This removes any trace of the previous hierarchy entirely.

So even though both terms end up with the same deleted timestamp, we have lost the parent-child relationship by the time they are in the trash. We will need to store the hierarchy data somewhere else, probably with the term itself as others had suggested in the issue. I posted this finding back to the issue queue because it changes the direction of the solution. After that, the maintainer suggested that we pause and reconsider the overall direction of the fix before writing more implementation code. I didn’t want to just stop working at that point, so I decided to focus on something that would still add value: a solid set of tests around the behavior we had uncovered.

I reached this conclusion through traditional debugging, but AI became useful once the solution path was unclear, because it could help me quickly generate and refine tests instead of spending my time on boilerplate.

Starting Fresh and Finding My Rhythm

With the understanding that solving hierarchical restore is tricky and needs more intervention from the module’s maintainer, and that the direction of the fix was on hold, I decided to change how I contributed. Instead of trying to force a solution, I asked AI to help enumerate test scenarios and create tests for trashing, restoring, and purging terms, and it came up with a decent list of scenarios (it applied trashing, restoring, and purging):

• Single term
• Hierarchies with one parent
• Hierarchies with multiple parents

I specifically requested creating atomic tests where one test does one thing. In previous iterations I had noticed it crammed multiple assertions into single tests, but this time it created a comprehensive test class covering all scenarios properly. AI generated the initial test code and structure, and my job was to review, adjust, and guide it toward clean, atomic tests that matched how we actually use the Trash module.

This felt like a real breakthrough in how to work with these tools, namely: you must provide as much context, detail, and guidance as possible in order to get good results.

It tried to run these tests, failed a few times, and I had to step in to explain that the project uses DDEV and tests need to run inside the container. Even then it took three or four more attempts to get the tests running, which tested my patience a bit. As expected, all tests except the hierarchical restore passed.

None of this moved the core solution forward directly, but it still added real value. By using AI to design scenarios and generate most of the test code, I could keep making progress without sinking a lot of time into repetitive work. Those tests now act as a reusable safety net for future changes, so when the direction is finally decided, we will already have a solid foundation to build and iterate on.

Without AI, I probably would have stopped at one or two manual checks or a much smaller test suite, simply because of the time investment. With AI handling the boring parts of writing and reshaping tests, I could afford to cover more scenarios and refine them, even though the underlying solution is still on hold.

Internal Work Showed Me the Real Potential

The Trash module work showed me how AI can help with testing around complex problems, but internal projects are where it really clicked for me. For internal projects, the AI proved more immediately useful, and I got genuinely excited about the possibilities here. For example, on a separate internal project, I needed to create a text filter plugin for rich text formats in Drupal that checks for special unordered lists and replaces them with a Storybook component.

I crafted my prompt carefully based on previous attempts where the AI went wild and tried to implement everything from scratch including the filter plugin, the component, and all the theme functions. In a new session I prompted explicitly that I did not need a new theme function, that it should just use twig include from Storybook, and that it needed to handle nested lists properly since they are multi-level.

It generated a decent filter plugin on the first try, and while there were mistakes of course, I guided it toward modern PHP patterns like attributes and constructor property promotion and PHPStan compliance. A couple of project-specific issues needed manual fixes, but the core implementation was solid.

The tests went really well too. I started with a Kernel test, then tried a Functional test, and eventually settled on Unit tests on the tech lead's suggestion. The Unit test was precise and to the point, and I think this is where AI really shines because the context is clear and limited in unit testing scenarios.

CSS Help Was a Pleasant Surprise

As someone who is mostly a backend developer, this is where I found the use of AI to be genuinely delightful. It quickly understood the project's styling approach, detected that we were using Tailwind, and suggested fixes with basic prompts. No deep context needed, just quick wins that saved me from the usual frustration of wrestling with frontend styling.

Together, these internal projects reinforced the same pattern I saw with the Trash module: AI is most helpful when I give it a narrow, well-defined problem and let it handle the repetitive parts while I focus on the decisions.

The Lessons That Actually Matter

The biggest realization I had is that you need to treat AI as a junior developer who needs clear guidance and supervision. It never replaced my debugging or architectural judgment, but it did make it cheaper and faster to handle the repetitive parts of the work. Providing context aggressively makes an enormous difference, and the more specific you are about the codebase structure the better the results turn out. In my case that meant offloading a lot of test boilerplate, trying out different test structures (Kernel, Functional, Unit), and iterating on scenario coverage without feeling like I was wasting time. Limiting where the AI can scan also helps manage the context window size, which matters more than I initially realized.

I found that spending time in Plan mode before rushing to Act pays off tremendously because it lets the AI think through the problem first. Keeping scope small is also critical since large ambitious prompts lead to hallucinations and broken assumptions while small well-directed tasks actually get completed correctly.

When the AI starts hallucinating, restoring to a previous checkpoint or starting fresh with the same context works much better than trying to correct a conversation that has gone off the rails. I learned this the hard way through several frustrating sessions.

Managing the “context window” for the AI is important. Sometimes starting a fresh conversation makes more sense than continuing with the existing one. I made sure that I exported the context in each conversation, adjusted it and carried that to the next session.

Used this way, AI feels like a junior developer who is great at cranking out tests and repetitive scaffolding, while I stay focused on debugging, design decisions, and understanding the problem. The thing that excites me most is that using AI we can finally do test-driven development without it feeling like a burden. That alone makes learning to work with these tools worthwhile, and I am looking forward to exploring this further on future projects.

Bring practical, proven AI adoption strategies to your organization, let's start a conversation! We'd love to hear from you.

Image by Cline

Transcript

From Idea to working Drupal prototype with AI-assisted coding

I started with a simple goal: build a working prototype that could summarize linked documents directly in Drupal, without having to spend too much time on it. AI-assisted coding helped me move from idea to an installable module quickly, even though the first versions weren’t perfect. The focus was on getting something functional that I could iterate on, instead of hand-writing every piece from scratch.

The prototype I put together with AI-assisted coding works and can be installed and tested. You can find it on GitHub at https://github.com/minnur/docs_summarizer_tooltip.

Initially, I tried using Cline with Claude Sonnet to generate the module. It produced a full module structure, but the result didn’t actually work in Drupal. JavaScript in particular needed refactoring, so I switched over to Claude Code, which became my main tool for debugging and refining the implementation.

What broke, what worked, and what I fixed with Claude Code

One of the biggest pain points was the tooltip behavior itself. The tooltip wasn’t positioning correctly, which meant the UX felt off and inconsistent. I used Claude Code iteratively to adjust the JavaScript until the tooltip appeared in the right place and behaved in a way that felt natural.

Another issue was that the tooltip wasn’t showing the title as expected. I tracked down the generated function responsible for rendering the header, wired in my own variables, and then asked Claude Code to include that variable in the header output. After that targeted change, the tooltip finally displayed the title properly and felt much closer to what I wanted.

Turning document links into smart, AI-powered tooltips

The core concept of the module is straightforward: detect document links on a page and show an AI-generated summary in a tooltip on hover. It started life as a PDF-only prototype, focused on a single file type so I could validate the idea. Once I had the tooltip behavior working smoothly, with correct positioning, title rendering, and consistent UX, I was ready to expand the scope. I asked Claude Code to refactor the module to support more file types beyond PDFs and rename it to “Document Summarizer Tooltip.”

The refactor mostly worked, but the rename was incomplete. Some files kept the old name and needed manual updates. This was a good reminder that while AI can handle broad changes efficiently, it still needs a human to double-check details across Drupal files and configuration.

Accessibility, ARIA, and making AI summaries usable for everyone

Once the basic behavior was there, I wanted to think about accessibility. A tooltip full of AI-generated content is not very helpful if screen readers or keyboard users can’t access it. I asked the AI to help with adding accessibility considerations as a next step, including ARIA attributes and behavior that would work beyond simple mouse hover.

The initial AI-generated settings form went a bit overboard and included more fields than I actually needed. That said, it did a good job of covering a lot of reasonable options. From there, I was able to prune back the form to something simpler and more focused, which also made the UI easier to understand and configure.

What AI got right (and what still needed review)

One thing that stood out to me was how well the AI handled some of the integration details. It added Drupal AI integration and CSRF token support with almost no issues, which saved a lot of time. It also recognized variables I introduced and reused them correctly across functions, which made iterations smoother.

At the same time, the generated code was not something I could just drop in without reading. A few Drupal API calls looked right on the surface but weren’t actually real. That required a thorough review and manual fixes. I didn’t have time to add unit tests for this prototype, but in the future I’d like to see how well AI can help suggest or scaffold tests alongside code changes.

How clients can use AI for prototyping, accessibility, and tests

There are a few clear ways clients could apply this approach. First, AI-assisted coding is very effective for rapid prototyping, especially when you need to validate a module concept before committing a lot of engineering time. Second, using AI to help with accessibility improvements in templates can speed up the process of making interfaces more inclusive.

Finally, I see a lot of potential in using tools like Claude Code to support test creation and maintenance. While I didn’t get to that stage on this project, generating tests, fixing contributed modules, and experimenting with code improvements all look like strong fits for this kind of workflow. The Document Summarizer Tooltip itself could also be directly useful on content-heavy sites that want instant, inline document previews.

If you’d like to explore the code or try the module yourself, the prototype is available on GitHub at https://github.com/minnur/docs_summarizer_tooltip.

Bring practical, proven AI adoption strategies to your organization, let's start a conversation! We'd love to hear from you.

The event operated on Chatham House Rules, which means I can share what I learned but not attribute specific ideas to specific people. What follows is my synthesis of themes that emerged, filtered through my own perspective. Other attendees will have their own takeaways.

The Business Model Problem

The most intense discussions centered on how AI is challenging traditional agency economics. Some clients are expecting lower prices because "AI makes everything cheaper," even when actual costs tell a different story. Developers using AI should be able to build complex Drupal sites dramatically faster, but advanced models burn through expensive tokens quickly, and quality still requires senior-level review. The math doesn't simplify the way some assume it will.

Nobody has solved this yet. The most honest framing I heard was: treat clients as partners in figuring it out, because we're all learning what AI actually costs in practice. Various experiments are underway with value-based pricing, fixed price with variable scope, and subscription models. No consensus has emerged.

This reminds me of the "outsource everything" wave from years ago. We still feel downward price pressure from that movement, too. What we learned: cheap and fast often means expensive and slow once you factor in the rework. The clients who came to us after failed projects understood that. I suspect the same pattern will play out with projects that exclusively focus on lowering costs with AI-generated vibe code.

The Rise of Disposable Code

Some agencies are leaning hard into "disposable code". If AI lets you build a complete website in a week, why chase perfection? If the client needs something different next month, just rebuild it. Move fast, and don't look back.

This may be a legitimate strategy for certain markets. I'm not dismissing it.

But it's not ours.

Tag1 builds things that last and work well. The disposable approach may work when what you're building is truly standalone, when nothing else depends on it, when institutional knowledge doesn't live in how it's configured. It quickly breaks down when your system is load-bearing infrastructure, when other systems integrate with it. When the cost of "just rebuild it" includes weeks of re-integration, testing, and rediscovering why the previous version made certain decisions.

Our clients tend to be in that second category. We rescue failed Drupal projects as often as we build greenfield sites. We've seen what breaks when speed of delivery and lower hourly rates are prioritized over a maintainable architecture. Prototypes should be disposable. Production infrastructure should not.

Repositioning Drupal

A major debate emerged about Drupal's target audience. Should we keep pitching to marketers, or pivot toward technical decision-makers like CTOs and enterprise architects?

The argument for the shift: marketing websites are increasingly commoditized. AI can vibe-code a marketing microsite. The real stability is in business-critical systems — intranets, support platforms, e-learning, complex integrations. These clients are less likely to cut budgets because the systems are core infrastructure, not discretionary marketing spend. And technical buyers naturally appreciate Drupal's depth.

The emerging consensus wasn't to abandon marketers entirely, but to stop leading with marketing use cases. Lead with business-critical applications where Drupal excels. Let marketing capabilities be a supporting benefit rather than the headline.

This validates where Tag1 has always focused. We do performance engineering and infrastructure for systems that can't go down. That positioning looks stronger, not weaker, as AI commoditizes the simpler work.

Digital Sovereignty

With shifting geopolitics and growing concerns about U.S. cloud dependency, digital sovereignty came up repeatedly as an opportunity for Drupal, especially in Europe. Organizations worry about routing data through U.S. jurisdiction. Compliance requirements are tightening.

Drupal's story here is strong: it is open source, it can run on-premises, there are no hidden dependencies on proprietary services, and you have full control over your data. This matters beyond just regulatory compliance. It's about organizations maintaining genuine ownership of their infrastructure and the ability to switch providers without rebuilding from scratch. And it's about being able to invest in your future.

Open source has always been about working together to make things better. When you build on Drupal, you're not just licensing software — you're joining an ecosystem where improvements flow back to everyone. That shared investment model is the opposite of vendor lock-in, and it's increasingly valuable as organizations think harder about long-term technology risk.

Looking Forward

Drupal has survived 25 years by adapting and leading. The fact that agency leaders are gathering to honestly confront challenges rather than pretending everything is fine gives me confidence we'll figure this out too.

There are big questions to consider:

• Will quality continue to command a premium when AI makes mediocre work cheaper and faster?
• How do we price work when the hours become unpredictable?
• What does junior developer training look like when AI changes the learning curve?

Nobody has definitive answers yet. But asking the questions openly, together, is how the Drupal community has always navigated change. I'm glad to be part of that conversation.

Image by Joris Vercammen from flickr

Project Summary

This project focused on using AI to help resolve a long-standing Drupal core issue: Allow multiple field widgets to not use tabledrag (#2264739). The goal was simple but impactful: make it possible to disable drag-and-drop ordering for specific multi-value field widgets, instead of forcing all of them to be orderable. For years, the only practical option was a brittle patch that touched many core files and often broke on core updates, creating recurring maintenance work that nobody enjoyed. By pushing this core fix forward with AI as a coding partner, the aim is to remove that maintenance burden for good and give site builders more control over the form UX.

The Challenge

The core problem was that Drupal automatically renders multi-value fields in a table with tabledrag behavior, even when reordering is not needed. That table-based structure makes theming harder, complicates responsive layouts, and adds JavaScript overhead for no real benefit in many use cases. Our only workaround was a large, fragile patch from this very issue that had to be kept in sync across Drupal core releases by hand.

This AI Applied project set out to change that by getting a clean, configurable solution into core. The work included writing an improved merge request, updating the issue summary, and adding thorough test coverage, all geared toward making the change easy to understand, review, and eventually commit.

The Technical Overview

The first step was using AI to explore alternatives to the existing proposed fix and to see if there was a better architectural direction. After looking at the options together with AI, we confirmed that the original "orderable" setting approach was still the best fit, and then focused on strengthening it, especially around configuration schema. A key enhancement was the introduction of a shared field.widget.settings.base config schema so widgets could inherit the new orderable boolean cleanly instead of each re-defining it.

Across the project, AI helped with:

• Drafting a clearer, more complete issue summary that explains the problem, motivation, and proposed resolution.
• Building out comprehensive test coverage for affected multi-value widgets so regressions are caught automatically.
• Updating Twig templates and styling for the new non-orderable rendering path, including a simplified field-multiple-value-without-order-form template.
• Getting unstuck on Git and GitLab workflows specific to Drupal core contributions, including issue forks and merge requests.

AI also sped up UI work by letting me paste screenshots into the coding environment so it could adjust CSS more accurately, instead of iterating blindly. Here’s an example:

Over time, I shifted from an earlier extension to a smoother Claude Code setup, supported by installing the ddev-claude-code integration so the assistant could run directly inside the DDEV container with GitLab CLI access.

AI Workflow

A few workflow patterns turned out to be especially helpful on this project:

Dedicated context folder
I added a .claude folder in the repo to hold plans, reference snippets, and docs like the Drupal config schema guide. This let me carry context between sessions and ask the AI to "open and update" specific plan files instead of re-explaining everything.

Plan-driven development
For larger theming or testing tasks, I asked the AI to first write a plan to a file (for example, @.claude/theming-plan-22-nov.md), then execute it step by step, pausing after each item for review. That structure made it much easier to course-correct early rather than cleaning up after a big batch of code.

Voice prompts for speed
Using dictation for prompts in the terminal helped reduce friction for small, repetitive questions or instructions. It was surprisingly effective for "talking through" next steps in a more natural way.

Deep reasoning prompts
Adding a keyword like "ultrathink" in key prompts encouraged the AI to reason more thoroughly before proposing code, which was particularly useful for tricky config and test design work.

On top of that, the ddev-claude-code installation was straightforward and lives right alongside normal Drupal tooling:

composer config extra.drupal-scaffold.allowed-packages --json --merge '["drupal/claude_code"]'
composer require --dev drupal/claude_code
ddev add-on get FreelyGive/ddev-claude-code
ddev restart
ddev claude

Results and Lessons Learned

The issue is still open, but the state of the work is very different from when this effort began. The implementation now uses a clean configuration schema pattern, has broad widget coverage, and includes extensive tests and documentation in the issue summary. Remaining tasks are mostly about theming and documentation polish before the merge request is ready for final review and potential commit.

This was my first serious use of AI for coding, so it naturally took longer than it would now that I have more experience. The upside is that it gave me a strong foundation for using AI as a regular programming tool, and it has since become part of my daily workflow.

If I were starting this same issue again today, I would:

• Ask the AI to generate full test coverage first, across all relevant widgets, to surface edge cases earlier.
• Lean heavily on a "plan mode" flow, approving each step in advance before code is written.
• Independently run and verify tests instead of trusting automated "all tests passed" claims.
• Keep prompts short and focused, especially around test generation, to avoid bloated code that is slow to review.

Real-World Applications

Contributions to Drupal core like this one tend to benefit every Drupal site over time. In this case, having an "Orderable" toggle for multi-value widgets will simplify maintenance by removing the need for a large, fragile patch and will improve form UX options for site builders. It's the kind of change that quietly pays off for years through cleaner upgrades and more flexible theming.

More broadly, this project is a concrete example of how teams can use AI to move long-standing open-source issues forward. It is especially valuable where the work involves a mix of architecture decisions, broad test coverage, and tedious but important updates across multiple components.

Expert Oversight Is Non-Negotiable

One of the most important lessons from this project is that expert oversight is essential. I saw multiple cases where the AI made questionable choices or leaned on weak assumptions in the code, which I only caught because I was reading closely and testing manually. Without that attention, the "help" would have turned into extra rework later.

Used well, AI acts as a powerful accelerator: it drafts, refactors, and suggests, while you stay accountable for direction, quality, and correctness. This project helped me build that mindset and gave me the confidence to make AI a normal part of my engineering toolkit. It also reaffirmed how valuable it is to practice with AI on internal or infrastructure-oriented work like this before applying it in higher-risk contexts.

Bring practical, proven AI adoption strategies to your organization, let's start a conversation! We'd love to hear from you.

Image by FranFrank96 from Shutterstock

Speed up your testing with Deuteros

At Tag1 we like performance.

We also like not being yelled at because a recently released production build introduced a major regression and suddenly the dev team has to scramble to hot-fix the issue.

Our industry has settled for quite a while now on a solid strategy to avoid that scenario: automated testing. It’s not a silver bullet but, when done right, it can hugely increase confidence in making changes to large and/or complex codebases, where even minimal tweaks can sometimes trigger very hard to predict side-effects.

Doing it Right

Automated testing is a vast and complex subject, with some grey areas, especially around terminology; however, there’s a key principle it’s a good idea to stick to: always run your automated tests after any change.

If you are embracing Test Driven Development, you’ll have written new tests covering the changes you are working on before implementing them: this will require running tests multiple times before the task is over. However, even if you are following a more traditional approach, writing test coverage after implementing changes, you will still end up running tests very often.

Admittedly, in the cases above we are talking about a very limited set of tests; however, if tests run slowly, even those will add a significant overhead to development time.

Another widely accepted best practice is to run the entire test suite before merging a change into the project’s repository. This both ensures that the new code behaves as expected and that no regression was introduced in the process. Once again, if tests run slowly, it may take a long time to get feedback, adding further overhead due to context switching.

Aside from the impact on developer experience, which at Tag1 is taken very seriously, the larger the overhead, the harder it is to justify to clients the amount of time spent implementing a change. I guess I don’t need to describe the cascading effects.

The Test Pyramid

An approach that’s very effective in addressing test speed issues is the test pyramid: without going too much into detail, the idea is that a test suite should be organized in a pyramidal shape with multiple layers getting smaller and slower to run as they approach the top.

This commonly translates into having:

• A large amount of fast-running unit tests, covering individual aspects of the codebase.

• A medium amount of integration tests combining multiple units into a consistent (sub)system and testing its behavior.

• A small amount of end-to-end (E2E) tests pulling everything together and testing the business-critical behaviors of the entire codebase.

  

What about Drupal?

At Tag1 we do many things, but Drupal has a special place in our hearts. However, running Drupal tests quickly has often been challenging.

Support for automated tests was initially added to Drupal 7 and, as awesome as it was at the time, it involved running a full site installation in the test setup phase before being able to perform a single assertion. The Simpletest framework focused mainly on UI testing and, even if it was sort of possible to use it to write unit tests, it was like driving to your favorite movie theater during rush hour just to check whether the car battery was wired properly. As you can imagine, it took time.

In Drupal 8 and above the situation vastly improved with the adoption of the PhpUnit testing framework. Multiple types of tests were introduced:

• Browser tests (and their companion WebDriver tests) are the successors to the original Simpletests and are primarily meant to perform UI testing. These are a very good fit to implement E2E tests, as they cover the full request/response scope, albeit being slow, as they still require an installed site and a full Drupal bootstrap.

It should be noted that the introduction by Moshe Weitzman of Drupal Test Traits helped to speed up these tests, as it allows them to run with an existing database, instead of installing an empty site from scratch every time.

use Deuteros\Double\EntityDoubleFactory;
use Deuteros\Double\EntityDoubleDefinitionBuilder;

class MyServiceTest extends TestCase {

  public function testMyService(): void {
    // Get a factory (auto-detects PHPUnit or Prophecy)
    $factory = EntityDoubleFactory::fromTest($this);

    // Create an entity double
    $entity = $factory->create(
      EntityDoubleDefinitionBuilder::create('node')
        ->bundle('article')
        ->id(42)
        ->label('Test Article')
        ->field('field_body', 'Article content here')
        ->build()
    );

    // Use it in your test
    $myService = new MyService();
    $myService->doStuff($entity);

    // These assertions would all pass
    $this->assertInstanceOf(EntityInterface::class, $entity);
    $this->assertSame('node', $entity->getEntityTypeId());
    $this->assertSame('article', $entity->bundle());
    $this->assertSame(42, $entity->id());
    $this->assertSame('Article content here', $entity->get('field_body')->value);
  }

}

class MyNodeTest extends TestCase {

  private SubjectEntityFactory $factory;

  protected function setUp(): void {
    $this->factory = SubjectEntityFactory::fromTest($this);
    $this->factory->installContainer();
  }

  protected function tearDown(): void {
    $this->factory->uninstallContainer();
  }

  public function testNodeCreation(): void {
    $node = $this->factory->create(Node::class, [
      'nid' => 42,
      'type' => 'article',
      'title' => 'Test Article',
      'body' => ['value' => 'Body text', 'format' => 'basic_html'],
      'status' => 1,
    ]);

    // Real Node instance with DEUTEROS field doubles.
    $this->assertInstanceOf(Node::class, $node);
    $this->assertSame('node', $node->getEntityTypeId());
    $this->assertSame('article', $node->bundle());
    $this->assertSame('Test Article', $node->get('title')->value);
    $this->assertSame('Body text', $node->get('body')->value);
  }

}