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 Faster ddev 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.

We benchmarked ddev start from a stopped state on both macOS and Linux, and v1.25.3 is faster on both. Numbers vary by machine, but you can reproduce it with scripts/compare-start-perf.sh:

git clone https://github.com/ddev/ddev ddev-upstream cd ddev-upstream bash scripts/compare-start-perf.sh v1.25.2 v1.25.3

On macOS, v1.25.3 is about 28% faster than v1.25.2 (benchmarked by @rfay):

Summary (ddev start from stopped state) ------------------------------------------------------------------- A (v1.25.2): median=11.03s trimmed-mean=10.49s B (v1.25.3): median=7.91s trimmed-mean=7.84s B is FASTER than A by 3.12s (-28.3%) on median

On Linux, it's about 21% faster (benchmarked by @stasadev):

Summary (ddev start from stopped state) ------------------------------------------------------------------- A (v1.25.2): median=18.03s trimmed-mean=18.25s B (v1.25.3): median=14.18s trimmed-mean=14.96s B is FASTER than A by 3.85s (-21.4%) on median New Docker Compose Library

DDEV now uses the Docker Compose SDK directly instead of shelling out to a separate docker-compose binary. The $HOME/.ddev/bin/docker-compose binary DDEV used to download and manage can be removed. This switch was made possible by the Docker Compose maintainers, who exposed the SDK as a reusable library in Compose v5.0.0. Thank you very much!

Driving Compose through the SDK is also what gives you the cleaner output and live per-step timer in the GIFs above: DDEV now controls how progress is displayed instead of passing through whatever the external binary printed.

This is the same underlying change that added the optional ddev config global --docker-buildx-version setting in this release. See Docker Buildx Requirement in DDEV for the full background on Buildx and the Compose SDK switch.

MariaDB 12.3 LTS Support

DDEV now supports MariaDB 12.3, the latest LTS release. For new projects, set it with:

ddev config --database=mariadb:12.3

To migrate an existing project's database, use:

ddev utility migrate-database mariadb:12.3 Podman and Docker Rootless Are No Longer Experimental

Both Podman rootless and Docker rootless are now stable. We introduced this support as experimental in v1.25.0. See Podman and Docker Rootless in DDEV for the background, trade-offs, and the work behind it. Setup instructions:

• macOS (Podman rootless)
• Linux/WSL2 (Docker rootless)
• Linux/WSL2 (Podman rootless)

Node.js Changes

• The correct Node.js version is now used during the build phase of ddev start. Previously the build phase always used DDEV's default version, which could cause problems when a project specified a different one (see ddev-pnpm#14).
• If you install global npm packages in post-start hooks, move them to extra Dockerfiles instead, since those now run against the correct Node.js version.
• nodejs_version is now preserved in .ddev/config.yaml even when it matches DDEV's default (previously it was removed in that case).
• Setting nodejs_version: "" in .ddev/config.yaml always uses the default Node.js version bundled with DDEV, currently Node.js 24.
• You can install additional Node.js versions with ddev exec n install <version> inside the web container. This used to be a reason to use nvm, which was moved to the ddev-nvm add-on in v1.25.0; with n built-in, you no longer need nvm for it.
• N_PREFIX moved from /usr/local to /usr/local/n.
• See the updated nodejs_version documentation for more details.

XDG_CONFIG_HOME Is No Longer Respected, but DDEV_XDG_CONFIG_HOME Is Available

We received several reports of DDEV recreating $HOME/.ddev repeatedly:

Warning: multiple global DDEV configurations found, /home/stas/.config/ddev is used, /home/stas/.ddev is not used, delete one of them to avoid confusion

IDEs such as PhpStorm don't always see XDG_CONFIG_HOME from the terminal, so DDEV fell back to and recreated $HOME/.ddev repeatedly. See the upstream issue IJPL-1055 for details.

To avoid this problem, DDEV now reads its own environment variable, DDEV_XDG_CONFIG_HOME, and no longer respects XDG_CONFIG_HOME. If you had set XDG_CONFIG_HOME to something other than its default of $HOME/.config, set DDEV_XDG_CONFIG_HOME to that same value instead.

Support for using $HOME/.config/ddev as the global configuration directory on Linux is unchanged.

Everything Else

This release includes many more features and bugfixes. See the full release notes for the complete list.

From the entire team, thanks for using, promoting, contributing, and supporting DDEV!

If you have questions, reach out in any of the support channels.

Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.

This article was edited and refined with assistance from Claude Code.

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.

The second is that anything that works with fields will be aware of your computed field. So you can add it to a view as a field (though not a sort or filter of course, since it has nothing in the database). You can add it to a SearchAPI index (and there, you actually can filter on it, because SearchAPI will index the computed value into its backend).

