fidzu : Drupal

Today we are talking about Drush, Core Contributions, and Drupal's Past with guest Moshe Weitzman. We'll also cover Cache Metrics as our module of the week.

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

Topics

• Moshe Updates and Clients
• Maintaining Drush Long Term
• Locale Performance Overhaul
• CLI in Core Initiative
• Which Commands Make the Cut
• Roadmap Contrib Commands
• Moving Commands Technical Hurdles
• How to Help From AI Initiative
• DDEV Add-ons for Local CI
• MySQL Toolkit Database Images
• Testing With Real Databases
• Devel Module Status
• Organic Groups Origins
• Where Ideas Come From
• Finding Drupal Early Days
• Release Cadence And Backward Compatibility
• Avoiding Maintainer Burnout
• Maintaining With AI And Xdebug

Resources

• Drush's Final Act
• Drupal cli issue
• DDEV addons
  • https://github.com/ddev/ddev-drupal-contrib
  • https://github.com/weitzman/ddev-mtk
  • https://www.drupal.org/project/dtt

Guests

Moshe Weitzman - weitzman.github.io moshe-weitzman

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Scott Falconer - managing-ai.com scott-falconer

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted insights into how cache is working on your Drupal site? There's a module for that.
• Module name/project name:
  • Cache Metrics
• Brief history
  • How old: created in Oct 2019 by Moshe Weitzman (moshe weitzman), today's guest, a consistent core contributor, a member of the security team, and one of the rare few with a two-digit user id on drupal.org
  • Versions available: 2.0.3, 2.1.0, and 2.2.0, the last of which works with Drupal 8.7.7, 9, 10, and 11
• Maintainership
  • Actively maintained
  • Security and test coverage
  • Documentation - in depth README
  • Number of open issues: 2 open issues, 1 of which is a bug, but is marked fixed
• Usage stats:
  • 37 sites
• Module features and usage
  • With this module enabled, your Drupal site will log all cache tag invalidations
  • Additionally, cache tag invalidations will be sent to New Relic as custom events, where you can use the rich reporting tools available to mine for further insights. Many Drupal hosting options include New Relic out-of-the-box, and there's a free tier you can use if you're self-hosting, so this a reporting tool lots of Drupal sites can use
  • Cache hits and misses are also sent to New Relic, so you can investigate things like cache misses as a percentage by cache bin
  • Finally, the aforementioned README also includes information about how to use a different analytics provider, in case New Relic doesn't meet your specific needs
  • Drupal sites probably don't need this kind of visibility on a regular basis, but if you're troubleshooting any kind of cache-related issue, this could be really useful

08 Jun 2026 6:00pm GMT

LocalGov Drupal Camp 2026 will bring together public-sector practitioners, developers and digital service teams at Sheffield Hallam University on 11-12 June 2026. Speaker previews released ahead of the event show a programme centred on practical implementation experiences, artificial intelligence governance and product-led approaches to digital services, with knowledge sharing and peer learning emerging as common themes across multiple sessions.

08 Jun 2026 2:28pm GMT

AI coding agents like Claude Code and OpenAI Codex tend to choose the path that is cheapest to complete. They work within a budget of tokens, context, time, tools, and permissions. Every step spends from that budget: reading documentation, installing software, running it, configuring it, changing it, and fixing errors.

For Open Source, this is a rare opportunity. AI agents could become its biggest adoption engine yet. While that should energize Open Source communities, it should also make proprietary vendors deeply uncomfortable.

Many proprietary software vendors have spent years optimizing for a human buyer journey: capture a lead, qualify the buyer, force a signup, offer a demo or trial experience, ask for a credit card, schedule a sales call.

Humans may grumble but keep going. To an AI coding agent, these are blockers, not buying steps.

Open Source starts from a different place. AI agents can read the source code, run it locally, and change it without asking anyone for permission. That does not guarantee adoption, but it removes the proprietary gates that slow agents down.

But being Open Source is not enough. Open Source removes the "permission barriers", but it can still have "execution barriers". If an Open Source project is hard to install, configure, extend, debug, or verify, an agent may choose an easier Open Source project instead.

In that sense, AI agents amplify an old truth about software adoption: the best software does not always win. The software with the easiest path to a working result often does.

But AI agents amplify that truth through "silent rejection". A human evaluator might complain, ask for help, file an issue, or write an angry Reddit post. An AI agent just tries another path. You may never know your software was considered and rejected.

Easy is more than low friction

If you want your project to be adopted, you have to make the best path the easiest one to complete.

And "easy" means more than low friction. For an AI agent, there are at least three costs: friction, abstraction, and verification.

