fidzu : Drupal

A Drupal View does not have to end as a row of equal cards. Bento Showcase tests how far sorting, promotion, and image treatment can carry a structured content collection toward a composed page.

01 Oct 2026 11:01am GMT

A large multilingual Drupal site took almost 20 minutes to self-install, which made every CI run painfully slow. Here's how a PHP profiler and an AI coding agent got it down to 90 seconds.

"We'll add the tests later" only works if the tests are fast enough that nobody is tempted to skip them. On one of our large multilingual Drupal projects, they weren't.

The site has content in 100 languages, around 200 modules, 400+ configured fields, and up to 5,000 config files once translations are counted in. Running drush site:install against that configuration took close to 20 minutes. Add Docker startup and the actual end-to-end test run on top, and a single CI pipeline run could easily take an hour. Copying the production database into CI wasn't an option, so a full config-driven install was the only realistic way to get a clean site to test against for every change.

An install that slow doesn't just cost CI minutes, it costs feedback loops. So we set out to find out exactly where the 20 minutes were going, fix what we could, and see how AI could shorten the loop of measuring, fixing and re-measuring.

Setting up a profiler

The first step was getting visibility into what Drupal was actually doing during install. We used SPX, a lightweight PHP profiler that's easy to drop into a Docker-based PHP image alongside xdebug or blackfire alternatives, without much of the performance overhead those carry.

Once enabled, SPX gives you a web UI to browse individual profiles and see wall time, memory and call counts per function:

And for any profiled request, a flame-graph-style view of the whole call stack, with a sortable table of the most expensive functions underneath:

That's already useful for a single page load. The interesting part is what happens when you point the same tooling at an AI coding agent.

Giving the coding agent access to the profiler

SPX ships an MCP server extension, SPX-MCP, which exposes recorded profiles through a query-like interface instead of a browser UI. Wiring it into an agent's MCP configuration means the agent can list profiles, drill into a specific request, and pull out the functions responsible for the most time, without a human first opening a flame graph and squinting at it.

In practice, that turns "let me go look at a profile and tell you what's slow" into a two-line prompt:

The agent found the three most recent profiles, correctly noticed they were regular page requests rather than the site:install run we actually cared about, and then, once pointed at the right report, broke a 1.44s homepage request down into HTML rendering, Twig compilation, class loading, cache reads and database time, each with concrete function names attached. That's the same triage a developer would do manually, just a lot faster to get to.

The problem with profiling a 20-minute install

Profiling a single page request is straightforward. Profiling a 20-minute drush site:install is a different story: turning SPX on for the whole run produced one profile with almost 590 million calls, weighing about 8GB on disk. That's too large to open in the web UI, and too large for an agent to reason about as a single blob.

The fix was to split it into one profile per install stage instead of one profile for the whole run. Drupal's installer runs through a fixed sequence of tasks (install_select_language, install_config_import_batch, install_import_translations, and so on), and there's a single place in core, install_run_tasks(), where each task starts and finishes. A small patch there starts and stops an SPX profile around each task and tags it with the task name as metadata:

--- a/core/includes/install.core.inc
+++ b/core/includes/install.core.inc
@@ function install_run_tasks(&$install_state, ?callable $callback = NULL) {
     $task = array_shift($tasks_to_perform);
     $install_state['active_task'] = $task_name;
     $original_parameters = $install_state['parameters'];
+    if (function_exists('spx_profiler_start')) {
+      spx_profiler_start();
+      spx_profiler_full_report_set_custom_metadata_str(json_encode(['task' => $task_name]));
+    }
     $output = install_run_task($task, $install_state);
     ...
+    if (function_exists('spx_profiler_stop')) {
+      spx_profiler_stop();
+    }
   } while (!$finished);

That turned one unmanageable profile into a dozen small ones, each scoped to a single install task, each cheap enough for the agent (or a human) to load and query directly. For the rare case of a profile that's still too big, there's also SPXQ, a small command-line viewer for browsing multi-gigabyte SPX reports without loading the whole thing into memory or a browser tab.

Finding the bottlenecks

With per-task profiles available, the workflow became a loop: profile a task, find the most expensive function, patch it, install again, and check the diff in timing. Doing that by hand, task by task, function by function, is tedious, exactly the kind of repetitive, well-defined work an AI coding agent is good at once it has direct access to the profiling data instead of having to be told what's in it.

One of the clearest examples was the install_config_import_batch task, which turned out to spend the majority of its time in EntityStorageBase::doPostSave():