The code

Here's what you need to do. You need two things:

1. A FieldItemList class.
2. A declaration of your field in an entity class or field info hook.

Unlike declaring code fields, you don't need to declare a field storage: that's because a computed field doesn't store anything!

1. The FieldItemList class

Create a subclass of \Drupal\Core\Field\FieldItemList that uses \Drupal\Core\TypedData\ComputedItemListTrait. In this class, all you need to do is implement computeValue() to return your data.

<?php // The namespace doesn't matter, but I like to put it under \Field. namespace Drupal\my_module\Field; use Drupal\Core\Field\FieldItemList; use Drupal\Core\TypedData\ComputedItemListTrait; use Drupal\Core\Url; /** * Field item list class for my computed field. */ class MyFieldFieldItemList extends FieldItemList { use ComputedItemListTrait; /** * {@inheritdoc} */ protected function computeValue() { // You have access to the complete entity, so you can use other field // values. $entity = $this->parent->getValue(); // Create a field item for your data. You can create more than one for a // multi-valued field. $this->list[] = $this->createItem(0, [ 'value' => 'cake', ]); } } ?>

For most field types, the key to use in the item array is 'value', but some more specialised fields use something else. You can find this by looking in the field item class for the field type. For example, in \Drupal\link\Plugin\Field\FieldType\LinkItem::propertyDefinitions() you can see that for a link field, you need these array keys:

$this->list[] = $this->createItem(0, [ 'title' => $this->t('My link title'), 'uri' => $some_url_that_we-compute->toUriString(), ]); 2. Define the field

For the field definition, there are two things to consider:

• Is it on an entity type you control, or somebody else's?
• Do you want a base field or a bundle field?

If it's your own entity type, you define the field in the entity class, in either the baseFieldDefinitions() or bundleFieldDefinitions() method. If it's an existing entity type, you need to use hook_entity_base_field_info() or hook_entity_bundle_field_info().

In all cases, the code is broadly similar. For a base field, it looks like this:

/** * Implements hook_entity_base_field_info(). */ #[Hook('entity_base_field_info')] function entityBaseFieldInfo(EntityTypeInterface $entity_type) { if ($entity_type->id() == 'node') { $fields = []; $fields['my_computed_field'] = BaseFieldDefinition::create('link') ->setLabel($this->t('My computed field')) ->setDescription($this->t('My field is amazing.')) // This declares it as a computed field. ->setComputed(TRUE) // This is the class you created earlier, which provides the values. ->setClass(MyFieldFieldItemList::class) // Optional default view display options, which can be overriden in the admin UI. ->setDisplayOptions('view', [ 'label' => 'above', 'type' => 'link', 'weight' => '0', ]); return $fields; } }

For a bundle field, you need the Drupal\entity\BundleFieldDefinition class from Entity module, and a few extra things need to be explicitly set on the definition because the field system doesn't handle them for you:

$fields['my_computed_field'] = BundleFieldDefinition::create('link') ->setName('my_computed_field') ->setTargetEntityTypeId($entity_type_id) ->setTargetBundle($bundle) // Rest of the definition as above.

See my earlier blog post on bundle fields for more about their uses and their quirks.

The contrib module

If you want to do it all with less boilerplate, or your computed field is something that's reusable across different entity types, consider the Computed Field module as an alternative to the code examples above. Instead of a Field class, the computational code does in a plugin, which the module then makes available in an admin UI where you can create and edit computed fields alongside the usual stored fields.

And if your computed field is purely a render array rather than data, the Computed Field module also provides a computed_render_array field type for that, with an accompanying field formatter.

Do you need help with data structures, and their integration with Views or SearchAPI? I'm available for hire - contact me!

joachim Sun, 05/07/2026 - 16:02 Tags

• Field API
• Drupal core

Canvas Internals - JSON data types in differentes databases: It works on my machine! Image

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.

For PostgreSQL, the engine offers two different data types: json and jsonb, with the second being the option we (and core) opted for because of its efficiency. But that's key, as the docs explain:

In general, most applications should prefer to store JSON data as jsonb, unless there are quite specialized needs, such as legacy assumptions about ordering of object keys.

That's exactly what our problem was.

For MariaDB, the JSON type is just an alias. See their docs:

JSON is an alias for LONGTEXT COLLATE utf8mb4_bin introduced for compatibility reasons with MySQL's JSON data type. MariaDB implements this as a LONGTEXT rather, as the JSON data type contradicts the SQL:2016 standard, and MariaDB's benchmarks indicate that performance is at least equivalent.

