fidzu : Drupal

Today we are talking about PHP, Open Source, and Sustainability with guest Elizabeth Barron. We'll also cover AI Image Classification as our module of the week.

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

Topics

• What is the PHP Foundation
• Language Health Challenges
• Paid Core Developers
• Release Infrastructure
• Foundation Role and Perception
• Docs and Onboarding
• Elizabeth Open Source Journey
• Future of PHP Ecosystem
• Listener Elephant Question
• Ecosystem Security Hub
• Advisory Board Limits
• Modernizing Mailing Lists
• Foundation Awareness Push
• PHP Ambassadors Strategy
• State of PHP Survey
• Five Year Vision
• Community Hour Podcast
• php.net Design Refresh

Resources

• The PHP Foundation
• Derek Rethans
  • xdebug
  • Infrastructure
  • https://github.com/derickr
• Drupal advocacy
• Link to community hour podcast
• Php 8.5
• Contribute to php article

Guests

Elizabeth Barron - thephp.foundation elizabethbarron

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Tim Sharp - tea-sharp

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted the images in your Drupal media library to be automatically given alt text, a rich description, and a set of tags, using AI? There's a recipe for that.
• Module name/project name:
  • AI Image Classification
• Brief history
  • How old: created in Sep 2025 by Artem Dmitriiev (a.dmitriiev) of 1xINTERNET
  • Versions available: 1.1.1, which requires Drupal 11.2 or newer
• Maintainership
  • Actively maintained, latest release and commit just two weeks ago
  • Security coverage
  • Number of open issues: 9 open issues, 4 of which are bugs
• Usage stats:
  • No usage data reported
• Module features and usage
  • This recipe applies core's image media type recipe, then adds a description field and a tags field to image media, with tags in a new "Image Classification" vocabulary
  • Editors get a "Generate Alt Text" button right on the image field, using the Field Widget Actions module, with a prompt written like an accessibility expert: under 100 characters, no "image of", flag logos and graphics
  • On save, a vision model writes a description of up to eight sentences: colours, photo versus illustration, people, mood, and key objects, using the media name for context
  • Tagging is chained off that description rather than the image itself, picking or creating up to five short, general terms, and reusing similar existing tags where it can
  • It also adds bulk actions to the media admin view, so you can run description and tagging across an existing library, not just new uploads
  • Description and tag filters are added to the media library, including the widget, so editors can search for "sunny summer day" right in the image picker
  • The stated bigger goal is making images discoverable by RAG and other AI search, so good descriptions become a foundation for future AI features. In fact, this recipe is a dependency for the Canvas AI Image Search recipe, which is still a work in progress
  • Under the hood, images get scaled to 400px wide and converted to PNG before they're sent to the model, which keeps things faster and cheaper
  • One caveat: your site needs an AI provider with a default "chat with image vision" model, and the recipe checks for that when it's applied
  • Also worth a look: the description prompt asks the model to describe people's age, gender, and ethnicity, and even name them if it can, so you may want to review that prompt for your privacy policies, and adjust accordingly
  • Like any recipe, it provides a robust starting point for some compelling features, and every prompt and setting can be tweaked after you apply it
  • Lastly, I wanted to mention that in today's Driesnote in here in Rotterdam, Dries demoed being able to use MCP to search images on his own site. A recipe like this could help you make sure the images in your media library have sufficient metadata to make that work reliably

01 Oct 2026 6:00pm GMT

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

How Tag1 Reviews Code with AI covered the tools Tag1 built to put AI into the PR review process. This post shows the pattern: AI drafts your whole review into GitHub pending reviews or GitLab draft notes, and you decide, line by line, what gets published under your name.

Where AI Fits in Code Review

AI is good at the unglamorous parts of review: actually reading every line of a large diff, knowing the obscure API pitfalls no single reviewer carries in their head, checking the change against the rest of the codebase for consistency, and asking every "what if this input is empty" question without getting bored. What it can't tell you is which of its twenty comments actually matter.

There are two ways to put that to work, and they're not in competition. The first is the one most people have seen: a bot that reads the pull request and posts its review straight to it. That's a good fit for CI and merge gating. Tag1's own ai-pr-review runs on every push, combining deterministic scanners with AI reviewers, and can gate merges on what it finds: a leaked credential, a known CVE, a phpstan error, or a logic bug an agent caught.

The second way is quieter, and easy to overlook. Both GitHub and GitLab have a staging layer for reviews: comments you write that nobody else can see until you press submit. GitHub calls it a pending review; GitLab calls them draft notes ("Start a review"). Point your AI at that layer instead of at the publish button and you get the machine's thoroughness with a person still accountable for every published word. That's what this post is about, and it's what you want when the review goes out under your name, especially when you're the gate a client is paying to stand between their code and their production site. There, the reviewer of record should be someone who read the change and chose to sign it.

The Workflow

The workflow has four steps:

1. AI reads the PR and writes review comments into a pending review, under your account, visible only to you.
2. You open the PR in the normal web UI, and edit, delete, or add comments like you always do.
3. Optionally, ask the AI to look at your edited pending review and flag anything you missed or got wrong. Repeat.
4. You press submit. Every published word is one you chose to publish, under your name. You can wire this up yourself, which is what the rest of this post covers. If you'd rather start from something prebuilt, Greg Chaix's comprehensive-review already packages the pattern: it runs the review locally and can stage its findings as a draft review for you to edit and submit.