Friction is the cost of getting to a system the agent can run and change. Some friction comes from the environment: runtimes, containers, databases, package managers, local services, and setup choices that must be installed or configured before useful work can begin. Some comes from access and authorization: private repositories, account creation, credentials, and API keys.

Abstraction is the cost of figuring out what to do next. Once the software is running, the agent still has to know which modules to use, how to structure the data, which settings to apply, which conventions to follow, and how the pieces should fit together. A good site template, recipe, or scaffold packages that expertise so the agent can take several correct steps at once instead of reconstructing the path from scratch.

Verification is the cost of knowing whether the work succeeded. Tests, clear errors, inspectable state, and fast debugging cycles help the agent compare what happened with what should have happened. As I wrote in AI rewards strict APIs, agents do not struggle with complexity; they struggle with ambiguity.

Each cost burns tokens, meaning the AI agent has to spend more of its limited context and reasoning budget reading documentation, comparing different options, or recovering from failed attempts.

What helps agents helps people

This is not just an AI problem. People have always preferred software that is easy to get running, gives them a clear path forward, and tells them when something worked. AI agents make the same preference more obvious because they have even less room for trial and error.

Developer Experience (DX) makes software easier for developers to evaluate, build with, and maintain. Agent Experience (AX) makes software easier for agents to install, modify, and verify.

In practice, the overlap is large. Better scaffolding, clearer errors, faster setup, opinionated best practices, and reliable tests help agents, but they also help developers, evaluators, and contributors.

Open Source still has to compete

The cheap-to-run advantage will not belong to Open Source forever. Proprietary vendors and SaaS companies are adding free tiers, programmatic access, and Model Context Protocol servers that give agents tools and context with less friction.

Open Source's structural advantage is about to expand, but it will concentrate in the projects that are easiest for agents to understand, run, and improve.

Every software project will have to earn its place in the agent flow. Being open will get you considered, but being easy to discover, install, inspect, modify, and verify will get you chosen.

08 Jun 2026 7:13am GMT

Hello, Drupal community. The first week of June showed Drupal moving from AI experimentation toward a more practical question: how AI-assisted work should be trusted, tested, and governed.

Several stories this week explored that shift. Amber Matz examined trust and expertise in AI-assisted open-source contributions, while a live experiment tested AI-assisted Drupal 7 migration. The discussion is no longer only about whether AI can be used in Drupal workflows. It is now about reliability, accountability, and the points where human expertise must remain in control.

That concern extends beyond Drupal. Recent coverage of Drupal AI 1.4.0, GitHub's outcome-based validation framework for AI agents, and Carlos Ospina's agentic recipes concept points to the same operational problem. AI systems now require governance, evaluation, and clear boundaries alongside technical experimentation.

Sustainability formed the second major thread. The Drupal Association's support for Acquia's Fair Trade Initiative reopened a familiar question about how open-source projects fund shared infrastructure while remaining community-driven. As more digital services depend on open-source software, stewardship, contribution, and long-term maintenance are becoming increasingly inseparable from technical progress.

Community activity also remained visible. Reflections from DrupalSouth 2026 highlighted collaboration and local momentum, while preparations for DrupalCon Rotterdam 2026 and the return of DrupalCamp Italy showed continued investment in face-to-face knowledge sharing.

Practical site management stories rounded out the week. Coverage included new approaches to file management through the Drupal Form File Usage module and fresh security guidance from Acquia. These updates show how Drupal's surrounding tools continue to mature while supporting day-to-day operational needs.

The coming weeks are likely to bring more examples of AI entering Drupal development workflows. The stronger test will be how clearly those workflows are evaluated, explained, and governed. Open-source projects can adopt automation without losing transparency only when human responsibility remains visible.

Additional developments from across the Drupal ecosystem were published during the week. Readers can follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook for ongoing updates. The publication is also active on Drupal Slack in the #thedroptimes channel.

Allen Jason
Junior sub-editor
The Drop Times

08 Jun 2026 5:46am GMT

In the last article in this series I looked at creating a link directory on a Drupal site. In that article I looked at how I set up the links and took screenshots of the sites using a headless Chromium browser as the links were added.

The issue I had was that when I used headless Chromium to take screenshots of the sites the success rate was not very high. In these days of AI attacks, site captcha checks, and cookie popups it turned out to be quite difficult to take a clean screenshot of a site without being blocked either by a CDN or a cookie popup. In fact, most of the time the screenshot would be just a CDN error page.