And the last one, SQLite, has support for a jsonb format since 3.45, but the work in progress for introducing this in Core uses json, which, like MariaDB, is ordinary text and sorting of the keys is respected.

How did we fix this?

The actual sorting of the inputs in the database is, as of today, irrelevant to us. So we ended up with:

• Our own assertSameInputs, which sorts the keys before comparison. assertEqualsCanonicalizing is not an option, as that sorts by value.
• Our own PHPStan rule, which is not 100% accurate but detects most usages of assertSame with these inputs, and suggests using assertSameInputs instead. 

Translating Drupal Canvas

This is just one of the many show-stoppers that we faced while working on the much-anticipated symmetric translation support for Drupal Canvas. If you want to test this experimental feature, check the release notes in Canvas 1.7.0, but please only on test sites for now!

penyaskito Sat, 07/04/2026 - 18:24 Tags

• contributing
• Drupal
• Drupal Core
• Drupal Canvas
• multilingual
• databases
• PHPStan
• JSON
• Drupal planet
• testing

• Read more about Canvas Internals - JSON data types in differentes databases: It works on my machine!
• Add new comment

Shibin Das explains why visual workflow tools need visible execution, audit trails, runtime ownership, and clear boundaries between deterministic workflows and AI-assisted decision-making.

Every Drupal developer eventually hits this wall: a client or editor requests that a standard text field (like a headline or subheadline) be expanded from 255 to 512 characters. You change the value in the field configuration YAML or try to update it programmatically via the Entity API, only to be hit with a fatal exception.

Release timing is often treated as calendar work, but the 11.4.0 delay exposed a dependency problem beneath the schedule. The fix changes how selected Composer dependencies can move when security updates land.

Many Drupal sites are fast when launched, but become heavier over the years. The cause is usually not Drupal itself, but how the platform is maintained, extended and filled with content over time. Slowness rarely comes from one change A Drupal site does not usually become slow overnight. It is usually a gradual process: more content is added; more images and files are uploaded; new modules are installed; small custom features are built; analytics, marketing and chat scripts are added; cache or server configuration falls behind; old solutions remain in place next to new ones. Each individual change may seem small. Together, they can make the site slower, harder to manage and more expensive to develop further. Content growth has a bigger impact than expected A large organisation's Drupal…

Alias Your Local DDEV Commands mandclu Jul 2, 2026 - 1:19am Like a lot of other people in the Drupal community, I exclusively use DDEV for local development. I am regularly impressed by the breadth of features it offers out-of-the-box, and the add-on architecture means you can easily bring in additional capabilities as you need them. Recently, I even decided to vibe-code my own add-on to make it easy to run code validation checks and automated tests locally before pushing code. The working result has been transformative, allowing me to ship more code, with higher confidence, on more contrib projects. One lingering point of friction for me has been the need to remember to prefix common tutorial commands with ddev for them to work as expected. I've been thinking about aliasing drush to ddev drush for some time, and I was even on a call with someone More

The fourth feature release of Drupal 11 is another performance breakthrough. Using only a third of the database and cache lookups compared to Drupal 11.0 and 10.6 for the same requests. It also comes with 15-25% better compression of JS and CSS, much faster translation file handling, a new native command line interface, improved password hashing and a lot more.

New in Drupal 11.4 Biggest performance improvement of the decade (again!)

With Drupal 11.3, we announced that it was the biggest performance improvement of the decade. Drupal 11.4 is arguably the biggest performance improvement of the decade again!

Drupal 11.4 reduces database queries by half compared to 11.3 across a wide range of requests due to optimizations in how entity fields are loaded.

Now, on a completely cold cache, Drupal 11.4 will execute just over 1/3rd of the database and cache lookups compared to Drupal 11.0 or 10.6, representing hundreds of milliseconds saved.

As well as entity loading, entity listing queries have also been significantly improved via reducing the number of table joins, leading to fewer slow queries. This should particularly benefit sites using JSON:API.

To reduce the cost of rendering menus and improve render cache hit rates, menu blocks now have a configuration option to not generate CSS classes for ancestor menu links.

Applying recipes, such as setting up Drupal CMS is twice as fast

We have made recipe-based site installation twice as fast. This significantly improves the UX of installing Drupal CMS and other site recipes. Installing individual recipes is also markedly faster.

Translation file handling: dramatically faster with a modern API

Importing translations during the installer or during site operation is now much faster. On a test site with 66 projects and 38 languages, checking for translation updates was 87% faster on Drupal 11.4 compared to 11.3.

The APIs handling translation files and import have undergone an extensive modernization effort. All .inc files and several important APIs in locale.module have been deprecated and updated to OOP with special attention paid to performance and organization.

15-25% better compression of JS and CSS

