fidzu : Drupal

"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

02 Jun 2026 11:25am GMT

Attending Drupal Dev Days Athens as both a participant and first-time international speaker gave Francesco Maria Battaglia a new perspective on the Drupal ecosystem. Reflecting on the experience, he writes about mentorship, community support, volunteer contributions, and the sense of belonging that continues to draw people into open source communities.

02 Jun 2026 10:45am GMT

02 Jun 2026 9:52am GMT

Slow Drupal site costing you rankings? Learn some impactful fixes that work - caching, images, hosting, and the Drupal 11.3 improvements worth knowing about. Included is a real case study going from a performance score of 65 to 98!

02 Jun 2026 9:21am GMT

This morning, Salesforce announced its plan to acquire Contentful.

Congratulations to Sascha Konietzke, Paolo Negri, and the whole Contentful team. They spent 13 years building Contentful into one of Europe's most visible enterprise software companies. Salesforce buying Contentful is real validation of the product, customers, and team they built.

The deal makes sense for both Salesforce and Contentful. Salesforce has long had a CMS-shaped hole in its product offering, and Contentful fills it with a mature, enterprise-ready SaaS product.

To me, the more important question isn't whether the acquisition makes strategic sense, but what it means for digital sovereignty. It's a textbook example of why "Buy European" isn't enough.

Before I go further, let me be clear about where I'm coming from. I founded Drupal and still lead the project, and I co-founded Acquia, the company built around Drupal, where I'm Executive Chair. So when I argue that this deal exposes a problem, you should factor in that Open Source is both my life's work and my livelihood.

Contentful is a German company, Contentful GmbH, registered in Berlin. For over a decade it has been a flagship European software company.

If the acquisition closes, it becomes part of Salesforce, a US corporation, and falls under US law.

For many of Contentful's customers, this acquisition will be a non-event. For governments, public institutions, and regulated industries, it exposes a harder truth: a vendor being European today is no guarantee it stays European tomorrow.

A practical example is the US CLOUD Act. Many people may not know about it, but it becomes relevant anytime a non-US vendor is acquired by a US company.

In plain English, the CLOUD Act means that US authorities can require any US company to disclose data it controls. That can apply even if its data is stored in Europe, managed by a European team, or running on European infrastructure.

This is not a hypothetical concern. The law came out of a dispute between Microsoft and the US government over emails stored in Ireland. US Congress changed the law while the case was pending, making clear that US providers can be required to produce data stored abroad.

That does not make Contentful a bad company. It does not make Salesforce a bad owner. And it does not take anything away from what the Contentful team built.

But it shows the limit of "Buy European". Contentful spent 13 years as a trusted European vendor, and one board meeting is enough to put it under US law.

An Open Source license changes that. Drupal customers running on Acquia, my own US-based company, are also exposed to US law. But because Drupal is Open Source, they can move to a European hosting partner, self-host, or fork the code. A Contentful customer cannot.

The Contentful team deserves credit for what they built. Few European software companies have reached its scale and size. But this is also a reminder for Europe. For software that governments, public institutions, and critical industries depend on, sovereignty must survive any acquisition.

That is the point of The Software Sovereignty Scale and The Sovereignty Prerequisite that I submitted to the European Commission as feedback on their Cloud Sovereignty Framework.

Open Source is the only way to guarantee long-term choice, control, and governance over your code, data, and infrastructure.

Special thanks to Tiffany Farriss for her review of this blog post.

01 Jun 2026 6:30pm GMT

Today we are talking about AI, How to stay up to date with it, and if it will really take our jobs with guests Angie Byron & Amber Matz. We'll also cover AI Best Practices for Drupal as our module of the week.

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

Topics

• What Is AI Learners Club
• Amber Defines the Club
• Origin Story and DrupalCon
• AI Debate and Community Tensions
• Issue Queue Conduct and Moderation
• Thread Tone vs Substance
• AI Adoption Outside Drupal
• Conflict Mediation Playbook
• Maintainer Burnout and Flood
• Safe Space Learners Club
• How the Club Started
• Picking Topics and Demos
• AI Taking Our Jobs
• Future of Learners Club

