fidzu : php

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.

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.