Drupal now supports Brotli compression for aggregated CSS and JavaScript files in addition to the existing gzip compression. Brotli typically provides 15-25% better compression ratios than gzip, resulting in faster page loads for browsers that support it. The feature relies on the PHP Brotli extension: ext-brotli.

Immediate security updates of key dependencies allowed in core-recommended

The drupal/core-recommended package no longer pins minor versions for dependencies like Guzzle, Twig, and Symfony Polyfills. In the past, stricter version rules and Composer 2.9's blocking behaviour forced sites to wait for a new Drupal release to get important security fixes. Now, you can install these security fixes immediately. Since the updated dependencies at that time may not have been tested with Drupal core yet, site owners should ensure adequate quality assurance occurs before deploying to production.

New experimental extensible native command line interface

A new extensible ./vendor/bin/dr command line interface was added. While Drupal already includes a CLI script with hardcoded commands, it is not extensible. This new interface was built by a team which included the maintainers of the Drush utility. Drush has been a mainstay for people using Drupal with the command line. Now a transitional period starts as Drush is gradually replaced with the core dr CLI over time. Learn how to make your existing Drush commands compatible.

Simplified and updated default experience

The default installation, the Standard profile, is now leaner. It no longer includes the Article and Page content types, and commenting is disabled by default. Further core startup simplifications are planned for upcoming releases.
The Navigation module is now enabled in the standard administrative interface. The legacy Toolbar module remains available but is scheduled for removal in Drupal 12.

Better entity display management for display builders such as Drupal Canvas

A new overview page has been added under the "Manage display" tab for content entity bundles. Previously, this tab led to the form editing the default view mode. Now, it lists all display modes for the bundle with their label and description and allows one to toggle the enabled/disabled status. The listing makes it easier to integrate tools such as Drupal Canvas.

Distraction-free editing available with CKEditor

Text formats using CKEditor can now be configured to include the FullScreen plugin. This plugin lets users expand the editor to the whole browser viewport, giving more space to comfortably edit content in a distraction-free environment.

Improved password hashing available

The password hashing algorithm is now configurable. The new argon2id option provides much stronger hashing compared to the old bcrypt method. Drupal 12 will default to argon2id, but your site can already start to adopt it. If you update the setting, users' passwords will be rehashed on their next login.

Do more with PHP attributes

You can now use attributes on your controllers to specify the routes the controller is used for. Any class in a module's Controller namespace (for example, Drupal\example\Controller) that have the Symfony\Component\Routing\Attribute\Route attribute will be picked up as route definitions. Even multiple routes can be defined on one class. This supplements the existing .routing.yml based declarations.

It is now possible to use the Drupal\Core\Entity\Attribute\Bundle attribute to define bundle classes, when in need of specific logic for an entity subtype. This previously required an entity_type_info or entity_type_info_alter implementation.

No more .theme files, only a few .module files left

All .theme and .theme-settings.php files in core have moved to PHP classes. Support for .theme files is still planned to be retained in Drupal 12 to ease the transition, but will be removed in Drupal 13.

Most .module files have been converted too: 32 modules are fully converted to PHP classes, with 11 modules remaining (4 of which are deprecated for removal in Drupal 12).

A team of 26 key contributors worked on 57 issues since January 2026 to get here, making Drupal's code more consistent. Also thanks to the dozens of users that worked on the many decades old issues that this initiative built upon.

Front controllers now utilize symfony/runtime

Drupal now integrates the Symfony Runtime component to separate bootstrapping logic from request handling. This provides a clear separation of concerns between preparing the environment (runtime) and handling a request, which will also later enable better integration with FrankenPHP.

Write faster tests with new helper method

A new trait for kernel tests, HttpKernelUiHelperTrait, allows kernel tests to make HTTP requests to the test site and make assertions against the returned content. This has the potential for many browser tests to be converted to kernel tests, which are much faster to run because unlike browser tests, they don't fully set up a test site by running the Drupal installer.

New experimental administrative theme

The Gin administrative theme has been added to Drupal core as the "Default Admin" experimental theme. The theme includes a new dark mode option.

While it is not yet actually the default admin theme, when it becomes stable it will replace Claro as the look of Drupal's backend. We encourage module maintainers to test their module's UIs and provide feedback!

Core maintainer team updates

Since Drupal 11.3 Andrei Mateescu was appointed as a provisional general core committer and is now a Content Moderation and the Workflows module maintainer too. Also Edward Wu was appointed as provisional release manager.

Various wonderful contributors also took our call for subsystem maintainership:

• Moshe Weitzman is now a maintainer of the core CLI
• Derek Wright stepped up to be a Content Moderation and core CLI maintainer
• Kent Richards is a new accessibility maintainer
• Max Pogonowski was added as a maintainer for Menu UI and the token system
• Jürgen Haas and Sascha Eggenberger are maintainers of the new Default Admin theme
• Chris Weber was added as a maintainer for Settings Tray
• Stephen Mustgrave stepped up to maintain the Options module and Menu UI
• Lucas Hedding is now a maintainer for the Image module and the Authentication and Authorization subsystem
• Christian López Espínola is a new maintainer to the Language and Content Translation modules

We also thank maintainers that stepped down in this period:

• Heather Brooke Drummond stepped down from their maintainer role on Breakpoint and Responsive Image modules
• Brian Gilbert stepped down from his core mentoring role
• Wim Leers stepped down from being maintainer of Drupal's CKEditor integration, Editor module, JSON:API module and REST module
• Gareth Goodwin stepped down from maintaining the Umami demo

Want to get involved?

If you are looking to make the leap from Drupal user to Drupal contributor, or you want to share resources with your team as part of their professional development, there are many opportunities to deepen your Drupal skill set and give back to the community. Check out the Drupal contributor guide.

You would be more than welcome to join us at DrupalCon Rotterdam in September 2026 to attend sessions, network, and enjoy mentorship for your first contributions.

Drupal 12 is coming the week of December 7, 2026

Drupal 12 will be released with the upcoming Drupal 11.5 at the beginning of December this year. Drupal 11.5 will be a Long Term Support release with version 11 support expected until the end of 2028.

File attachments:  Drupal114Available.png DarkDrupalAdminPage.jpg

Image Credit: Mike Gifford

I spent last week at the UN in New York for Open Source Week. The AI sessions were sharp, well-attended, and full of people who have been thinking seriously about where this is all going. Ministers, engineers, researchers, cybersecurity practitioners.

And across four days of sessions, a picture kept assembling itself — not one anyone drew deliberately, but one that emerged from enough different people making enough adjacent points. By the end of the week I was fairly convinced that what the AI world is urgently trying to build, Drupal already is.

Read on and let me make the case.

The model is not the thing

Brian Behlendorf said it plainly: people talk about AI as if it's the model. It isn't. The model is one layer. What matters is the harness. How you orchestrate models, constrain them, route information, log outputs, build verification in. That's where the work happens. That's where the risk lives and where we create value.

Sara Hooker from Adaptation Labs made the same point from a different angle. We used to work in code and design. Interfaces were understood and boundaries were mostly clear. AI has moved us into unknown interfaces. The next step, she said, is dynamic, adaptable interfaces that allow humans to remain at the centre. Not interfaces that hand control to the model, but ones that keep the human in the loop while the model does the work.

I've been saying that Drupal has quietly become the most flexible and powerful AI harness available. This week gave me a room full of smart people explaining which helped bring that conviction into focus.

What a harness needs to do

Let me pull a few threads from the week.

It needs to constrain the model to known truth. One of the most interesting presentations came from a team that deployed a chatbot for Pittsburgh's Public Works department. The very first question from city officials was: "How do we know the answer is correct?" Their solution was a Data Concierge model — the AI is only permitted to answer questions against a defined dataset. If it can't answer from the data, it doesn't answer; the question goes into a queue. This makes the AI responses reproducible, traceable, and auditable.

That is what Drupal can do when you integrate AI into a content management workflow. The model doesn't get to hallucinate about your organisation's policies. It answers from what you've published, structured, and governed. The content model is the constraint.

It needs to aggregate intelligence, not just query a single model. Mostafa Elkordy from UNICC put this as clearly as anyone: every agent in isolation only has its own memory. The most critical and least understood capability in enterprise AI is intelligence harnessing. We need to pull all intelligence sources into a single coherent system. The organisations that figure this out will have a structural advantage. The ones that treat AI as a chat widget bolted onto a webpage will not.

Drupal's architecture is built for this. You have multiple data sources, multiple content types, relationships between entities, and views that aggregate and filter. This is what structured content management systems do best. Adding AI to that foundation is a multiplier. Adding AI to an unstructured system makes a mess.

It needs to keep humans in control, not in the dark.

Rodrigo Rodríguez, an AI & Quantum Architect at Microsoft made a point early in the week that I keep coming back to: AI is clustered around organised confidence. It rarely says "I don't know." Confidence is not evidence. The harness is the mechanism by which you decide what the AI is allowed to be confident about, and when it should surface uncertainty rather than paper over it.

Drupal's editorial workflows, content moderation, and publishing controls are part of a governance layer that sits between AI output and public consumption. A model can draft. A human approves. That's not a limitation. In fact, that's the architecture working as intended.