Resources

• Context Control Center
• AI Learners Club
  • Initiative page
  • Event calendar
  • YouTube Playlist
  • Session Recaps
  • Next session (Claude Design)
  • Slack: #ai-learners
  • Most wanted topics
• What Angie's working on these days

Guests

Amber Matz - tugboatqa.com amber-himes-matz Angie Byron - ai_best_practices webchick

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:
  • Do you want to start using AI tools for Drupal development, in the most efficient way possible? There's a composer plugin for that!
• Module name/project name:
  • AI Best Practices for Drupal
• Brief history
  • How old: created in Mar 2026 by Angie Byron (webchick), one, of today's guests, a long-time Drupalist, one-time Acquian, and a fellow Canadian
  • Versions available: dev version only, which doesn't seem directly opinionated about what version of Drupal you're using, though it does have minimum versions of PHP and Symfony libraries that suggest Drupal 10 is functionally your minimum
• Maintainership
  • It is officially seeking co-maintainers
  • Test coverage
  • Documentation - an in-depth README, or you can ask an AI model! (like I did for this segment)
  • 54 open "Work Items" on Gitlab, so lots of active discussion already
• Module features and usage
  • AI Best Practices for Drupal aims to be the opinionated starter experience for AI-assisted Drupal development
  • You can think of it as a single Composer install that makes any AI coding agent "speak Drupal": following community standards, preferring contrib over custom code, and avoiding framework-naive mistakes. It replaces scattered, tool-specific CLAUDE.md files and Cursor rules that some Drupal developers currently maintain individually, with one canonical, community-governed package that works across Claude Code, Cursor, Copilot, and more. With contributions by a variety of Drupal luminaries including Marcus Johansson, Christoph Briedert, and Scott Falconer, it's the Drupal equivalent of Laravel Boost: stop explaining Drupal to your AI every session and just get writing code.
  • After install or update, it will create an AGENTS.md file from a provided template if there isn't one already, or it will update a specifically marked "ai-best-practices" section of an existing file
  • You will also have a directory of provided skills, and guidance for creating new Drupal agent skills
  • Also included is a set of evals, meant to automatically identify when AI models go off course and provide feedback
  • AI Best Practices for Drupal is meant to provide guidance that will be particularly useful for AI agents, so it's ideal for Drupal developers getting started with AI tools, or for AI developers who want to get started with Drupal

01 Jun 2026 6:00pm GMT

Drupal 12 is still months away, but readiness work is already becoming visible in contributed projects. One recent example comes from Scheduled Transitions 2.9.0-beta4, which declares compatibility with Drupal ^11.3 || ^12. The release itself is modest, but it serves as an early reminder for teams beginning to review upgrade paths and dependency inventories ahead of the next major Drupal release.

Scheduled Transitions is an editorial workflow module that allows content revisions to move automatically between moderation states at scheduled times. While the module itself may not be widely discussed, it represents the kind of workflow dependency that organisations often rely on for day-to-day publishing operations.

That makes its Drupal 12 compatibility declaration noteworthy. Upgrade planning should not stop at Drupal core. Teams also need visibility into the contributed modules that support moderation, scheduling, revisions, translations, layout management, search, and editorial access. Early compatibility signals help identify which parts of a publishing stack are already preparing for the next release cycle.

According to the Drupal core release schedule, Drupal 12.0.0-beta1 is planned for the week of 14 September 2026, with Drupal 12.0.0 scheduled for the week of 7 December 2026. Drupal 10 is also expected to reach end of life on 9 December 2026, giving site owners a practical reason to begin evaluating dependencies before the final quarter of the year.