Digging into that call chain showed that saving a single field config was re-triggering hooks and cache invalidation for every entity type's base field definitions, even when only one bundle had actually changed, and it was doing that for every field, of which there were hundreds. After each fix, the agent could re-run the install, pull the new profile, and confirm the improvement against the previous run.

What actually moved the needle

After several rounds of this profile-fix-reprofile loop, here's what made the biggest difference:

1. Cache collection names. StorageComparer::getAllCollectionNames() was rescanning the sync directory to find language collections on every one of ~2,800 config items during import, even though the answer never changes. Computing it once per import and reusing it cut that step by 27.6%.

2. Cache translatable default config. LocaleConfigManager::getTranslatableDefaultConfig() rebuilt a typed-config wrapper once per language, even though the shipped default config is identical across languages. Caching it by config name cut this by 53.5%.

3. Cache isSupported(). The sibling of the fix above, doing two redundant config reads per language for an answer that doesn't depend on the language. Caching it removed another 5.4%.

4. Scan the translation directory once. The same, usually-empty translation folder was being scanned for every project/language pair, up to 1,580 times. Listing it once and matching filenames against that list brought the whole step down to about 6ms.

5. Skip no-op config saves. LocaleConfigManager::updateConfigTranslations() was saving configuration even when nothing had actually been translated, reloading language override objects for all languages on every save. A simple !empty($processed) guard removed 237 unnecessary saves.

6. Stop force-rebuilding a cold field map. After every container rebuild, FieldDefinitionListener::onFieldDefinitionCreate() was forcing a full field map rebuild for every single field created during install. Skipping that while the map is still cold cut getBaseFieldDefinitions() calls by 76%, with no change to the resulting field map.

7. Narrow the cache clear on field save. This was the single biggest win. Saving one field config was wiping every entity type's base field definitions and triggering a full plugin rediscovery. Clearing only the affected bundle's field definitions during install cut this step by 18%, verified as producing byte-identical definitions across 37 entity/bundle combinations.

8. No-op the translation status key/value store during install. A small wrapper turns locale.translation_status lookups into an in-memory no-op during install (and passes through normally afterwards), avoiding repeated database hits for a value that's meaningless mid-install.

9. Disable remote translation lookups for CI installs. During an automated test install there's no reason to reach out to the localization server, so translation.import_enabled and related settings are simply turned off for that environment. This one is a CI-only optimization, not something you'd want in production.

10. Skip irrelevant entity hooks during install. Some entity_update/entity_insert hooks have no meaning during install or fixture loading. Guarding them behind $entity->isSyncing() avoided pointless work; for example, the Search API module's _search_api_view_crud_event() handler.

None of these are exotic. Individually, most are the kind of "don't redo work you already did" fix any Drupal developer would recognize once pointed at it. What changed was how quickly they could be found and verified: instead of manually reading flame graphs and re-running a 20-minute install to check each guess, the agent could query a profile, propose a targeted fix, and confirm the improvement against the previous measurement, over and over.

The result

After all of it: 1 minute 30 seconds, down from roughly 19 minutes 30 seconds. A 13x improvement on the number that mattered most for us, the total install time inside the CI pipeline.

Not every fix here is something we'd apply blindly to every project. Some, like skipping remote translation downloads, only make sense for a throwaway test install. Others touch Drupal core behaviour around cache invalidation and are being submitted as proper core patches with issues on drupal.org, since they need review and testing well beyond "it worked for us".

Bonus

Both the SPXQ profile viewer and a reusable "profile, analyze, fix, validate" skill for coding agents are public:

• SPXQ, a CLI profile viewer for large SPX reports.
• A Claude/Codex skill that walks an agent through profiling, analyzing, fixing and validating performance issues on its own.
• The core patches from this round of optimization are collected in this gist.

Tags: Drupal Planet, Drush, Performance, AI, Drupal, DrupalCon

01 Oct 2026 11:00am GMT

After watching the Driesnote (aka the keynote) from DrupalCon Rotterdam, I was inspired and overwhelmed by everything happening in Drupal that I need to catch up on.

Immediately, I should help get the new Tool API working with the Webform module, but first I need to work through the Webform module issue backlog. Second, I need to learn more about Drupal Canvas and start defining a roadmap for my organization to move to Drupal Canvas. Lastly, I have no experience with ECA, and now there's FlowDrop to look at too.

My new AI reality is that I'm generally no longer overwhelmed by new technical challenges because I leverage AI to help me learn and plan how to evolve my knowledge base and the applications I support. I've used AI enough, building and maintaining a Drupal site and its modules, to know just how capable today's frontier models are. At the same time, I struggle to communicate with AI and get it to understand my requirements to achieve my goals. During these struggles, I get slapped in the face with AI slop.

