fidzu : Drupal

As a maintainer of DDEV, Stas Zhuk works behind the scenes to ensure thousands of developers rarely have to think about their local environments. In this interview with The DropTimes, he reflects on reliability, open source responsibility, AI-assisted development, and what it takes to keep critical infrastructure stable even during power blackouts in Ukraine.

20 Feb 2026 5:03pm GMT

Practical guide to using Agentic AI in Drupal development without vibe coding. Learn where AI helps, where it fails, and how to produce reliable code.

20 Feb 2026 12:55pm GMT

A bit of background

Even as a seasoned Drupal developer, when upgrading a Drupal 10.x site to Drupal 11.x you can still encounter a number of weird issues with some older legacy code on the site, which had previously (unbeknownst to you) relied on functionality that has now changed in some way, shape or form due to the upgrade to Drupal Core and its dependencies.

I've just gone through a long morning of debug hell with some JavaScript functionality on a client's site that has previously not had any issues throughout the last few Drupal upgrades. For context, this site was originally built as a Drupal 7 site (all those years ago!), has been entirely rebuilt and migrated to Drupal 9, upgraded to Drupal 10 and now is finally being upgraded to Drupal 11(.3).

The site has a fair number of different JavaScript powered Carousels on the site, and at the time of building the site originally, the 'in vogue' solution for responsive carousels was the excellent Slick Carousel (Github link). I won't go into too many details about this package here, but it's worked well and hasn't caused any issues over the years with previous Drupal upgrades.

The package is dependent on jQuery, and with the move to jQuery 4.x in Drupal core (an optional dependency!), this is where the problems started. Now, it's unfair to expect a package with the last official release of nearly 9 years ago to magically work with a newer version of jQuery which didn't exist at the time (the latest version in 2017 was 3.2 but the plugin was designed around jQuery 2.x), but with the aim of trying to keep within budget for this Drupal 11 upgrade, it was decided to not rewrite the entire functionality of the carousels on this site.

This would have involved having to implement an entirely new (ideally non jQuery dependent!) plugin such as Swiper or Glider and re-writing the DOM structure in all the Twig templates that contain the markup for each of the carousels, tweaking the styling for each carousel, and then re-writing the various JavaScript code to work with the new chosen plugin. If the site only had a simple type of carousel in a singular place, then swapping out would have been a suitable option but the carousels on the site in question are quite complex in some instances, so I decided to go with trying to make Slick work.

The initial problem

Even though there hasn't been an official release of the package since October 2017, there has been work in the master branch in the last few years to make the plugin work with more modern jQuery versions. The previous upgrade to use jQuery 3.x in Drupal core (versions 8.5 and above) didn't actually cause any noticeable issues with the Slick plugin (at least in our use case), but the version 4 upgrade as part of Drupal 11 finally caused us issues.

jQuery 4 has finally removed a number of deprecated APIs, one of which is jQuery.type, which is what Slick used internally in multiple parts of it's code.. without the function available anymore, of course, the JavaScript blows up! Luckily, there have been a number of commits to the master branch of Slick in the last few years and one in 2022, which fixed these deprecated calls, allowing it to work properly with more modern jQuery versions. The commit in question was designed to fix jQuery 3.x issues, but by swapping out deprecated API calls in time, it's enabled it to work (mostly) with 4.x as well.

So to get the master version in place instead of the latest official release (which is very old), I made the following change to our package.json (the project in question uses npm) in the list of dependencies, changing:

"slick-carousel": "^1.8.1",

to (the latest commit hash in the master branch):

"slick-carousel": "github:kenwheeler/slick#279674a815df01d100c02a09bdf3272c52c9fd55",

and then re-installed the projects JS dependencies to bring the new version in.

(For reference, we have some code that will take the version installed here into the node_modules folder and copy it into our sites custom theme directory in an appropriate folder, we then define this as a custom Drupal library and include only where needed.)

With the latest version in place, the JS error with the previously used deprecated API's was gone, yay! But now we had other issues to worry about.

Further problems

The first thing I noticed, now that the JS error was gone, was that a carousel on the homepage looked to be styled incorrectly compared to the version in production. Closer inspection of the DOM revealed that, for some reason now (after not changing any of the invocation calls to the Slick plugin), the slides were now wrapped in two extra divs, instead of the slides themselves getting the slick-slide class (amongst others).