The takeaway is straightforward: start small, but start now. Check which contributed modules already declare Drupal 12 support, note any changes in PHP requirements, and identify workflow dependencies that have yet to publish a compatibility path. Scheduled Transitions is only one example, but it highlights the quiet preparatory work that often determines how smoothly a major upgrade goes.

With that context in mind, the major developments covered in last week's edition of Editor's Pick newsletter are presented in the teaser blocks below.

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.

Kazima Abbas
Sub-editor
The Drop Times

01 Jun 2026 6:23am GMT

Drupal is moving through one of the most exciting periods in its recent history.

We have Drupal CMS, Drupal AI, Recipes, and the upcoming Experience Builder all pushing Drupal toward a more approachable, modern, and ambitious future.

31 May 2026 5:14pm GMT

Drupal site building has changed a lot in the last few years.

You can still build a site the traditional way with blocks, templates and Layout Builder, but there are now two newer approaches worth knowing about: UI Suite with Display Builder, and Drupal Canvas in Drupal CMS.

In the above video, we walk through all three approaches to help you pick the right one for your Drupal site.

31 May 2026 8:31am GMT

My LocalGov Drupal contributions for May 2026 markconroy 31st May 2026

29 May 2026 11:50am GMT

Image

Imagen

28 May 2026 5:22pm GMT

See how we seamlessly integrated WooCommerce with the Autenti system without affecting the checkout process.

28 May 2026 12:04pm GMT

Climate data are shaping decisions everywhere, from infrastructure and public health to agriculture, insurance, emergency preparedness, and urban planning. Yet despite the growing importance of this information, climate data can still be surprisingly difficult to use.

The challenge is not a lack of science. In many cases, the problem is the opposite: there are an overwhelming amount of data available. What's often missing is an experience that helps people explore and understand complex information in ways that feel approachable, intuitive, and useful.

Together with Luqia, we redesigned the ClimateData.ca platform around a simple but important idea: climate data become more accessible when people can explore them for themselves. Rather than treating information as something users simply download or read through, the new platform encourages interaction and discovery through maps, filtering tools, and guided exploration.

The goal was never to simplify science. It was to make navigating climate data feel clearer, more intuitive, and more connected to the real-world questions people are trying to answer.

What is ClimateData.ca?

ClimateData.ca is a free, bilingual platform that gives Canadians access to climate projections and historical data to support real-world decision-making.

At its core, it is a data visualization and download platform. You can browse interactive high-resolution maps, filter by sector or variable, explore graphs, and download raw datasets for your own analysis. The platform also includes educational materials and guidance on how to use climate information in decision-making.

Why it matters: Canada is warming fast

Canada is warming, on average, twice as much and twice as fast as the rest of the world. In Northern Canada, it's happening even faster (Canada's Changing Climate Report, ECCC, 2019). Across the country, the effects are already measurable: more extreme heat, shorter snow and ice seasons, earlier spring peak streamflow, thinning glaciers, thawing permafrost, and rising sea levels. All sectors of society and the economy are at risk, and further warming is described as effectively irreversible. The case for better data infrastructure is built into the science itself.

Feature focus #1: The Learning Zone

A key feature on the Climate Data platform is its Learning Zone, a filterable library of resources designed for users at every level and across sectors. A planner, engineer, health professional, educator, or community organization may come to the platform with very different questions, levels of technical knowledge, and regional concerns. The redesigned Learning Zone gives users a more accessible entry point into the science before they move into maps, datasets, or projections.

Content types include videos, podcasts, interactive tools, articles, case studies, sector overviews, and regional profiles. Resources can be filtered by region (Atlantic, North, Ontario, Pacific, Prairies, Québec) and technical level.

Feature focus #2: Seasonal to Decadal forecasting

Climate data are most useful when they help people understand patterns rather than react to isolated events. Conditions naturally shift from season to season, year to year, and decade to decade, shaped by factors like ocean-atmosphere cycles, volcanic activity, and broader climate trends. El Niño and La Niña are familiar examples: these recurring patterns can influence temperature and precipitation in a given season or year, including during El Niño conditions like those forecast this year. That variability is part of what makes climate information complex: a single warm season or cool year can stand out, but it does not always tell the full story.