The verification problem

Tricia Wang made the argument I found most compelling across the entire week. We live in a claims-based AI world. A model asserts something is true. You have no mechanism to verify it independently. She called for a move to a verification-based world — ideally cryptographic — where claims can be checked against sources without exposing the underlying data.

She also made an observation that seemed obvious once she said it: we trust agents all the time. Every time you board a plane, you're trusting an agentic system — pilots, air traffic controllers, flight management software. We know how to govern this. We have liability frameworks, certification requirements, black boxes, independent investigation bodies. We just haven't built any of that for AI yet.

What Drupal offers in this space is structural transparency. Content has provenance. You can see who created it, when, what revision it's on, what workflow state it passed through. When AI is integrated into that system, the AI's contributions can be logged, reviewed, and attributed in the same way. That's the beginning of a verifiable AI layer — not cryptographic yet, but architecturally honest in a way that most AI deployments are not.

The zero-day exploit window is now down to seven days, according to Jim Zemlin from the Linux Foundation. In 2020 it was sixty. The security argument for keeping AI tightly integrated with auditable, open-source infrastructure isn't a theory. It is a requirement.

The sovereignty argument

David Shrier from Imperial College described intelligence as the next sovereign battlefield. The concentration of AI capability inside roughly eight companies is a structural problem. Hyperscalers are, in effect, concentrations of intelligence. Open source is the mechanism for distributing that intelligence more broadly.

Tanzania's Minister of Technology put it in terms I found more useful: her government is no longer a passive consumer of technology. It's an active creator. 90% of government systems are on open source. The savings from licence elimination have been reinvested in people. The workforce now owns the systems it builds.

The Drupal parallel is direct. When you run AI on Drupal, you're running it on infrastructure no single vendor controls. The model can be swapped. The hosting can be changed. The data stays yours. This is not a minor point — the lock-in risk in AI is real, and it's coming fast. The organisations building AI on proprietary stacks are creating dependencies they will spend years trying to unwind.

Morocco is building a 1 GW data centre and training 100,000 people a year in digital skills, specifically so it can run sovereign AI infrastructure with local values embedded. That's "open source as an instrument of sovereignty" at national scale. The same logic can apply at the organisational level.

The governance argument

The DPI sessions drove home a point that applies directly to AI: the technical system is rarely the problem. The governance is. Ethiopia has 98% ID coverage and 92% payment wallet adoption — and yet fewer than 5% of people can actually access the protections those systems are supposed to provide. The technology works but the governance doesn't.

Armando Manzueta from the Dominican Republic put it cleanly: treat AI with the same governance rigour as your core infrastructure. Without proper guardrails and oversight, you shouldn't do it at all. Human oversight must be embedded so mistakes can be corrected in real time.

This is an argument Drupal has been making implicitly for twenty-five years. Content governance — who can publish what, when, through what process — is the foundational problem that Drupal was built to solve. The workflows, roles, permissions, and moderation tools are a governance system for information. Extending that to AI output is not a conceptual leap. It just extends what Drupal already does.

The Premise

Here is the argument in full: the AI conversation at the UN kept arriving at the same destination from different directions. You need a harness, not just models. The harness needs to constrain the model to verified data. It needs to aggregate intelligence across sources. It needs human oversight and editorial control. It needs to be open source so it can be audited, forked, and owned. It needs governance built into the architecture, not bolted on afterwards.

What does that remind you of? Drupal with AI integration.

The Drupal work isn't finished. The AI modules aren't mature yet. The work won't be easy. I'm suggesting that the architectural foundation is right, and the architectural foundation is the hardest part. Most organisations are trying to build AI workflows on systems that weren't designed for governance, structured content, or auditability. They're going to spend a lot of time and money discovering what the DPI world learned the hard way: the technology problem is tractable. The governance problem is where things break. Our community even has a Road Map that describes many of these challenges.

Drupal solved the governance problem for content a long time ago. That foundation is now worth something more than it was worth two years ago.

Matthew Saunders works in AI and open-source infrastructure at amazee.io and has been building on Drupal since 2006.

File attachments:  55357069511_d841e14953_o.jpg

My LocalGov Drupal contributions for June 2026

At last, I've started work on microsites demo content.

markconroy 1st Jul 2026

The ECA Guide Revolution: Documentation Meets AI Jürgen Haas Wed 1 Jul 2026 - 12:00