GitHub: Pending Reviews

When you comment via "Start a review" in the Files changed tab, GitHub holds the comments in a pending review - they're "pending and only visible to you," per GitHub's docs, until you submit as Comment, Approve, or Request changes. The same states exist in the REST API: create a review without an event and it lands in PENDING; a second call to .../reviews/{review_id}/events submits it; DELETE abandons it. Each user gets one pending review per PR. GitHub doesn't seem to document this anywhere, but the API enforces it with a 422 error: "User can only have one pending review per pull request."

The detail that matters is that if the AI authenticates with your token, the pending review it creates is yours. It shows up in your browser as your own draft, fully editable.

One approach for integrating AI into human-owned reviews is the official GitHub MCP server, which wraps everything in purpose-built tools. One command connects it to Claude Code (create a Personal Access Token (PAT) with repo scope first):

claude mcp add --transport http github https://api.githubcopilot.com/mcp \
  -H "Authorization: Bearer YOUR_GITHUB_PAT"

This exposes the purpose-built tools: pull_request_review_write to create, submit, or delete a review, and add_comment_to_pending_review to add inline comments to your latest pending review. Then, prompt with something like:

Review PR #123 in tag1/example. Read the full diff. Start a pending review and add inline comments only for real problems: correctness, security, performance. Prefix each with Critical/Minor/Nit. Do NOT submit the review; I'll edit and submit it myself.

Because the agent runs as you, a second round works too: "I've edited the pending review. Read it back, tell me what I misjudged, and add pending comments for anything I missed."

The gh CLI is the more dependable approach. There's currently no native pending-review command for gh pr (no gh pr review --draft), but gh api can do it in a single call with nothing extra to install, and when Claude Code prompts you to approve the call it shows the full comment text in a readable form which the MCP doesn't.

# Create a pending review with inline comments (no "event" = stays pending)
gh api repos/tag1/example/pulls/123/reviews --input - <<'EOF'
{
  "body": "First pass by Claude; edited by Jeremy.",
  "comments": [
    { "path": "src/Form/SettingsForm.php", "line": 87, "side": "RIGHT",
      "body": "Critical: user input is concatenated into the query; use a placeholder." }
  ]
}
EOF

You then edit and submit in the web UI. The one thing gh api can't do is append comments to a review you've already started: the REST endpoint only accepts comments at creation time, and the append path needs GraphQL, as discussed in the GitHub community. That's the case where the MCP server has an advantage, since it does the GraphQL for you.

GitLab and Drupal: Draft Notes

For those of us in the Drupal ecosystem, most contribution happens through GitLab merge requests on git.drupalcode.org. Fortunately this uses the same pattern, but with different names.

In the UI, Start a review / Add to review keeps comments unpublished and visible only to you until you submit (with Approve, Comment, or Request changes). This is a Free-tier feature, so it works on any GitLab deployment.

The GitLap API calls them draft notes. To use them, you first need to point glab at the right instance (create a personal access token with api scope in your GitLab profile settings). Swap git.drupalcode.org for your own GitLab host (gitlab.com or your self-managed instance).

glab auth login --hostname git.drupalcode.org

Inline comments need diff SHAs, which come from the merge request itself. Run these inside your clone of the project:

# Get the SHAs the position object needs
glab api projects/:id/merge_requests/42 | jq .diff_refs
 
# AI (or you) stages an inline comment; nobody else sees it
glab api projects/:id/merge_requests/42/draft_notes --input - <<'EOF'
{
  "note": "Minor: this hook is missing a cache tag for the config entity.",
  "position": {
    "position_type": "text",
    "new_path": "src/EventSubscriber/CacheSubscriber.php",
    "new_line": 54,
    "base_sha": "<diff_refs.base_sha>",
    "head_sha": "<diff_refs.head_sha>",
    "start_sha": "<diff_refs.start_sha>"
  }
}
EOF
 
# Later, YOU publish, or just click "Submit review" in the UI
glab api -X POST projects/:id/merge_requests/42/draft_notes/bulk_publish

GitLab's official MCP server (beta, Premium/Ultimate) can read MR diffs and pipelines but doesn't expose draft notes yet, per its tool list, so on GitLab the dependable recipe is to let the agent read the MR however it likes, but have it stage comments through glab api .../draft_notes. Drop the commands above into your project's CLAUDE.md and Claude Code handles the SHAs and line positions itself.

Two Rules

Two simple rules guide the workflow. First, tell the AI explicitly, every time, that it must never submit, approve, or publish anything; staging comments is its entire job. Second, run it with your own credentials, because draft comments are only editable by their author, and the author should be you.

The AI delivers the efficiency: it reads every line of the diff in minutes and never gets bored or distracted. You deliver the quality: your judgment decides what's real, what matters, and how to say it to a colleague, and the AI's optional second pass over your edits catches what you missed. Because nobody else sees the pull request until you've read it, shaped it, and chosen to sign it, you stay in control of the review from first comment to submit button. You're not choosing between doing reviews faster and doing them well. Done this way, AI helps you achieve both.

30 Sep 2026 12:00am GMT