Drupal 11.4.0, AI Workflows, and Orchestration
Recent Drupal developments point to a clearer direction for the project’s AI and developer-experience work. The immediate story is not only that Drupal is adding AI features.
Core performance, upgrade tooling, workflow orchestration, and AI governance are beginning to converge around a more controlled operating layer for modern web teams. That makes maintainability, auditability, and human review central to Drupal’s AI direction, not secondary safeguards.
Drupal 11.4.0, published on 1 July 2026, gives that direction a stronger core foundation. The release reduces database queries compared with Drupal 11.3, speeds up recipe-based site installation, improves translation file handling, and adds Brotli compression for aggregated CSS and JavaScript when ext-brotli is available. It also introduces an experimental extensible native command-line interface through ./vendor/bin/dr, improves password hashing with support for argon2id, and adds display-management changes intended to support tools such as Drupal Canvas.
The AI layer is moving in the same direction. Drupal AI 1.4.0 adds developer-focused drush generate commands for providers, automators, guardrails, operation types, API explorers, function calls, and related extension points. The release also introduces chat normalisation, Views Bulk Operations integration for AI Automators, failover foundations, and streaming guardrails.
Two Drupal core issues in responsive images you may be experiencing and not know it
In early 2025 I noticed an odd behavior with how responsive images were rendering in my Drupal site. This was a Drupal 10.4 site and the configuration I set was being ignored causing images to render smaller than expected.
I have worked with responsive images for many years and have written a 7-part blog series about them, and have never run into this issue until now.
Note: The issues described in this post do not affect the <picture> element. They are only present when using the srcset and sizes attributes of the <img> tag.
After some debugging and testing, I noticed the image rendering issue was directly related to the fallback image style used in the responsive images UI. The original purpose of the fallback image is to be used in the event the browser does not support responsive images. As of the date of this post, the browser support for srcset, sizes, and <picture> is at about 97%, which pretty much means it is no longer an issue in almost all cases.
The responsive_image core module in Drupal started explicitly adding width and height attributes to the <img> tag from the fallback image's dimensions. This was a fix for an issue in Drupal core 10.1.x-dev, which was closed (fixed) on August 9, 2023.
Rendering image at 325 x 217px (fallback image dimensions), but the loaded image is 2600 x 1733px.
DDEV v1.25.3: Faster Start and Stop, Built-in Docker Compose, Stable Podman, MariaDB 12.3 LTS
We're announcing DDEV v1.25.3: faster ddev start and ddev stop, built-in Docker Compose, stable Podman and Docker Rootless support, MariaDB 12.3 LTS support, Node.js improvements, XDG_CONFIG_HOME changes, and more.
This release represents 131 PRs from the entire DDEV community: your suggestions, bug reports, code, and financial support made it possible.
Table of Contents Fasterddev start, ddev stop, and ddev restart
ddev start in v1.25.3 (bottom) is faster than in v1.25.2 (top), including a faster warm start:
ddev stop in v1.25.3 (bottom) is significantly faster than in v1.25.2 (top), and the same improvement also applies to ddev poweroff and ddev delete, since all three share the same code path:
ddev restart in v1.25.3 (bottom) is significantly faster than in v1.25.2 (top), since it stops and starts a project and benefits from both improvements:
Post-healthcheck tasks now run concurrently instead of one after another, reducing overall ddev start time, thanks to @jonesrussell.
A bug in the web server startup script also added a ~10-second delay to ddev stop. That delay is now gone.
Mapping the Drupal AI Ecosystem: Building an Automated Module Tracker
No data, no problem: computed fields made simple
It's often useful to let the machines do the work, and output something that's dynamically computed on an entity. By that I mean something that can't be hardcoded as a fixed value for all entities of a particular type, but that varies for each entity, in a way that allows it to be generated in code rather than laboriously entered into each entity form by humans.
For example, you might want a backlink for an entity reference, or a link to a view that has an argument for the entity's ID, or something that depends on field values on the entity.
There are several ways in Drupal of putting something dynamic on the entity's display output. You can of course add something to the build array yourself, in either the entity's view handler or hook_entity_view(). The extra fields system lets you then declare your additional build array item with hook_entity_extra_field_info() which allows it to be rearranged among normal fields in the field admin UI.
This is okay, but the extra fields system is Drupal 5-era stuff. Your piece of build array is just that, some render stuff; it can't participate in any data structures and nothing else will recognise it and work with it.
A better approach is a computed field. This involves a little more boilerplate code than the extra fields technique, but there are several benefits.
The first is that you are defining a field value, not a render array, and you get access to all the field formatters that apply to your type of data. So for example, if your computed data is a URL, you get all of the link field formatters at your disposal, in core and contrib.
No data, no problem: computed fields made simple
It's often useful to let the machines do the work, and output something that's dynamically computed on an entity. By that I mean something that can't be hardcoded as a fixed value for all entities of a particular type, but that varies for each entity, in a way that allows it to be generated in code rather than laboriously entered into each entity form by humans.
For example, you might want a backlink for an entity reference, or a link to a view that has an argument for the entity's ID, or something that depends on field values on the entity.
There are several ways in Drupal of putting something dynamic on the entity's display output. You can of course add something to the build array yourself, in either the entity's view handler or hook_entity_view(). The extra fields system lets you then declare your additional build array item with hook_entity_extra_field_info() which allows it to be rearranged among normal fields in the field admin UI.
This is okay, but the extra fields system is Drupal 5-era stuff. Your piece of build array is just that, some render stuff; it can't participate in any data structures and nothing else will recognise it and work with it.
A better approach is a computed field. This involves a little more boilerplate code than the extra fields technique, but there are several benefits.
The first is that you are defining a field value, not a render array, and you get access to all the field formatters that apply to your type of data. So for example, if your computed data is a URL, you get all of the link field formatters at your disposal, in core and contrib.
Canvas Internals - JSON data types in different databases: It works on my machine!
Drupal has been working to add a JSON data type since 2023, but that has not landed yet. Drupal Canvas jumps ahead of that in its inputs for a component tree item with
'inputs' => [
'description' => 'The input for this component instance in the component tree.',
'type' => 'json',
'pgsql_type' => 'jsonb',
'mysql_type' => 'json',
'sqlite_type' => 'json',
'not null' => FALSE,
],Recently some of our tests started failing for MySQL and Postgres on CI, but passed in SQLite and MariaDB, which is what most of us use locally.
The problem was that the sorting of the keys of that field was not deterministic, and we used assertSame in our tests to see if operations added/removed the inputs as expected when components evolved.
How does that translate to different engines?
For MySQL, there's a native data type. Quoting their docs:
To make lookups more efficient, MySQL also sorts the keys of a JSON object. You should be aware that the result of this ordering is subject to change and not guaranteed to be consistent across releases.
Canvas Internals - JSON data types in differentes databases: It works on my machine!
Drupal has been working to add a JSON data type since 2023, but that has not landed yet. Drupal Canvas jumps ahead of that in its inputs for a component tree item with
'inputs' => [
'description' => 'The input for this component instance in the component tree.',
'type' => 'json',
'pgsql_type' => 'jsonb',
'mysql_type' => 'json',
'sqlite_type' => 'json',
'not null' => FALSE,
],Recently some of our tests started failing for MySQL and Postgres on CI, but passed in SQLite and MariaDB, which is what most of us use locally.
The problem was that the sorting of the keys of that field was not deterministic, and we used assertSame in our tests to see if operations added/removed the inputs as expected when components evolved.
How does that translate to different engines?
For MySQL, there's a native data type. Quoting their docs:
To make lookups more efficient, MySQL also sorts the keys of a JSON object. You should be aware that the result of this ordering is subject to change and not guaranteed to be consistent across releases.
How to Integrate Google Cloud Storage with Drupal: Step-by-Step Guide
Object-Oriented Form API in Drupal 11
Drupal 11.2 Hook Migration Guide: Modernize Your Module’s Hooks with Attributes
Drupal Theming and Layout: When to Use Paragraphs, Layout Builder, or Twig Templates
Why More Indexes in MySQL Aren't Always Better
How to Efficiently Load and Process 10,000 Nodes in Drupal Without Killing Performance
Mastering OOP and SOLID Principles in PHP with Drupal Examples: A Complete Guide
Combining Tailwind CSS and Bootstrap (Radix) in a Drupal Theme: A Step-by-Step Guide
Laravel for Drupal Developers: Comparing Eloquent and Entity API
Pages
