fidzu : Drupal

17 Feb 2026 6:15pm GMT

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

17 Feb 2026 9:15am GMT

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

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

The noisy status report problem

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

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

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

…

17 Feb 2026 8:11am GMT

For most people, Xdebug step debugging in DDEV just works: ddev xdebug on, set a breakpoint, start your IDE's debug listener, and go. DDEV handles all the Docker networking automatically. If you're having trouble, run ddev utility xdebug-diagnose and ddev utility xdebug-diagnose --interactive - they check your configuration and connectivity and tells you exactly what to fix.

This post explains how the pieces fit together and what to do if things do go wrong.

The Quick Version

1. ddev xdebug on
2. Start listening in your IDE (PhpStorm: click the phone icon; VS Code: press F5)
3. Set a breakpoint in your entry point (index.php or web/index.php)
4. Visit your site

If it doesn't work:

ddev utility xdebug-diagnose

Or for guided, step-by-step troubleshooting:

ddev utility xdebug-diagnose --interactive

The diagnostic checks port 9003 listener status, host.docker.internal resolution, WSL2 configuration, xdebug_ide_location, network connectivity, and whether Xdebug is loaded. It gives actionable fix recommendations.

How Xdebug Works

Xdebug lets you set breakpoints, step through code, and inspect variables - interactive debugging instead of var_dump().

The connection model is a reverse connection: your IDE listens on port 9003 (it's the TCP server), and PHP with Xdebug initiates the connection (it's the TCP client). Your IDE must be listening before PHP tries to connect.

:::note The Xdebug documentation uses the opposite terminology, calling the IDE the "client." We use standard TCP terminology here. :::

How DDEV Makes It Work

DDEV configures Xdebug to connect to host.docker.internal:9003. This special hostname resolves to the host machine's IP address from inside the container, so PHP can reach your IDE across the Docker boundary.

The tricky part is that host.docker.internal works differently across platforms. DDEV handles this automatically:

• macOS/Windows: Docker Desktop and Colima provide host.docker.internal natively
• Linux: DDEV uses the docker-compose host gateway feature
• WSL2: DDEV determines the correct IP based on your configuration

You can verify the resolution with:

ddev exec getent hosts host.docker.internal

DDEV Xdebug Commands

• ddev xdebug on / off / toggle - Enable, disable, or toggle Xdebug
• ddev xdebug status - Check if Xdebug is enabled
• ddev xdebug info - Show configuration and connection details

IDE Setup

PhpStorm

Zero-configuration debugging works out of the box:

1. Run → Start Listening for PHP Debug Connections
2. Set a breakpoint
3. Visit your site

PhpStorm auto-detects the server and path mappings. If mappings are wrong, check Settings → PHP → Servers and verify /var/www/html maps to your project root.

The PhpStorm DDEV Integration plugin handles this automatically.

VS Code

Install the PHP Debug extension and create .vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug",
      "type": "php",
      "request": "launch",
      "port": 9003,
      "hostname": "0.0.0.0",
      "pathMappings": {
        "/var/www/html": "${workspaceFolder}"
      }
    }
  ]
}

The VS Code DDEV Manager extension can set this up for you.

WSL2 + VS Code with WSL extension: Install the PHP Debug extension in WSL, not Windows.

Common Issues

Most problems fall into a few categories. The ddev utility xdebug-diagnose tool checks for all of these automatically.

Breakpoint in code that doesn't execute: The #1 issue. Start with a breakpoint in your entry point (index.php) to confirm Xdebug works, then move to the code you actually want to debug.

IDE not listening: Make sure you've started the debug listener. PhpStorm: click the phone icon. VS Code: press F5.

Incorrect path mappings: Xdebug reports container paths (/var/www/html), and your IDE needs to map them to your local project. PhpStorm usually auto-detects this; VS Code needs the pathMappings in launch.json.

Firewall blocking the connection: Especially common on WSL2, where Windows Defender Firewall blocks connections from the Docker container. Quick test: temporarily disable your firewall. If debugging works, add a firewall rule for port 9003.

WSL2 Notes

WSL2 adds networking complexity. The most common problems:

• Windows Defender Firewall blocks connections from WSL2 to Windows. Temporarily disable it to test; if debugging works, add a rule for port 9003.

• Mirrored mode requires hostAddressLoopback=true in C:\Users\<username>\.wslconfig:

  [experimental]
  hostAddressLoopback=true
  

  Then wsl --shutdown to apply.

• IDE in WSL2 (VS Code + WSL extension): Set ddev config global --xdebug-ide-location=wsl2

Special Cases

Container-based IDEs (VS Code Remote Containers, JetBrains Gateway):

ddev config global --xdebug-ide-location=container

Command-line debugging: Works the same way - ddev xdebug on, start your IDE listener, then ddev exec php myscript.php. Works for Drush, WP-CLI, Artisan, and any PHP executed in the container.

Debugging Composer: Composer disables Xdebug by default. Override with:

ddev exec COMPOSER_ALLOW_XDEBUG=1 composer install

Custom port: Create .ddev/php/xdebug_client_port.ini with xdebug.client_port=9000 (rarely needed).

Debugging host.docker.internal resolution: Run DDEV_DEBUG=true ddev start to see how DDEV determines the IP.

Advanced Features

xdebugctl: DDEV includes the xdebugctl utility for dynamically querying and modifying Xdebug settings, switching modes (debug, profile, trace), and more. Run ddev exec xdebugctl --help. See the xdebugctl documentation.

Xdebug map feature: Recent Xdebug versions can remap file paths during debugging, useful when container paths don't match local paths in complex ways. This complements IDE path mappings.

Performance: Xdebug adds overhead. Use ddev xdebug off or ddev xdebug toggle when you're not actively debugging.

More Information

• DDEV Step Debugging Documentation
• Xdebug Documentation
• Xdebug Step Debugging Guide

Claude Code was used to create an initial draft for this blog, and for subsequent reviews.

17 Feb 2026 12:00am GMT

16 Feb 2026 8:03pm GMT

Today we are talking about Acquia's Fully managed Drupal SaaS Acquia Source, What you can do with it, and how it could change your organization with guest Matthew Grasmick. We'll also cover AI Single Page Importer as our module of the week.

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

Topics

• Introduction to Acquia Source
• The Evolution of Acquia Source
• Cost and Market Position of Acquia Source
• Customizing and Growing Your Business
• Challenges of Building a SaaS Platform on Drupal
• Advantages of Acquia Source for Different Markets
• Horizontal Scale and Governance at Scale
• Canvas CLI Tool and Synchronization
• Role of AI in Acquia Source
• Agencies and Enterprise Clients
• AI Experiments and Content Importer
• AI and Orchestration in Drupal
• Future Innovations in Acquia Source

Resources

• Acquia source
• Nebula

Guests

Matthew Grasmick - grasmash

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Catherine Tsiboukas - mindcraftgroup.com bletch

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to use AI to help map various content on an existing site to structured fields on Drupal site, as part of creating a node? There's a module for that.
• Module name/project name:
  • AI Single Page Importer
• Brief history
  • How old: created in Jan 2026 by Mark Conroy (markconroy) who listeners may know from his work on the LocalGov distribution and install profile
  • Versions available: 1.0.0-alpha3, which works with Drupal core 10 or 11
• Maintainership
  • Actively maintained
  • Documentation - pretty extensive README, which is also currently in use as the project page
  • No issues yet
• Usage stats:
  • 2 sites
• Module features and usage
  • With this module enabled, you'll have a new "AI Content Import" section at the top of the node creation form. In there you can provide the URL of the existing page to use, and then click "Import Content with AI". That will trigger a process where OpenAI will ingest and analyze the existing page. It will extract values to populate your node fields, and then you can review or change those values before saving the node.
  • In the configuration you can specify the AI model to use, a maximum content length, an HTTP request timeout value, which content types should have the importer available, and then also prevent abuse by specifying blocked domains, a flood limit, and a flood window. You will also need to grant a new permission to use the importer for any user roles that should have access.
  • The module also includes a number of safeguards. For example, it will only accept URLs using HTTP or HTTPS protocols, private IP ranges are blocked, and by default it will only allow 5 requests per user per hour. It will perform HTML purification for long text fields, and strip tags for short text fields. In addition, it removes dangerous attributes like onclick or inline javascript, and generates CKEditor-compatible output.
  • It currently supports a list of field types that include text_long, text_with_summary, string, text, datetime, daterange, timestamps and link fields. It also supports entity reference fields, but only for taxonomy terms.
  • Listeners may also be aware of the Unstructured module which does some similar things, but requires you to use an Unstructured service or run a server using their software. So I would say that AI Single Page Importer is perhaps a little more narrow in scope but works with an OpenAI account instead of requiring the less commonly used Unstructured.