ECA documentation stopped being only for humans. The ECA Guide at ecaguide.org is now machine-readable infrastructure - an MCP server at /mcp with three tools (search_docs, get_page, list_sections), an llms.txt structured index, llms-full.txt with about 151,000 words, and clean Markdown for any page by adding index.md to its URL. All 1,206 plugins are documented and auto-generated at /plugins/. An AI agent skill packages this: point an agent at the Guide, describe a workflow in plain English, and watch it read the token-syntax docs humans skip and build a working model with the right tokens on the first try. The numbers back it up. Over the last six months, humans made about 11,400 visits and 17,300 page views; machines through the MCP server made about 244,000 visits and 734,000 page reads. Around 21 times more visits and 42 times more reads from machines than humans (with honest caveats: machine traffic includes crawling, and an agent read is not a human learning). The pattern works for any complex Drupal system - Views, Layout Builder, Commerce could all do it. Documentation becomes infrastructure, and Drupal becomes AI-native rather than AI-adjacent.

Artificial intelligence is changing how we build, manage, and deliver digital experiences. But AI isn’t just a developer conversation. It’s also a conversation for architects, product owners, marketers, digital strategists, executives, and organisational leaders.

That’s why DrupalCon Rotterdam is introducing two dedicated AI summits on Monday, 28th September. Each has a different focus, but together they provide a complete picture of what AI means for the future of Drupal.

The AI Dev Summit

The AI Dev Summit is built for the people creating the next generation of Drupal experiences.

If you enjoy building, experimenting, and solving technical challenges, this summit is for you. Sessions focus on practical implementation, emerging AI capabilities, and the tools developers need to begin building AI-powered Drupal solutions today.

Topics include:

• AI-assisted development
• Drupal AI and Drupal CMS
• Canvas and modern AI workflows
• Building with AI frameworks and services
• Real-world technical demonstrations
• Best practices from experienced contributors

Whether you’re already working with AI or just beginning to explore what’s possible, the AI Dev Summit offers practical knowledge you can apply immediately.

The Enterprise AI Summit

Technology alone doesn’t create transformation. Organisations also need leadership, governance, strategy, and clear business objectives.

The Enterprise AI Summit focuses on those conversations.

Designed for digital leaders, executives, product managers, architects, and decision-makers, this summit explores how organisations can responsibly adopt AI while delivering measurable value.

Sessions examine questions such as:

• How should organisations develop an AI strategy?
• What governance models are needed?
• Where can AI deliver measurable business value?
• How do security, privacy, and compliance influence adoption?
• What organisational changes are required for successful AI implementation?
• What projects have leading global organisations deployed?

Rather than concentrating on implementation details, this summit focuses on helping organisations make informed decisions about AI.

Different audiences. Shared goals.

While each summit has its own emphasis, they are closely connected.

Successful AI initiatives require both technical expertise and organisational leadership.

Developers need leaders who understand the opportunities and challenges AI presents. Leaders need developers who can turn strategy into working solutions.

By offering both summits, DrupalCon recognises that AI adoption succeeds when technical innovation and business strategy move together.

Which summit should you attend?

Choose the AI Dev Summit if you:

• Build Drupal websites and applications
• Want hands-on technical sessions
• Are interested in Drupal AI, Canvas, and AI development tools
• Enjoy learning by seeing practical demonstrations
• Meet the makers of Drupal AI and expert practioners

Choose the Enterprise AI Summit if you:

• Lead digital strategy or technology initiatives
• Make technology investment decisions
• Manage products, teams, or digital transformation
• Want to understand how AI fits into organisational goals
• Meet leading practitioners and peers who have delivered successful solutions within their organizations

Of course, if your role bridges both worlds, you’ll likely find value in either summit.

Join us in Rotterdam

Whether you’re writing code, defining strategy, or helping your organisation navigate the future of AI, DrupalCon Rotterdam has a summit designed for you.

Whichever path you choose, you’ll leave with practical insights, new connections, and a deeper understanding of how AI is shaping the Drupal ecosystem.

We look forward to seeing you in Rotterdam.

File attachments:  banner_web_3400X720 (002).png

Colour brings life and vibrancy to your Drupal website and shapes how people feel when they visit it. The right palette can make your site feel bold and dynamic, warm and cozy, or reserved and professional. Colours enhance user experience by clarifying your website’s hierarchy and making interactive elements easier to recognize. That being said, colours are an essential part of a compelling Drupal website design. 

To better serve smaller organizations and those in a budget crunch, we’ve launched Tiny Services.

Anxiety about AI

The Drupal and broader software community are getting overly anxious about the new kids on the block… AI. I wanted to step back and explore this anxiety through the analogy of AI as the new kids on the block, or, more specifically, the new kids entering our software teams and community. It is important to view AI not as a single kid because AI consists of multiple LLMs and harnesses.