I therefore looked for a different mechanism. Since I wanted to take a screenshot of a website it made sense to me to use a browser to do this, and because I am already using a browser why not get the browser I'm using to take the screenshot. After a bit of research I realised that creating browser extensions to do this was actually pretty simple. Plus once the screenshot has been taken I can post this to the Drupal site using a REST resource.

The only niggle was that I needed the screenshot to be at a set dimension, since all the link images on the site also have that dimension. That turned out to be slightly more challenging.

In this article we will look at setting up a rest resource to generate (or update) links, and then creating a Chrome extension to take a screenshot of a site at a set resolution.

First, let's look at creating the REST resource in Drupal.

Creating A REST Resource

This needs to accept the data from the Chrome extension and generate a Link content entity using that data.

Read more

07 Jun 2026 6:15pm GMT

For years, prefetching made me uneasy. It can make websites feel faster, but it also asks visitors to spend bandwidth, CPU, memory, and battery on pages they may never open. That always felt a little wasteful, and maybe even a little disrespectful.

A couple months ago, while updating my HTTP header analyzer, I added support for the Speculation-Rules HTTP header. Learning about the Speculation Rules API inspired me to try it on my own blog.

The idea is simple: a page can give the browser a small JSON rule set that says which links are safe to prefetch, and when. Those rules can live directly in the HTML using <script type="speculationrules">, or in an external file referenced by the Speculation-Rules HTTP header.

For my blog, I added the rules directly to the HTML of every anonymous page request:

<script type="speculationrules">
{
  "prefetch": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": { "href_matches": "/search*" } }
      ]
    },
    "eagerness": "conservative"
  }]
}
</script>

The rule tells browsers that any same-origin link is safe to prefetch, except for paths under /search*.

The eagerness: conservative setting fires the prefetch on pointerdown or touchstart, meaning the browser only starts prefetching once the user begins to click or tap a link. There are more aggressive options, such as prefetching when a link becomes visible or when a user hovers over it.

Some of you might point out that browsers have supported prefetching for years through the older <link rel="prefetch"> tag. That is true, but I've never loved it.

Traditional prefetching is great when the next page is highly predictable, like the next step in a checkout flow or setup wizard.

On many websites, including my blog, it's anyone's guess what a visitor will click next. Sometimes you can make a smarter guess, but it is still a guess.

And when you guess wrong, visitors spend bandwidth, battery, and compute on pages they never visit. Multiply that across millions of sites and visitors, and those speculative requests add up.

So why implement Speculation Rules? With eagerness: conservative, the browser waits until the user has already started an action. At that point, the navigation is no longer a vague prediction. It is very likely to happen.

Speculation Rules also respect Battery Saver and Data Saver modes. If a device is low on battery, memory constrained, or trying to conserve data, the prefetching is skipped.

So is prefetching still worth it when the user has already started to click? I think so. With eagerness: conservative, the browser only gets a small head start but something is better than nothing.

Browsers already do some speculative loading on their own without Speculation Rules, but only for high-confidence destinations, like the address bar suggestion you are typing toward.

But they will not prefetch arbitrary links on a page, and for good reason. Prefetching /logout, for example, would sign the visitor out, even if they change their mind and never complete the click or hit Enter.

That is why Speculation Rules can be useful. You can tell the browser which paths are safe and which to leave alone.

In short, Speculation Rules changed my mind because they make prefetching feel more responsible: don't prefetch too much, don't prefetch too early, and only give the browser a safe hint when the user's intent is clear.

05 Jun 2026 2:37pm GMT

For organisations still running Drupal 7, the challenge is often less about whether to upgrade and more about how to modernise without disrupting critical business operations. Niels de Feyter, founder and lead developer of CodeLift, argues that successful upgrades depend on preserving a system's observable behaviour while modernising its underlying platform. In this interview with The Drop Times, he discusses verification, migration complexity, ageing infrastructure, AI-assisted development, and the risks organisations face as legacy systems grow older.

05 Jun 2026 2:03pm GMT

Explore the future of enterprise AI at The AI Summit London 2026. See how open-source architecture is becoming the foundation for secure, scalable, and future-ready enterprise AI.

05 Jun 2026 10:00am GMT

Drupal 11.4 is the next minor release in the 11.x branch, with a stable launch planned for the week starting June 22, 2026. It doesn't break backward compatibility for public APIs, but it brings plenty of concrete improvements: PHP attribute routing, a new bootstrap based on Symfony Runtime, Brotli compression for assets, SEO-oriented robots.txt changes, and a whole list of deprecations worth handling in custom modules. Below I walk through what actually changes compared to Drupal 11.3.

05 Jun 2026 4:38am GMT