After deleting most of my agent skills and starting over, I began experimenting with one of the most popular agent skills, /grill-me, which proved to be a game changer.

The /grill-me skill was created by Matt Pocock and is mentioned in many Reddit threads. I was not sold on even trying it until I listened to Read More

01 Oct 2026 8:52am GMT

File (Field) Paths is stable. 8.x-1.0 is the first stable release since the Drupal 7 one (long may it live), and it does what it has always done: sorts and renames your uploads with token patterns, so you get a filesystem you can read.

If you've been holding off while it sat in RC, you don't need to. It has 215 automated tests and 1287 assertions where beta8 had 21 tests, a safer default for where uploads wait, and a plan for what comes next. It's under active maintenance again.

Core file fields let you choose a directory, and that setting takes tokens. Drupal ships [date:custom:Y]-[date:custom:m] as the default. What it can't take is a token about the entity you're attaching the file to, because at the moment the file is saved those values don't exist yet. The file name isn't touched at all.

Continue reading →

01 Oct 2026 6:00am GMT

In December 2017, on Ægir's tenth birthday, Steven Jones of ComputerMinds joked that within ten years Ægir would be an AI, setting up cat gif websites for its own purposes. With fourteen months left on the clock we checked how the prophecy is doing. In BOA, our Ægir hosting stack, the agent which keeps a server current is called Skynet since a 2012 commit meant to replace boring welcome messages, the installer still pretends to charge your credit card as it did in 2010, and the family named after a Norse sea giant and his doorman, Ægir and Eldir, grew a Barracuda, an Octopus and this summer a Kraken. Since 2025 the Ægir 3 projects on drupal.org are maintained by us, after the prophet himself asked, fairly enough, whether they should be marked obsolete, and in 2026 the stack is built with AI tools: eleven stable releases against three last year, for Drupal, Drupal CMS and Backdrop sites. The AI stays on our desks and nothing on your server guesses, so only the cat gifs are late.

30 Sep 2026 5:34pm GMT

Not every Drupal AI update calls for the same response. Recent releases may require teams to rebuild search indexes, update agent configuration or keep experimental Views changes under close human review.

30 Sep 2026 4:37pm GMT

30 Sep 2026 12:01pm GMT

The official Drupal AI Demo is live. Explore how Drupal AI features work together in one real-world demo!

30 Sep 2026 12:00pm GMT

30 Sep 2026 10:55am GMT

30 Sep 2026 9:21am GMT

The winning projects span AI, public services, publishing, education, healthcare, commerce and other areas of Drupal implementation.

30 Sep 2026 8:49am GMT

Watching the DriesNote at DrupalCon Rotterdam, one part of Dries Buytaert's argument felt immediately familiar.

30 Sep 2026 8:44am GMT

Key takeaways from the DrupalCon Rotterdam Driesnote: MCP support through PHP attributes, Canvas updates, and a new Drupal advocacy program.

30 Sep 2026 7:29am GMT

What Migrate Plus adds to core, when a custom source plugin is the right answer, and the anatomy of one that survives real data, with working PHP and YAML.

30 Sep 2026 7:00am GMT

I've worked in several settings where technical people announced their focus was on the technology, not the user of the technology. They would say things like: "I don't care what they do, I just want to build it."

This is a terrible way to work. It leads to bad solutions and miscommunication.

You cannot find the flaws in the spec, and there are always flaws, if you cannot sanity check it yourself. You cannot know for sure your solution worked if you don't know what the data means and how it is used.

The Importance of Understanding

When my wife and I attended the Polo match pictured above we tried to ask some of the regulars basic questions about what was happening. They responded to us using all the words of the sport, but not in a way we could understand. If they wanted to attract new fans to the sport, they needed to explain the game to us in words we understood. It got even worse when a horse got injured and no one really explained what was happening until the ambulance trailer pulled onto the field.

To do our best work we need to understand the end goal of our users. The most effective way I know to communicate clearly is to use the same language as my audience does when talking about their work. If you try to force them to use the terms and phrases you know best they will likely make mistakes that cause you problems.

We must meet our audiences where they are.

When I was a Drupal developer, I was creating web sites that were customized to a specific organization's needs. When I was a Salesforce consultant and developer, I was tailoring the platform to handle the specific needs of those users. In my role inside a nonprofit energy company I am making sure our Salesforce org meets our needs.

What was common across all those roles is that I needed (and still need) to talk with my users and understand their needs and the work they need the tool to do for them.

Problems with Failure to Understand