16 Feb 2026 7:00pm GMT

16 Feb 2026 4:00pm GMT

Four PHP Communities, One Uncomfortable Conversation

ashrafabed Mon, 02/16/2026

16 Feb 2026 1:58pm GMT

16 Feb 2026 1:48pm GMT

It was fantastic to see Ivan Zugec diving deep into our ecosystem! We actually popped into the chat during the stream (he jokingly referred to us as the "End Boss"), and it was great to see him exploring the capabilities of Display Builder alongside UI Suite DaisyUI.Here is our recap of his session available on WebWash youtube channel:

16 Feb 2026 12:14pm GMT

The UK's largest Drupal event arrives at the University of Salford, Manchester on 28th February - 1st March - and there's something for everyone, whether you're a seasoned Drupal professional or simply curious about what open source technology can do for your organisation.

16 Feb 2026 12:00pm GMT

16 Feb 2026 9:28am GMT

Mutagen has been a part of DDEV for years, providing dramatic performance improvements for macOS and traditional Windows users. It's enabled by default on these platforms, but understanding how it works, what can go wrong, and how to debug issues is key to getting the most out of DDEV.

Just Need to Debug Something?

If you're here because you just need to debug a Mutagen problem, this will probably help:

ddev utility mutagen-diagnose

See more below.

Contributor Training Video

This blog is based on the Mutagen Fundamentals and Troubleshooting Contributor Training held on January 22, 2026.

See the slides for the training video.

What Mutagen Does

Mutagen is an asynchronous file synchronization tool that decouples in-container reads and writes from reads and writes on the host machine. Each filesystem enjoys near-native speed because neither is stuck waiting on the other.

Traditional Docker bind-mounts check every file access against the file on the host. On macOS and Windows, Docker's implementation of these checks is not performant. Mutagen solves this by maintaining a cached copy of your project files in a Docker volume, syncing changes between host and container asynchronously.

Mostly for PHP

The primary target of Mutagen syncing is PHP files. These were the fundamental problem with Docker as the number of files in a Docker-hosted PHP website grew into the Composer generation with tens of thousands of files, so php-fpm had to open so very many of them all at once. Now with DDEV on macOS using Mutagen, php-fpm is opening files that are just on its local Linux filesystem, not opening ten thousand files that all have to be verified on the host.

Webserving Performance Improvement

Mutagen has delighted many developers with its web-serving performance. One dev said "the first time I tried it I cried."

Filesystem Notifications

Mutagen supports filesystem notifications (inotify/fsnotify), so file-watchers on both the host and inside the container are notified when changes occur. This is a significant advantage for development tools that would otherwise need to poll for changes.

How Mutagen Works in DDEV

When Mutagen is enabled, DDEV:

1. Mounts a Docker volume onto /var/www inside the web container
2. A Linux Mutagen daemon is installed inside the web container
3. A host-side Mutagen daemon is started by DDEV
4. The two daemons keep each other up-to-date with changes on either side

Lifecycle

• ddev start: Starts the Mutagen daemon on the host if not running, creates or resumes sync session
• ddev stop: Flushes sync session to ensure consistency, then pauses it
• ddev composer: Triggers synchronous flush after completion to sync massive filesystem changes
• ddev mutagen reset: Removes the Docker volume and the sync session will then be recreated from scratch (from the host-side contents) on ddev start.

Upload Directories

DDEV automatically excludes user-generated files in upload_dirs from Mutagen syncing, using bind-mounts instead. For most CMS types, this is configured automatically, for example:

• Drupal: sites/default/files
• WordPress: wp-content/uploads
• TYPO3: fileadmin, uploads

If your project has non-standard locations, override defaults by setting upload_dirs in .ddev/config.yaml.

We do note that upload_dirs is not an adequate description for this behavior. It was originally intended for user-generated files, but now is used for heavy directories like node_modules, etc.

Common Issues and Caveats

Initial Sync Time

The first-time Mutagen sync takes 5-60 seconds depending on project size. A Magento 2 site with sample data might take 48 seconds initially, 12 seconds on subsequent starts. If sync takes longer than a minute, you're likely syncing large files or directories unnecessarily.

Large node_modules Directories

Frontend build tools create massive node_modules directories that slow Mutagen sync significantly. Solution: Add node_modules to upload_dirs:

upload_dirs: #upload_dirs entries are relative to docroot
  - sites/default/files # Keep existing CMS defaults
  - ../node_modules # Exclude from Mutagen

Then run ddev restart. The directory remains available in the container via Docker bind-mount.

File Changes When DDEV is Stopped

If you change files (checking out branches, running git pull, deleting files) while DDEV is stopped, Mutagen has no awareness of these changes. When you start again, it may restore old files from the volume.

Solution: Run ddev mutagen reset before restarting if you've made significant changes while stopped. That removes the volume so everything comes first from the host side in a fresh sync.

Simultaneous Changes

If the same file changes on both host and container while out of sync, conflicts can occur. This is quite rare but possible with:

• Scripts running simultaneously on host and in container
• Massive branch changes
• Large npm install or yarn install operations

Best practices:

• Do Git operations on the host, not in the container
• Use ddev composer for most composer operations
• Run ddev mutagen sync after major Git branch changes
• Run ddev mutagen sync after manual Composer operations done inside the container

Disk Space Considerations

Mutagen increases disk usage because project code exists both on your computer and inside a Docker volume. The upload_dirs directories are excluded to mitigate this.

Watch for volumes larger than 5GB (warning) or 10GB (critical). Use ddev utility mutagen-diagnose --all to check all projects.

Debugging Mutagen Issues

The New ddev utility mutagen-diagnose Command

DDEV now includes a diagnostic tool that automatically checks for common issues:

ddev utility mutagen-diagnose

This command analyzes:

• Volume sizes: Warns if >5GB, critical if >10GB
• Upload directories configuration: Checks if properly configured for your CMS
• Sync session status: Reports problems with the sync session
• Large directories: Identifies node_modules and other large directories being synced
• Ignore patterns: Validates Mutagen exclusion configuration

Use --all flag to analyze all Mutagen volumes system-wide:

ddev utility mutagen-diagnose --all

The diagnostic provides actionable recommendations like:

⚠ 3 node_modules directories exist but are not excluded from sync (can cause slow sync)
  → Add to .ddev/config.yaml:
    upload_dirs:
      - sites/default/files
      - web/themes/custom/mytheme/node_modules
      - web/themes/contrib/bootstrap/node_modules
      - app/node_modules
  → Then run: ddev restart

Debugging Long Startup Times

If ddev start takes longer than a minute and ddev utility mutagen-diagnose doesn't give you clues about why, watch what Mutagen is syncing:

ddev mutagen reset  # Start from scratch
ddev start

In another terminal:

while true; do ddev mutagen st -l | grep "^Current"; sleep 1; done

This shows which files Mutagen is working on:

Current file: vendor/bin/large-binary (306 MB/5.2 GB)
Current file: vendor/bin/large-binary (687 MB/5.2 GB)
Current file: vendor/bin/large-binary (1.1 GB/5.2 GB)

Add problem directories to upload_dirs or move them to .tarballs (automatically excluded).

Monitoring Sync Activity

Watch real-time sync activity:

ddev mutagen monitor

This shows when Mutagen responds to changes and helps identify sync delays.

Manual Sync Control

Force an explicit sync:

ddev mutagen sync

Check sync status:

ddev mutagen status

View detailed status:

ddev mutagen status -l

Troubleshooting Steps

1. Verify that your project works without Mutagen:

   ddev config --performance-mode=none && ddev restart
   