The New Workflow Modeler: Revolutionary, Not Just Improved

Jürgen Haas Thu 4 Jun 2026 - 13:45

04 Jun 2026 11:45am GMT

Mike Anello and Rod Martin discuss the sharp decline in demand for beginner Drupal training. Drawing on data from their businesses, events, and other training providers, they explore factors including AI-driven self-service learning, Drupal's growing complexity for newcomers, and limited community-wide marketing. They also discuss how initiatives like Drupal AI and broader promotion efforts could help attract and support the next generation of Drupal users.

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

Topics Mike Anello

Mike, widely recognized by his Drupal.org username "ultimike," is a prominent figure in the Drupal community with over 20 years of experience as a developer, educator, and community leader. As the co-founder and vice president of DrupalEasy, a Florida-based training and consulting firm, he has been instrumental in shaping the careers of countless Drupal professionals through comprehensive programs like Drupal Career Online and Professional Module Development. Mike's contributions extend beyond education. He has been deeply involved in the Drupal ecosystem, previously serving as a core contributor to the Migrate module, co-maintaining several contributed modules, and actively participating in issue queues and documentation efforts. His leadership roles include membership in the Drupal Community Working Group and the Conflict Resolution Team, as well as organizing the Florida Drupal Users' Group and Florida DrupalCamp for over a decade. As the host of the long-running DrupalEasy Podcast, MIke provides insights into Drupal development, community news, and interviews with key contributors, fostering a sense of connection and ongoing learning within the community (DrupalEasy). His dedication to mentoring and community building has made him a respected and influential voice in the Drupal world.

Rod Martin

Rod has introduced more than 50,000 people to Drupal through his live and video training since 2011. He owns NavigateTomorrow and runs DrupalHelps - a site for site builders to get information and quick starts to using Drupal in their own businesses or non-profits.

Guests

Mike Anello - DupalEasy ultimike Rod Martin - DrupalHelps.com imrodmartin

Resources

The slow decline of beginner Drupal training The Site Builder Breakthrough - From Confusion to Confidence Drupal AI Initiative Promote Drupal

04 Jun 2026 4:01am GMT

A proposal to introduce "Module Families" on Drupal.org aims to help users compare contributed modules that solve similar problems through structured comparison pages and ecosystem signals. The proposal argues that Drupal's challenge is not excessive choice but insufficient context, an issue that becomes more important as Drupal CMS introduces curated module selections and opinionated workflows.

03 Jun 2026 2:06pm GMT

With the Commerce Recurring module, any Drupal Commerce website can create recurring orders that users can manage directly in Drupal. This is useful for donations, subscriptions, and memberships, especially for selling access to content. We created the module well before payment gateways like Stripe had robust recurring solutions in place with full webhook support.

However, the market has now evolved, partly because of the SaaS explosion. If you're looking for a solution to recurring payments, you have many options to implement them reliably beyond Commerce Recurring.

While before we would always lean toward using a native Drupal solution for recurring billing, now the answer is more nuanced. How should you implement recurring payments in Drupal Commerce?

Start by ruling out what you don't need

Before diving into frameworks and modules, it's worth asking whether you actually need Drupal Commerce at all for your subscription use case.

If your requirements are straightforward, like selling access to a user role that unlocks gated content, you could implement that with nothing more than Stripe Checkout and a webhook listener. A customer hits Stripe's hosted checkout page, subscribes, and your Drupal site receives a webhook notification. You grant the role. When Stripe tells you the subscription was canceled or a payment failed, you revoke it. No shopping cart, no checkout flow, no Commerce module required.

Some use cases genuinely are that simple, and adding unnecessary complexity doesn't serve anyone.

Read more

03 Jun 2026 1:45pm GMT

"Argo-nizing" Our Platform for AI Development

John Locke Tue, 06/02/2026 - 10:00

Dev Corner

02 Jun 2026 5:00pm GMT

Our automated tests for a Drupal 11 upgrade failed with a cryptic error: Recursive router rebuild detected. A bit like when cron warns about it already running, this meant something had started a router rebuild, but without finishing successfully, before another rebuild of routing information was triggered. My solution was pretty specific to our context - but what might be interesting here is how I identified what had led to this problem.

The context

We run automated functional tests on this client project as regression tests, to show that various bespoke functionality still works, as changes are introduced. These are run in a DDEV instance inside a github action, via phpunit (and the DDEV Selenium Standalone Chrome add-on). To keep the maintenance of these tests easy and as portable as possible, we just use core's existing phpunit.xml.dist file as their configuration. The tests install a fresh Drupal site, importing our project's ordinary configuration along the way, and then perform actions in a headless browser, clicking on elements just like a site visitor would, etc. During work to upgrade from Drupal 10 to 11, tests started failing whilst just installing Drupal. Nothing to do with our custom functionality. What gives?!