When I was a web developer, often the spec I was working to support was a graphic design. The designers would create a very attractive design, the client would approve it, and I was told to go implement it. Drupal, of course, can be implemented many different ways. To create a good implementation I needed to understand the designer's intent and why the client liked the design (beyond it being pretty). I would ask why images were placed where they were, not to challenge the design but to make sure I called them the right thing in the backend. Those names were important to the content editors to help them select the right image in the future.

Working with Salesforce brings the same challenges. To understand if a Flow is working right, or even worth building at all, I need to know what the user expects to happen and why. When organizing a page layout, I need to know which information is most important and what fields are related to group them sensibly.

A Quick Note About Ethics

A complete discussion of the ethics of technology is impossible here; it's a whole field of thought within Philosophy. Still we all should care how our work impacts the world. If I create a tools that's helping someone commit evil, I'm supporting that evil. There is a mountain of nuance and detail to be thought through.

Just because the topic is huge and complicated does not free us from the basic responsibility to care about it. When someone tells me they don't care how the technology is used, they are implicitly announcing they are comfortable supporting outcomes they consider evil.

When Do I Know Enough?

Probably never.

Over the course of my career so far I have worked on projects that involved:

• International peace and conflict resolution efforts
• The US federal budget
• Private prisons
• Economic empowerment of women in Africa
• Lobbying at the federal and state levels
• The DNS system
• Youth empowerment in the US and other parts of the world
• Explaining Quakerism
• Phone system setup and operation
• Desktop computer and server hardware
• Web development
• Web site infrastructure
• Virtual machines
• Open source licenses
• Copyright (copyleft) and trademarks
• General nonprofit fundraising techniques and strategies
• Basic accounting practices
• The child welfare system in several US states
• Life guarding and water safety
• Natural disaster planning and response
• Rules for credit card processing and security
• Sales of kayaks, canoes, and other related products
• Advanced and basic marketing strategies
• Chemical coatings for packaging
• The US sales tax "system"
• The energy industry in California and generally around the US
• …and probably a bunch of other stuff I'm not thinking to include

While that might be a little more than is average in just over 25 years of professional life it's probably not all that high for someone with a similar career track. If you've been working for a few years, think about all the different things you have had to work on - it's a bigger list than you'll expect.

All of that learning can be exhausting; I understand the temptation to say "I know enough, I don't need to know more." But if I want to keep getting chances to advance, I need to be ready to understand the next thing I need to know.

It helps to be curious.

30 Sep 2026 12:00am GMT

A recent post on Bluesky asked a common question: with dozens of DDEV projects, what is the fastest way to get to one? The current routine was to open Finder, dig three folders deep, drag the folder into an editor, and then run ddev start. Another post mentioned 52 projects and no idea which ones are running. Here are the techniques we use and that came up in the replies.

See What Is Running: ddev list

ddev list shows every project DDEV knows about, with its status, location, URL, and type. The underlined locations and URLs are terminal hyperlinks you can click.

To see only the projects that are running, use ddev list --active-only (or ddev list -A). ddev poweroff stops every running project at once.

Clickable Links

Hold Cmd (macOS) or Ctrl (Linux and Windows) and click a link. A location opens in your file manager, and a URL opens in your browser.

DDEV adds links only in terminals it recognizes, including iTerm2, Ghostty, WezTerm, Kitty, Alacritty, Windows Terminal, VS Code's integrated terminal, GNOME Terminal, and Konsole. The macOS Terminal app doesn't support them, so on a Mac, iTerm2 is a good choice if you want clickable links or even if you just want to live a long and happy life.

If nothing is underlined:

• Upgrade DDEV. Links need v1.25.3 or later.
• Check that links are turned on in your terminal. Konsole has them off by default. To turn them on, enable "Allow escape sequences for links" under Settings > Edit Current Profile > Mouse > Miscellaneous.
• If you use tmux or screen, DDEV can't detect your terminal. Add export FORCE_HYPERLINK=1 to your shell startup file to turn links on anyway.

The DDEV Dashboard: Just Type ddev

Running ddev or ddev tui with no arguments opens an interactive terminal dashboard that lists all of your projects and their status. You can start, stop, and restart projects, open a project's URL or Mailpit in the browser, and press Enter for a project's details. For someone with 52 projects, this may be the quickest way to see what is running.

With many projects, the most useful key is /, which filters the list as you type. The filter matches part of a project's name, type, status, or directory, ignoring case, so dr finds every Drupal project, running shows only running projects, and client finds every project under a client directory. Move to the project you want, and start it with s or open it with l. See the interactive dashboard documentation for the full list of keys.

ddevcd: Built-In Project Jump

DDEV ships a shell function that changes to a project's root directory by name:

ddevcd some-project

It needs a one-time addition to your shell startup file. ddev utility cd prints the exact line for Bash, Zsh, or fish. See the utility cd documentation.

ddevcd works from any directory, and it has tab completion for project names like the rest of DDEV. Typing ddevcd pr<tab> completes to something like ddevcd pr8859-test.

autojump: Jump by Partial Name

autojump learns the directories you visit and lets you jump to them with j and part of the name. It works for any directory, not only DDEV projects.

brew install autojump # Or `sudo apt install autojump`, etc
# Follow the post-install instructions to source it from your shell rc file
j myproject
ddev start

If you only need to start a project, you don't have to change directories at all: ddev start <projectname> works from anywhere.

Note that autojump only knows directories you have already visited (unlike ddevcd, which knows every project DDEV has seen).

code . or phpstorm .: Open the Editor From the Project Directory

Once you are in the project directory, open it in your editor from the terminal.

For VS Code:

code .

For PhpStorm:

phpstorm .

Each command opens the current directory as the project, and reuses the window if that project is already open.

The commands have to be installed first:

• VS Code: Run "Shell Command: Install 'code' command in PATH" from the Command Palette.
• PhpStorm: Use Tools > Create Command-line Launcher in PhpStorm, or the shell scripts setting in JetBrains Toolbox. On macOS, open -a PhpStorm . also works without a launcher script.

Other editors follow the same pattern, for example cursor . for Cursor.

Put it all together to get from anywhere to a running project in your editor:

ddevcd myproject && ddev start && code .

ddevcd myproject && ddev start && phpstorm .

Click the Link in ddev describe

ddev describe has a short alias, ddev st, which is easy to type and worth adopting. It prints the project's details, including the project's location on disk.

The project location (~/workspace/ddev.com in the header above) is a clickable link that opens your file manager at the project root.

Advanced: Answer Fancy Questions With ddev list -j and jq

ddev list -j prints the project list as JSON, and jq can answer more specific questions. The project data is under .raw. Each entry has fields including name, approot, status, type, and primary_url.

Running projects and their directories:

ddev list -j | jq -r '.raw[]
  | select(.status=="running")
  | "\(.name)\t\(.approot)"'

Names of all Drupal 11 projects:

ddev list -j | jq -r '.raw[]
  | select(.type=="drupal11")
  | .name'

The directory of one project, which you can use with cd or code:

code "$(ddev list -j | jq -r '.raw[]
  | select(.name=="myproject")
  | .approot')"

Community! Third-Party DDEV GUIs

If you would rather click than type, the community has built several graphical front ends for DDEV. They sit on top of the DDEV command line, so your projects and .ddev configuration stay the same. The DDEV project doesn't maintain or endorse any of these, and this list comes from our newsletters and from reports by their authors. Try them and judge for yourself.

In Your IDE

• DDEV Integration plugin for PhpStorm and IntelliJ, maintained by AkibaAT.
• DDEV Manager extension for VS Code, by Biati Digital.

macOS

• DDrovr is a new native macOS app from Bison Digital that shows all your projects on one dashboard. It offers one-click access to URLs, terminal shells, and logs, detects the project's CMS, highlights startup failures, and searches projects with Cmd-K. It needs macOS 14 or later and DDEV v1.24 or later, and works with OrbStack, Docker Desktop, and Colima. It is a download from the site, and the site lists no pricing or source repository.
• ddevbar is a menu bar app by Klemens Arro for starting, stopping, and restarting projects with a click.
• DDEVUI is a native app written in Swift and SwiftUI.

Cross-Platform

• ddev-ui is an Electron and React app for macOS, Windows, and Linux. It covers project management, database import and export, snapshots, add-ons, and log streaming.
• DDEV Manager GUI by VonLoxx is another desktop wrapper.
• DDEV GUI by ChaosKing has been tested only on Linux.

Commercial and Agency Tools

• DevWorkspacePro by damms005 is a commercial wrapper GUI. When we last looked it had no free trial.

Didn't find yours? The June 2026 newsletter covers some of these tools as well. If you built a DDEV GUI, send a PR adding it here.

Tell Us What We Can Do To Make DDEV Better For You!

We know this is awkward territory, and we're always listening to you, and want to know what we can do to make it better.

Contributions welcome!

Your suggestions to improve this blog are welcome. If you have a technique for getting around your projects that isn't here, you can do a PR to this blog adding it. Info and a training session on how to do a PR to anything in ddev.com is at DDEV Website For Contributors.

Follow the DDEV Newsletter for information about upcoming user and contributor training sessions.

30 Sep 2026 12:00am GMT