At this point in time, I just assumed this was just a newer behaviour of the updated code of the Slick plugin.. so I set about just making a few quick style changes to the CSS that we had previously not had to take into account of these extra wrapping divs. Later on, I discovered the real reason for these additional wrapping divs... keep reading to find out what it was.

Broken:

Fixed:

This solved this immediate problem, and then I went hunting for the other carousels on the site, which is where things got very interesting (and time-consuming!)

The next carousel's with an apparent problem were on the site's main product page, where one is used on the left hand side (displayed vertically) and acts as a navigation of thumbnails of the 'main' product image gallery that is displayed next to it. The left hand one appeared to be functioning mostly correctly in itself (with a small style issue), but clicking on it would not progress the main slideshow at all! With no JS errors in the console and nothing obviously wrong, cue the debugging rabbit hole....

Going deeper

I won't go into too much detail here of all the paths I went down whilst debugging this but needless to say it involved swapping out the usually minified version of the Slick plugin for the non minified version, using the excellent Chrome JS debugger and stepping through exactly what was going on when Slick was trying to set this carousel up and why it was behaving like it was.

After a while, I finally realised the issue was present when Slick had started initialising itself - after invoking the plugin in the site's code - but before finishing setup. During it's setup, something was going wrong internally with the reference to the slides, which meant they were not copied into the slick-track div and the previously mentioned (new) wrapping divs were there in the DOM, but with no classes on at all.

The JS debugging revealed that the number of $slides being returned from the following Slick code was actually zero!

_.$slides =
  _.$slider
    .children( _.options.slide + ':not(.slick-cloned)')
    .addClass('slick-slide');

This meant the rest of the code that would then do the copying of the slides into the slick-track div (amongst other setup procedures) was failing. But - how could this possibly be? because running some debug code before initialising Slick and checking the number of slides in the DOM was correct...

The devil is in the detail here, and it turns out that the children() selector here is no longer matching my slide container children. But if we didn't change anything about the code that invokes the carousel, why exactly is it broken?

The key lies in the (optional) slide parameter for Slick (which controls the element query to find the slide). The working vertical carousel (amongst others that were working) wasn't using the slide parameter (as the DOM structure for that carousel has the children directly below the slide container), but the broken carousel was using it (due to a specific reason which I won't get into too far into the exact details of, but it involves other markup in the DOM at that specific place for another purpose on the site, so hence needing to specify the selector).

It turns out that if you omit the slide parameter, internally it'll use > div as the selector for slide , and (obviously) if you specify a selector, it'll use that. Because the previous code we had invoking Slick had specified a custom selector, and now (as mentioned above) there were two extra wrapping divs in play, the Slick selector .children( _.options.slide + ':not(.slick-cloned)') was not matching anymore, as my targets for the slide are now inadvertent grandchildren! and after explicitly defining a selector that wasn't the default (> div), it no longer matched.

The real question?

But why are there now two wrapping <div> elements around each slide where previously there were not?

This is the real question that needs answering, now that we understand why the selector wasn't working during the setup for the slides themselves.

By default, Slick has a default setting for the rows of a slideshow of 1 (unless overridden when invoking the plugin). There is internal code inside of Slick in a buildRows() function (called during initialisation of the carousel) that checks if the number of rows is > 0, and if so, it wraps the inner slides in these two divs!

Slick.prototype.buildRows = function() {

    var _ = this, a, b, c, newSlides, numOfSlides, originalSlides,slidesPerSection;

    newSlides = document.createDocumentFragment();
    originalSlides = _.$slider.children();

    if(_.options.rows > 0) {

        slidesPerSection = _.options.slidesPerRow * _.options.rows;
        numOfSlides = Math.ceil(
            originalSlides.length / slidesPerSection
        );

        for(a = 0; a < numOfSlides; a++){
            var slide = document.createElement('div');
            for(b = 0; b < _.options.rows; b++) {
                var row = document.createElement('div');
                for(c = 0; c < _.options.slidesPerRow; c++) {
                    var target = (a * slidesPerSection + ((b * _.options.slidesPerRow) + c));
                    if (originalSlides.get(target)) {
                        row.appendChild(originalSlides.get(target));
                    }
                }
                slide.appendChild(row);
            }
            newSlides.appendChild(slide);
        }

        _.$slider.empty().append(newSlides);
        _.$slider.children().children().children()
            .css({
                'width':(100 / _.options.slidesPerRow) + '%',
                'display': 'inline-block'
            });

    }

};