The easy bit

At least we had a clear error message to go by. Enable xdebug, stick a breakpoint on the line which throws the exception, and run to the line. (Thanks DDEV for getting us that far easily enough!) So that's in the rebuild() method of core's \Drupal\Core\Routing\RouteBuilder class. Simple enough to confirm there that, yes, the $this->building property shows a previous attempt to rebuild the routes has happened. But how can we see what that was?

At this point, the call stack shows us all the 'parent' callers of this method, but it's not a truly recursive call like the error implies: there's no smoking gun suggesting something incorrectly called back into rebuild(). Traversing through the parents, the most notable thing was just to see that this call is part of the install_finished step of installing Drupal. Seems reasonable that Drupal would build up its record of routes once everything has been installed. So what earlier installation task had somehow started a router rebuild, without getting to the end of the rebuild() method where the $this->building property is reset?

I wanted to identify what had triggered the earlier incomplete router rebuild, regardless of why that hadn't completed successfully. (In post-mortem, I found some unrelated exception had been thrown, sending control flow away before the $this->building property was reset, but the exception was handled 'gracefully' and installation innoncently continued. That exception could be avoided, but the principle remains that some kinds of exception should be acceptable and allow installation to continue on successfully.)

The magic

So the parent function calls, and 'grandparent' calls, couldn't tell me much. If the function stacks were CSS, I'd be building mad :has() selectors for the previous sibling of a grandparent (or some other ancestor). Something like a Great Uncle or Great Aunt, perhaps? Anyway - let's call it that - I needed to debug the Great Uncle Stack!

The diagram above illustrate this, as a graph of control flow (to be read depth-first, left-to-right). The exception is only thrown on the second call to rebuild() (the right branch in the diagram), but the call we need to understand is at the end of the first stack (the left branch), which wouldn't be available to us during the second call. We want to know what triggered that first rebuild() call.

Here's how I solved this: use a static variable to record each previous entry into the method; i.e. the full stack traces, with PHP's internal debug_backtrace() function:

static $stacks = [];
$stacks[] = debug_backtrace();

Then during the breakpoint debugging session, that static store of stack traces can be inspected.

So when my breakpoint landed, I could then see what the call stack was for when this rebuild() method had been previously called! In the screenshot above, the $stacks variable holds two stack traces: the first will contain the cause of the mysterious first failed call to rebuild(), somewhere in its stack of 42 function calls. (The second value in $stacks is just the stack trace up to this breakpoint, about to throw the exception.) So traversing through that first stack showed a specific install task and function that had triggered this.

The surprise

Bizarrely, the culprit was core's menu_link_content module! It has an entity_predelete hook implementation which, quite sensibly, wants to remove any menu links pointing to entities being deleted. But to do that, of course it needs to get information about which URLs an entity has which a menu link could point to - and that means route information is needed.

Of course, whilst installing Drupal, we didn't have any such menu links we needed to care about! But we do have entities that get deleted, so that hook is invoked. Our ordinary configuration for the project is imported as part of installing Drupal, which actually recreates some config - i.e. deleting before creating again the same config, just with a different UUID. That's because various config is created by default in installations without a specific UUID, and then gets switched to match the UUIDs in the config for our project.

Some of that config is created by Drupal core itself - for example, date formats from the system module - and others from quite reliable modules, like token. We could go round patching each individually to avoid them installing config that we will only recreate later during installation. But that wouldn't be very maintainable, and doesn't respect the quite reasonable default installation process.

Instead we crippled the specific functionality for finding menu links to delete, just during installation, with a simple hook_module_implements_alter():

/**
 * Implements hook_module_implements_alter().
 */
function MYPROFILE_module_implements_alter(&$implementations, $hook) {
  if ($hook === 'entity_predelete') {
    // During site installation, we have no menu links to clear up. Avoid
    // menu_link_content triggering router rebuilds on deleting entities.
    try {
      if (
        function_exists('install_verify_completed_task')
        && install_verify_completed_task()
      ) {
        unset($implementations['menu_link_content']);
      }
    }
    catch (\Drupal\Core\Installer\Exception\AlreadyInstalledException $e) {
      // Allow menu_link_content to react to entity deletion.
    }
  }
}

Our automated tests now pass, with Drupal installing successfully. Mystery solved and new debugging technique unlocked!

02 Jun 2026 3:26pm GMT

02 Jun 2026 1:23pm GMT