Therefore, our immediate expectation when working with AI is that there is no single way to prepare for or interact with AI that always works across all AIs. The inconsistency and unpredictability of the current state of AI, and how it impacts our work, is making people anxious, which is leading them to want tools and processes to prepare to collaborate with AI. I'm writing this post because I think people's anxiety about AI is making them overprepare.

Overpreparing for AI

A large part of the AI narrative centers on the tooling you need to use AI. I feel that most of the AI tooling is overbuilt or overplanned. At the same time, harnesses like OpenCode provide essential tools and methodologies for an LLM to write code and perform tasks. Still, a harness is just a tool for AI, like the computer and software I am using to write this post.

The tooling and planning I am concerned about involve AI-specific processes for managing and orchestrating AI agents. Many people in the software community are developing AI best practices to address the challenge of integrating AI into our software development process.

A quick aside. I think having AI best practices for Drupal as a collaborative, community-led initiative is essential to Drupal's proper adoption of agent-driven development. Before someone starts using Drupal's AI best practices, they should understand what AI is.

What exactly is AI?

I don't know...Read More

Back in 2019, I wrote that Open Source is not a meritocracy. Meritocracy says talent is the only thing that counts, but that is not true. To contribute, you also need time, a steady income, and a flexible schedule. Plenty of people lack one or more of these.

Some people can give their nights and weekends to learning a codebase, clearing the issue queue, or reviewing patches. Some are paid to do it on the clock. A lot of people can't do either. Their hours go to a second job, caring for family, or simply making it through the week.

That doesn't make these people less talented. It means they have less opportunity.

AI changes that math. A contributor might have the skill to fix a bug, but not the time to learn an unfamiliar codebase. AI can explain unfamiliar code and point them to where the fix belongs.

On paper, that should be great news for Open Source. In practice, AI will only help if access and skill become shared, not private advantages.

AI access is not equal. The most capable models and coding agents cost real money, and using them well takes real skill. I pay hundreds of dollars a month for these tools and have spent countless hours learning when to trust them, when to doubt them, and how to turn their output into useful work. Many contributors do not have that money or that time.

We learned once that "anyone can contribute" is not the same as "everyone has the same opportunity to contribute". AI can repeat that mistake in a new form.

Powerful technologies rarely share their benefits evenly at first. Electricity did not create equal opportunity the moment it was invented. It only changed lives broadly when people built the infrastructure to make it widely available.

The internet followed a similar path: it started with privileged access, then became useful to millions more people as infrastructure, tools, and skills spread.

AI is following the same pattern. It is powerful, imperfect, and unevenly distributed. We should not ban AI or pretend it has no flaws. If we want it to become broadly useful, more people need access to it and the knowledge to use it well.

If we want AI to reduce privilege in Open Source instead of reinforcing it, we have to close two gaps.

The first is cost. Contributors should be able to do meaningful work without paying for the most expensive AI tools. As lower-cost models, including open-weight models, improve, Open Source projects should make them practical for contribution work.

The second is skill. Knowing how to use AI well should become shared knowledge within Open Source projects so more people can learn faster and make better contributions.

Contributing with AI should come down to talent, not to who can afford the best tools or who has the time to learn them.

Open Source already moves many things from private advantage to shared infrastructure: code, documentation, test suites, best practices, decision-making processes, and even the financial side of our projects. The ability to use AI well for contribution should move in the same direction.

The opportunity is not just to make today's contributors faster. It is to help many more people become Open Source contributors: people with the talent, but not the free time, the insider knowledge, the employer backing, or the money for the best tools.

But more contribution is not automatically progress. As I wrote in AI creates asymmetric pressure on Open Source, AI can make it cheaper to contribute without making it cheaper to review.

The test is whether it helps more people move from issue to tested patch while making the result easier for maintainers to trust and merge.

If we do this well, AI can reduce the privilege of free time, insider knowledge, and expensive tools. If we do it poorly, it will widen the gap for contributors and increase the burden on maintainers.

In 2019, I argued that Open Source communities should create opportunity by paying contributors. I still believe that. Paying contributors gives people time. But AI gives us another way to reduce the privilege of free time: it helps people do more with the time they have.

I want Drupal to help explore what that looks like in practice: not because we have all the answers, but because this is the kind of problem Open Source should help solve.

Drupal Canvas AI gives content teams prompt-based speed, along with governance and brand control. Here is what it does and how to use it.

More than a dozen Drupal site templates are available. Compare every marketplace option by sector, design system, and content architecture.

Plenty of clients arrive with a system they see as a line item to keep cheap. The real job of an agency is to help them see what that same system could become - and why it is worth investing in.

See how a Drupal development partner relationship grows from minimal support into strategic investment - five readiness signals, quick wins that prove value, the account growth curve, and a ~24% conversion lift on one real account.