A quick check of setting rows to 0 in the carousel settings confirmed this was indeed the overall problem, and immediately, my carousels looked and behaved in the way they did before the update. The rows setting is designed for when putting Slick in a "grid mode" where you specify how many rows you want and also how many slides per row you want with the slidesPerRow parameter.

But why are most of the carousels now getting their slides wrapped in rows due to buildRows(), even if I haven't changed the rows parameter from its previous default of 1?

There is a slight confusion when looking at the documentation for the plugin, as it specifies the default value is 1, but also specifies "Setting this to more than 1 initializes grid mode. Use slidesPerRow to set how many slides should be in each row." But this is clearly not true, as we can see a commit that is present in the previous version we were using (1.8.1) had changed this check from if(_.options.rows > 1) to if(_.options.rows > 0) without having updated any of the documentation to say so.

... or is it? The final "gotcha" was that after comparing the minified JS provided in release 1.8.1 with the non-minified JS... the minified JS of 1.8.1 does indeed check if rows > 1, not rows > 0, but the non-minified code checks if rows > 0 - so they don't match, doh! 🤦

Minified code excerpt:

l.options.rows > 1) {

Non-minified code excerpt:

if(_.options.rows > 0) {

The master branch commit I'm running for the jQuery fixes correctly has the minified code matching the un-minified code, both checking rows > 0 - consistency, yey!

What a facepalm moment, eh?

TLDR - The solution:

After running either the updated Slick module code on a Drupal 11.x site that uses jQuery 4.x (or an un-minified 1.8.1 release on an older Drupal site running jQuery 3.x!) If you don't want your carousels to get the extra wrapping divs, which can cause serious selector issues (when you don't really need the 'grid mode' at all!) just pass rows: 0 as an option when initialising your Slick carousel along with the other options, and it'll behave as it did before.

e.g. (a super basic carousel options initialisation)

$('.some-carousel-selector').slick({
  arrows: true,
  dots: true,
  slidesToShow: 3,
  slidesToScroll: 3,
  rows: 0, // <-- This is the key if you don't need the grid mode!
});

If you've made it this far through the article, well done! Hopefully this article saves you from the same few hours of pain that I experienced!

Final thoughts

In hindsight, the amount of time it took to work out exactly what was going on here and write this article up, I could have probably spent getting most of the carousels working with an entirely different plugin and pretty much most of the way there. What should have been a 15-minute job here turned into hours, but sometimes these unexpected things just happen when doing upgrades, especially when some of the code being used is from a different era (2017 wasn't that long ago, was it?) It's sometimes a tricky choice to know when to leave legacy code in place, try and make it work or when it's time to jump ship to another solution.

If it turned out that there were a multitude of Javascript errors with the Slick plugin under jQuery 4.x and no obvious solutions without knowing the inner workings of the plugin, then I probably would have changed tact and started re-implementing the carousels with another solution. But this wasn't the case here, and the issues turned out to be a lot more nuanced.

On the plus side, another project that also needs a Drupal 11 upgrade also uses Slick carousel from a long time ago, so it really should be a 15-minute job on that one with the knowledge gained here :)

20 Feb 2026 11:02am GMT

Dig for gold in Drupal Contrib code

theodore February 20, 2026

20 Feb 2026 2:49am GMT

I've been reading Drupal Core commits for more than 15 years. My workflow hasn't changed much over time. I subscribe to the Drupal Core commits RSS feed, and every morning, over coffee, I scan the new entries. For many of them, I click through to the issue on Drupal.org and read the summary and comments.

That workflow served me well for a long time. But when Drupal Starshot expanded my focus beyond Drupal Core to include Drupal CMS, Drupal Canvas, and the Drupal AI initiative, it became much harder to keep track of everything. All of this work happens in the open, but that doesn't make it easy to follow.

So I built a small tool I'm calling Drupal Digests. It watches the Drupal.org issue queues for Drupal Core, Drupal CMS, Drupal Canvas, and the Drupal AI initiative. When something noteworthy gets committed, it feeds the discussion and diff to AI, which writes me a summary: what changed, why it matters, and whether you need to do anything. You can see an example summary to get a feel for the format.

Each issue summary currently lives as its own Markdown file in a GitHub repository. Since I still like my morning coffee and RSS routine, I also generate RSS feeds that you can subscribe to in your favorite reader.

I built this to scratch my own itch, but realized it could help with something bigger. Staying informed is one of the hardest parts of contributing to a large Open Source project. These digests can help new contributors ramp up faster, help experienced module maintainers catch API changes, and make collaboration across the project easier.

I'm still tuning the prompts. Right now it costs me less than $2 a day in tokens, so I'm committed to running it for at least a year to see whether it's genuinely useful. If it proves valuable, I could imagine giving it a proper home, with search, filtering, and custom feeds.

For now, subscribe to a feed and tell me what you think.

19 Feb 2026 4:14pm GMT

Florida DrupalCamp 2026 opens 20 February in Orlando with a program centered on Drupal Canvas 1.0 and AI-focused training. In a conversation with The Drop Times, organiser Mike Herchel outlined the Canvas-heavy agenda, hands-on workshops, lightning talks, and the camp's long-standing contribution culture.

19 Feb 2026 3:21pm GMT

Join Karen Horrocks and Stephen Musgrave as they introduce the upcoming non-profit summit at DrupalCon 2026 in Chicago. In this comprehensive fireside chat, they explore how AI can be integrated to serve a nonprofit's mission, plus the dos and don'ts of AI implementation. Hear insights from leading nonprofit professionals, learn about the variety of breakout sessions available, and discover the benefits of Kubernetes for maximizing ROI. Whether you're a developer, content editor, or a strategic planner, this session is crucial for understanding the future of nonprofit operations with cutting-edge technology.

For show notes visit: https://www.talkingDrupal.com/cafe015

Topics

• Introduction
• Meet Karen & Stephen
• Karen's Journey to Nonprofit Work
• Deep Dive into Drupal and Nonprofit Websites
• Capella's Approach to Continuous Improvement
• Nonprofit Summit Overview
• Exploring Summit Themes: AI and Resiliency
• Digital Sovereignty and Ethical Considerations
• Additional Breakout Sessions and Topics
• Community Engagement and Registration Details
• Conclusion and Final Thoughts

Stephen Musgrave

Stephen (he/him) is a co-founder, partner and Lead Technologist at Capellic, an agency that build and maintains websites for non-profits. Stephen is bullish on keeping things simple - not simplistic. His goal is to maximize the return on investment and minimize the overhead in maintaining the stack for the long term.

Stephen has been working with the web for over 30 years. He was initially drawn to the magic of using code to create web art, added in his love for relational databases, and has spent his career building websites with an unwavering commitment to structured content.

When Stephen isn't at his desk, he's often running to and swimming in Barton Springs Pool, getting a bit too wound-up at Austin FC games, and playing Legos with his little one.

Karen Horrocks

Karen (she/her, karen11 on drupal.org and Drupal Slack) is a Web and Database Developer for the Physicians Committee for Responsible Medicine, a nonprofit dedicated to saving and improving human and animal lives through plant-based diets and ethical and effective scientific research.

Karen began her career as a government contractor at NASA Goddard Space Flight Center developing websites to distribute satellite data to the public. She moved to the nonprofit world when the Physicians Committee, an organization that she supports and follows, posted a job opening for a web developer. She has worked at the Physicians Committee for over 10 years creating websites that provide our members with the information and tools to move to a plant-based diet.

Karen is a co-moderator of NTEN's Nonprofit Drupal Community. She spoke on a panel at the 2019 Nonprofit Summit at DrupalCon Seattle and is helping to organize the 2026 Nonprofit Summit at DrupalCon Chicago.

Resources

Nonprofit Summit Agenda: https://events.drupal.org/chicago2026/session/summit-non-profit-guests-must-pre-register Register for the Summit (within the DrupalCon workflow): https://events.drupal.org/chicago2026/registration Funding Open Source for Digital Sovereignty: https://dri.es/funding-open-source-for-digital-sovereignty NTEN's Drupal Community of Practice Zoom call (1p ET on third Thursday of the month except August and December): https://www.nten.org/drupal/notes Nonprofit Drupal Slack Channel: #nonprofits on Drupal Slack

Guests

Karen Horrocks - karen11 www.pcrm.org Stephen Musgrave - capellic capellic.com

19 Feb 2026 12:00pm GMT

19 Feb 2026 9:15am GMT

Stephen Musgrave appeared on TD Cafe episode 15 with Karen Horrocks, a co-organizer of the summit, to talk about what to expect when attending the Nonprofit Summit at DrupalCon Chicago. They dive into the agenda in detail, share anecdotes, and urge you to attend!

19 Feb 2026 5:00am GMT

Image

Imagen

18 Feb 2026 11:23pm GMT

DDEV v1.25.0 is here, and the community response has been strong. This month also brought three new training blog posts and a survey result that speaks for itself.

What's New

• DDEV v1.25.0 Released → Improved Windows installer (no admin required), XHGui as default profiler, updated defaults (PHP 8.4, Node.js 24, MariaDB 11.8), faster snapshots with zstd compression, and experimental rootless container support. Read the release post↗
• New ddev share Provider System → Free Cloudflare Tunnel support, no login or token required. A modular provider system with hooks and CMS-specific configuration. Read more↗
• Mutagen in DDEV: Functionality, Issues, and Debugging → Based on the January training session, this post covers how Mutagen works, common issues, and the new ddev utility mutagen-diagnose command. Read more↗
• Xdebug in DDEV: Understanding and Troubleshooting Step Debugging → How the reverse connection model works, IDE setup for PhpStorm and VS Code, common issues, and the new ddev utility xdebug-diagnose command. Read more↗

CraftQuest Survey: DDEV at 72%

The 2026 CraftQuest Community Survey↗ collected responses from 253 Craft CMS developers and found DDEV at 72% market share for local development environments. The report notes: "This near-standardization simplifies onboarding for newcomers, reduces support burden for plugin developers, and means the ecosystem can optimize tooling around a single local dev workflow."

Conference Time!

I'll be at Florida Drupalcamp this week, and will speak on how to use git worktree to run multiple versions of the same site. I'd love to see you and sit down and hear your experience with DDEV and ways you think it could be better.

Then in March I'll be at DrupalCon Chicago and as usual will do lots of Birds-of-a-Feather sessions about DDEV and related topics. Catch me in the hall, or let's sit down and have a coffee.

Community Highlights

• ddev-mngr → A Go-based command-line tool with an interactive terminal UI for managing multiple DDEV projects at once - start, stop, check status, and open URLs across projects. With this add-on Olivier Dobberkau inspired a new TUI approach for DDEV core as well! View on GitHub↗
• TYPO3 DDEV Agent Skill → Netresearch built an Agent Skill (compatible with Claude Code, Cursor, Windsurf, and GitHub Copilot) that automates DDEV environment setup for TYPO3 extension development, including multi-version testing environments for TYPO3 11.5, 12.4, and 13.4 LTS. View on GitHub↗
• Using Laravel Boost with DDEV → Russell Jones explains how to integrate Laravel Boost (an official MCP server) with DDEV, giving AI coding agents contextual access to routes, database schema, logs, and configuration. Read on Dev.to↗
• Laravel VS Code Extension v1.4.2 → Now includes Docker integration support and a fix for Pint functionality within DDEV environments. Read more↗

Community Tutorials from Around the World

• Getting Started with DDEV for Drupal Development → Ivan Zugec at WebWash published a guide covering installation, daily commands, database import/export, Xdebug setup, and add-ons. Read on WebWash↗
• Environnement de développement WordPress avec DDEV → Stéphane Arrami shares a practical review of adopting DDEV for WordPress development, covering client projects, personal sites, and training (in French). Read more↗

What People Are Saying

"I was today years old when I found out that DDEV exists. Now I am busy migrating all projects to Docker containers." - @themuellerman.bsky.social↗

"ddev is the reason I don't throw my laptop out of the window during local setup wars. one command to run the stack and forget the rest. simple as that." - @OMascatinho on X↗

v1.25.0 Upgrade Notes and Known Issues

Every major release brings some friction, and v1.25.0 is no exception. These will generally be solved in v1.25.1, which will be out soon. Here's what to watch for:

• deb.sury.org certificate expiration on v1.24.x → The GPG key for the PHP package repository expired on February 4, breaking ddev start for users still on v1.24.10 who needed to rebuild containers. We pushed updated images for v1.24.10, so you can either ddev poweroff && ddev utility download-images or just go ahead and upgrade to v1.25.0, which shipped with the updated key. Details↗
• MariaDB 11.8 client and SSL → DDEV v1.25.0 ships with MariaDB 11.8 client (required for Debian Trixie), which defaults to requiring SSL. This can break drush sql-cli and similar tools on MariaDB versions below 10.11. Workaround: add extra: "--skip-ssl" to your drush/drush.yml under command.sql.options, or upgrade your database to MariaDB 10.11+. Details↗

• MySQL collation issues → Importing databases can silently change collations, leading to "Illegal mix of collations" errors when joining imported tables with newly created ones. Separately, overriding MySQL server collation via .ddev/mysql/*.cnf doesn't work as expected. #8130↗ #8129↗
• Inter-container HTTP(S) communication → The ddev-router doesn't always update network aliases when projects start or stop, which can break container-to-container requests for *.ddev.site hostnames. Details↗
• Downgrading to v1.24.10 → If you need to go back to v1.24.10, you'll need to clean up ~/.ddev/traefik/config - leftover v1.25.0 Traefik configuration breaks the older version. Details↗
• Traefik debug logging noise → Enabling Traefik debug logging surfaces warning-level messages as "router configuration problems" during ddev start and ddev list, which looks alarming but is harmless. Details↗
• ddev npm and working_dir → ddev npm doesn't currently respect the working_dir web setting, a difference from v1.24.10. Details↗

As always, please open an issue↗ if you run into trouble - it helps us fix things faster. You're the reason DDEV works so well!

DDEV Training Continues

Join us for upcoming training sessions for contributors and users.

• February 26, 2026 at 10:00 US ET / 16:00 CET - Git bisect for fun and profit Add to Google Calendar • Download .ics

• March 26, 2026 at 10:00 US ET / 15:00 CET - Using git worktree with DDEV projects and with DDEV itself Add to Google Calendar • Download .ics

• April 23, 2026 at 10:00 US ET / 16:00 CEST - Creating, maintaining and testing add-ons 2026-updated version of our popular add-on training. Previous session recording↗ Add to Google Calendar • Download .ics

Zoom Info: Link: Join Zoom Meeting Passcode: 12345

Sponsorship Update

After the community rallied in January, sponsorship has held steady and ticked up slightly. Thank you!

Previous status (January 2026): ~$8,208/month (68% of goal)

February 2026: ~$8,422/month (70% of goal)

If DDEV has helped your team, now is the time to give back. Whether you're an individual developer, an agency, or an organization - your contribution makes a difference. → Become a sponsor↗

Contact us to discuss sponsorship options that work for your organization.

Stay in the Loop-Follow Us and Join the Conversation

• Blog↗
• LinkedIn↗
• Mastodon↗
• Bluesky↗
• Discord↗

Compiled and edited with assistance from Claude Code.

18 Feb 2026 7:49pm GMT

A proposal to add an AGENTS.md file to Drupal core has been closed as "works as designed," but not before prompting a wider debate about AI-assisted contributions, disclosure policies, and reviewer fatigue. While some contributors see structured agent guidelines as necessary guardrails, others warn that tooling alone cannot resolve deeper process and governance challenges.

18 Feb 2026 1:00pm GMT

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.

18 Feb 2026 12:00am GMT

17 Feb 2026 6:15pm GMT

Your Drupal 7 site has reached its end of life as of January 2025. If you're planning a move to Drupal 10 or 11, this blog will help you prepare for a smooth and well-planned migration.

17 Feb 2026 9:15am GMT

You know the drill. You visit the Drupal Status Report to check if anything needs attention, and you're greeted by a wall of warnings you've seen dozens of times before.

Some warnings are important. Others? Not so much. Maybe you're tracking an update notification in your Gitlab and don't need the constant reminder. Perhaps there's a PHP deprecation notice you're already aware of and planning to address during your next scheduled upgrade. Or you're seeing environment-specific warnings that simply don't apply to your infrastructure setup.

The noisy status report problem

The problem is that all these warnings sit alongside genuine issues that actually need your attention. The noise drowns out the signal. You end up scrolling past the same irrelevant messages every time, increasing the chance you'll miss something that matters.

Over time, you develop warning blindness. Your brain learns to ignore the status report page entirely because the signal-to-noise ratio is too low. Then, when a genuine security update appears or a database schema issue emerges, it gets lost in the familiar sea of orange and red.

This problem multiplies across teams. Each developer independently decides which warnings to ignore. New team members have no way to know which warnings matter and which ones are environmental noise. The status report becomes unreliable, defeating its entire purpose.

…

17 Feb 2026 8:11am GMT