Historical reference periods give users a more stable baseline for interpreting what they are seeing, whether they are looking at recent conditions, short-term forecasts, or longer-term projections. In the Seasonal to Decadal (S2D) tool, forecasts are shown against the 1991-2020 historical reference period, helping users understand whether projected conditions are likely to fall above, below, or near a recent baseline rather than viewing them in isolation.

The underlying data come from CanSIPSv3 (the Canadian Seasonal to Interannual Prediction System, version 3), developed by ECCC. It uses two coupled atmosphere-ocean-land climate models (CanESM5 and GEM5.2-NEMO) with an ensemble of 40 model simulations. This forecasting layer bridges the gap between short-term weather forecasts and the longer-horizon multi-decade projections the platform is better known for.

Feature focus #3: The Maps tool

We redesigned the platform's interactive maps tool to shift from a download-focused experience to an exploratory one. Rather than treating climate data as something users simply retrieve and interpret elsewhere, the interface is built to support comparison and discovery directly in the browser.

The maps tool covers more than 45 climate variables, including specific indicators such as Hottest Day, Frost-Free Season, Cooling Degree Days, and Freeze-Thaw Cycles. Users can compare emissions scenarios side by side, switch between projected change and absolute values, and navigate data through multiple geographic views (watersheds, health regions, census subdivisions, and grid cells) depending on the context of their work. The front end is built in React, designed to keep interaction smooth as users move between datasets and scenarios.

That geographic flexibility matters because different users approach climate impacts differently. Infrastructure planners, public health teams, researchers, and policy makers often need completely different spatial perspectives and levels of detail from the same underlying data.

The data behind the platform

The platform's projection datasets are built on rigorous scientific foundations. The primary future projection dataset, CanDCS-M6, shows how temperature and precipitation conditions may change across Canada under four possible emissions scenarios. It uses data from 26 climate models and maps results at a relatively local scale, with grid cells of about 6 by 10 kilometres. A companion dataset, CanDCS-U6, covers three emissions scenarios across the same 26-model suite.

The platform also includes more specialized datasets for climate-related risks, including drought, extreme heat and humidity, sea level rise, coastal infrastructure planning, and extreme rainfall. These help users move from broad climate projections to more specific questions, such as where drought stress may increase, how often heat may become dangerous, how coastal infrastructure may need to adapt by the end of the century, or how stormwater systems should be designed for heavier rainfall.

All datasets go through a formal evaluation process before being added to the portal. Every step involves representatives from all partner organizations, and respects strict data standards.

Who built ClimateData.ca?

ClimateData.ca is a collaborative product involving several of Canada's leading regional climate organizations: Ouranos (Québec), the Pacific Climate Impacts Consortium (PCIC), the Prairie Climate Centre, ClimateWest, CLIMAtlantic, and ORCAA-CRACO. Evolving Web built and maintains the platform alongside Luqia (formerly the Computer Research Institute of Montréal, CRIM), with overarching support from ECCC.

The bottom line

ClimateData.ca doesn't promise simple answers. Climate projections are probabilistic, scenario-dependent, and require careful interpretation. What the platform does offer is something genuinely valuable: a single, well-documented, freely accessible place where any Canadian can engage with the best available science on how their local climate is likely to change.

Given that Canada's own national climate report describes further warming as effectively irreversible, and that every sector of the economy faces risk, that kind of infrastructure matters, now more than ever.

Get in touch

If your organization is working with complex data and looking for ways to make it more accessible, interactive, and useful, we can help. From interactive maps and data-rich platforms to visualization tools and UX strategy, we work with organizations to create experiences that help people explore and understand information more effectively.

Get in touch to learn how we can help bring your data to life.

+ more awesome articles by Evolving Web

27 May 2026 8:07pm GMT