2. Run diagnostics:

   ddev utility mutagen-diagnose
   

3. Reset to clean .ddev/mutagen/mutagen.yml:

   # Backup customizations first
   mv .ddev/mutagen/mutagen.yml .ddev/mutagen/mutagen.yml.bak
   ddev restart
   

4. Reset Mutagen volume and recreate it:

   ddev mutagen reset
   ddev restart
   

5. Enable debug output:

   DDEV_DEBUG=true ddev start
   

6. View Mutagen logs:

   ddev mutagen logs
   

7. Restart Mutagen daemon:

   ddev utility mutagen daemon stop
   ddev utility mutagen daemon start
   

Advanced Configuration

Excluding Directories from Sync

Recommended approach: Use upload_dirs in .ddev/config.yaml:

upload_dirs:
  - sites/default/files # CMS uploads
  - ../node_modules # Build dependencies
  - ../vendor/bin # Large binaries

Advanced approach: Edit .ddev/mutagen/mutagen.yml after removing the #ddev-generated line:

ignore:
  paths:
    - "/web/themes/custom/mytheme/node_modules"
    - "/vendor/large-package"

Then add corresponding bind-mounts in .ddev/docker-compose.bindmount.yaml:

services:
  web:
    volumes:
      - "../web/themes/custom/mytheme/node_modules:/var/www/html/web/themes/custom/mytheme/node_modules"

Always run ddev mutagen reset after changing mutagen.yml.

Git Hooks for Automatic Sync

Add .git/hooks/post-checkout and make it executable:

#!/usr/bin/env bash
ddev mutagen sync || true

chmod +x .git/hooks/post-checkout

Use Global Configuration for performance_mode

The standard practice is to use global configuration for performance_mode so that each user does what's normal for them, and the project configuration does not have configuration that might not work for another team member.

Most people don't have to change this anyway; macOS and traditional Windows default to performance_mode: mutagen and Linux/WSL default to performance_mode: none.

When to Disable Mutagen

Disable Mutagen if:

• You're on Linux or WSL2 (already has native performance)
• Filesystem consistency is more critical than webserving performance
• You're troubleshooting other DDEV issues

Disable per-project:

ddev mutagen reset && ddev config --performance-mode=none && ddev restart

Disable globally:

ddev config global --performance-mode=none

Mutagen Data and DDEV

DDEV uses its own Mutagen installation, normally in ~/.ddev, but using $XDG_CONFIG_HOME when that is defined.

• Binary location: $HOME/.ddev/bin/mutagen or ${XDG_CONFIG_HOME}/ddev/bin/mutagen
• Data directory: $HOME/.ddev_mutagen_data_directory

Access Mutagen directly:

ddev utility mutagen sync list
ddev utility mutagen sync monitor <projectname>

Summary

Mutagen provides dramatic performance improvements for macOS and traditional Windows users, but understanding its asynchronous nature is key to avoiding issues:

• Use ddev utility mutagen-diagnose as your first debugging step
• Configure upload_dirs to exclude large directories like node_modules or heavy user-generated files directories
• Run ddev mutagen reset after file changes when DDEV is stopped
• Do Git operations on the host, not in the container
• Monitor sync activity with ddev mutagen monitor when troubleshooting

The benefits far outweigh the caveats for most projects, especially with the new diagnostic tools that identify and help resolve common issues automatically.

For more information, see the DDEV Performance Documentation and the Mutagen documentation.

Copilot was used to create an initial draft for this blog, and for subsequent reviews.

14 Feb 2026 1:39am GMT

Image

Imagen

13 Feb 2026 6:20pm GMT

Our webinar on Drupal CMS + Meridian theme is up on YouTube! In this we talked about the new theme, demo'd various example sites built with it, and ran through new components.

We also talked about our differences with Drupal CMS's built in Byte theme and site template.

Enjoy!

13 Feb 2026 4:18pm GMT

1xINTERNET and React online have joined forces, React Online will become the Dutch subsidiary of 1xINTERNET. Same great people, same trusted partnerships, now backed by a team of 90+ experts across Europe.

13 Feb 2026 12:00pm GMT