Drupal 11.4: The Release That Finally Makes Core Feel Modern Again
I’ve been running Drupal in production for over seven years now, mostly on enterprise CMS builds where every millisecond of TTFB gets scrutinized and every dependency upgrade has to be justified to a client who doesn’t care about your architecture diagrams. So when I say Drupal 11.4 is the most interesting core release I’ve sat down and gone through in a long time, that’s not hype — that’s someone who’s spent the last few years neck-deep in decoupled Drupal and Next.js frontends telling you this one actually matters.
I updated one of my own local dev sites to 11.4 the day after it landed, mostly out of curiosity, partly because I wanted to see if the performance claims held up under a real workload instead of a benchmark chart. They did. And along the way I found a genuinely interesting release — not just a routine point-release with a changelog nobody reads, but a snapshot of where Drupal core is heading architecturally. I want to walk through what stood out to me, what I think matters for teams like mine running decoupled setups, and a couple of things I’m still a little unsure about.
Why This Release Caught My Attention
Drupal 11.3 already set a high bar a few months back — that release delivered the biggest performance jump the platform had seen in a decade, and I remember being genuinely surprised by how much of that translated into real-world gains rather than synthetic benchmark wins. I figured 11.4 would be a breather release. It wasn’t. Core did it again, and this time the improvements are layered across database queries, caching, asset delivery, and the developer experience all at once.
What struck me most is that this isn’t a release built around one flashy feature. It’s a release built around dozens of smaller, deliberate architectural decisions that, added together, make Drupal feel like a platform that’s actively shedding weight instead of accumulating it.
The Performance Numbers Are Real
The headline number is that database queries are cut roughly in half across a wide range of requests, thanks to how entity fields are now loaded. On a cold cache, that translates to nearly two-thirds better performance for database and cache lookups compared to Drupal 11 or 10.6. If you’ve spent any time tuning a high-traffic Drupal site — and I have, more times than I’d like to admit — you know that cold-cache performance is usually the thing nobody wants to talk about because it’s the hardest to fix. Warm caches make everyone look good. Cold caches are where architecture actually gets tested.
On top of that, entity listing queries have been refactored to use fewer table joins, which cuts down on the kind of slow queries that show up in your slow query log at 2am during a traffic spike. For anyone running multi-layer caching setups — Drupal’s internal cache, Redis, a CDN in front of everything — this matters because it reduces the baseline cost of a cache miss. A faster cold path means your caching layers have less to compensate for, which in turn means fewer surprises when cache invalidation happens at scale.
The Resolvable URI Property — A Small Change With Big Implications for Decoupled Drupal
This is the one that actually made me sit up. The link field now has a resolvable URI property and token that returns a ready-to-use front-end link straight from the API, instead of the raw internal URI you’d normally have to resolve yourself.
If you’ve built a headless Drupal setup with a Next.js frontend, you know exactly the pain I’m talking about. You pull a link field from JSON API or GraphQL, and instead of a usable URL, you get something like entity:node/42 or an internal route that means nothing to your frontend until you write a resolver to translate it. Every team I’ve worked with has built some version of that resolver logic — usually more than once, usually slightly differently each time depending on whether it’s dealing with menu links, internal content links, or external URLs.
Having Drupal do that resolution natively and hand back something the frontend can actually consume removes an entire category of glue code. It’s a small line in the changelog, but for anyone doing serious decoupled work, it’s the kind of change that quietly saves hours across every project going forward.
Faster Recipes and Compression Wins
Recipes — Drupal’s newer mechanism for applying pre-configured functionality — now apply roughly twice as fast, and that includes the Drupal CMS installation process itself. For anyone building the kind of fast-deploy solutions I’ve been working on, where the entire pitch is getting a functional site running quickly, this is a meaningful improvement. Recipe application time is one of those invisible bottlenecks that doesn’t show up until you’re doing it repeatedly across client projects.
Core also now supports Brotli compression, which should give roughly 15-25% better compression on CSS and JS assets compared to gzip. That’s a free performance win at the infrastructure level — no code changes required, just better asset delivery once your server stack supports it.
Security: Argon2id and Looser Dependency Locking
Drupal 11.4 introduces Argon2id as a new password hashing algorithm, which will become the default in Drupal 12 later this year. Argon2id is generally considered a stronger, more modern choice than the bcrypt-based hashing Drupal has relied on, so this is a welcome, if unglamorous, improvement.
More practically useful day-to-day: the core recommended package no longer strictly locks minor versions for critical dependencies like Guzzle, Twig, and Symfony polyfills. Anyone who’s had to wait on a Drupal core release to get a security patch for an underlying dependency knows how frustrating that lag can be. Loosening those constraints means security updates for those packages can land faster without waiting on a full core release cycle.
There’s also a smaller but practical fix here — Drupal’s default robots.txt now blocks well-behaved crawlers from indexing search query URLs. If you’ve ever dealt with a site using faceted search getting hammered by crawlers indexing every possible filter combination, you’ll appreciate this. It’s not glamorous, but it’s the kind of thing that prevents a very real, very common source of unnecessary server load.
The Developer Experience Shift: PHP Attributes Everywhere
This is where 11.4 starts to feel like part of a bigger, multi-release story rather than an isolated update. Drupal has been steadily moving toward PHP attributes over the last several releases, and 11.4 pushes that further. You can now define application routes directly within your PHP controller and form classes using the Symfony route attribute, instead of maintaining a separate routing.yml file.
I’ll be honest — the back-and-forth between a controller class and its routing YAML has always felt like unnecessary friction to me. It’s not hard, it’s just an extra hop your brain has to make every time you’re wiring something up. Having the route definition live next to the code it routes to is a small change that removes a surprising amount of mental overhead once you get used to it.
There’s also a new bundle attribute that lets developers define bundle classes directly, which eliminates the need to write hook_entity_type_info or hook_entity_type_info_alter implementations. Anyone who’s worked with entity bundles in Drupal knows those hooks are exactly the kind of procedural glue that feels out of place next to modern object-oriented code. This closes that gap.
Saying Goodbye to .theme and .module Files
Every .theme and settings.php file in core has now been moved entirely to PHP classes, with legacy .theme file support being dropped entirely in Drupal 13. On top of that, dozens of .module files — somewhere around 38 to 40 of them at this point, with six or seven major ones like Locale, User, and Views still in progress — have been fully converted into clean PHP classes as well.
This is the kind of change that doesn’t show up in a demo but fundamentally changes how you write Drupal code. Procedural .module files with global function names and hook implementations scattered across the codebase have always been one of the harder things to explain to developers coming from more modern PHP frameworks. Moving to proper classes means dependency injection becomes natural instead of something you have to work around, and it opens the door to the kind of object-oriented patterns — interfaces, service composition, testability — that make a codebase easier to reason about at scale.
Front controllers now also leverage the Symfony runtime component to isolate bootstrapping logic from request handling. On its own that’s an internal architectural detail, but it’s also groundwork for running Drupal on more advanced environments — which brings me to FrankenPHP.
The New DR Command-Line Tool
Drupal 11.4 introduces a native, extensible command-line tool called DR, built in partnership with the Drush maintainers. This kicks off a transitional period where Drush commands will gradually migrate into this new core-native binary. I’ve relied on Drush for pretty much every Drupal project I’ve touched, so seeing core absorb this functionality natively — rather than depending entirely on a contrib tool — feels like a sensible long-term move, even if the transition itself will take time to play out. 
Editor Experience
On the editorial side, 11.4 ships a new default admin theme based on the popular Gin admin theme, now built into core rather than requiring a contrib install. It’s currently tagged experimental, so you’ll see that warning in the UI, but functionally it’s a solid step forward — I’d already switched to Gin as a contrib theme on my own projects before this, so getting there natively is a welcome consolidation. 
The navigation module is now enabled by default, replacing the legacy toolbar entirely. And CKEditor gets a full-screen button back without needing a contrib add-on, which is a small thing but genuinely useful for editors working on long-form content who want to get the surrounding admin chrome out of their way.
One open question I still have: navigation’s relationship with Layout Builder. As far as I can tell, navigation still has some dependency there, and with Drupal’s newer Canvas functionality becoming more tied into core, I’d expect that dependency to eventually get removed in a future major version. It’s not clear yet whether that’s already been resolved or is still on the roadmap, so it’s worth keeping an eye on if your project relies heavily on navigation.
What’s Being Deprecated
Every release with this many announced deprecations tends to make people nervous, so let me walk through what’s actually happening. The initial 11.4.0 release removed a handful of core recipes outright — those were restored in 11.4.1, but they’re still deprecated and slated for removal in Drupal 12.
On the module side, Ban, Contact, Field Layout, History, Migrate Drupal (and its UI), Search, Settings Tray, Shortcut, Telephone, Toolbar, and the Layout Builder “expose all field blocks” flag module are all being moved out of core. On the theme side, Claro, Stable 9, and Olivero are being deprecated and will eventually move to contrib.
Having gone through this list carefully, none of it strikes me as surprising or poorly justified. Migrate Drupal moving out makes sense — the population of people still migrating off Drupal 6 or 7 shrinks every year, and having it live in contrib means it can be maintained by the people who actually still need it, at whatever pace makes sense for them, without core carrying that weight indefinitely. I’ve actually used exactly this kind of core roadmap signal with a client of mine who’d been sitting on Drupal 7 far longer than they should have — seeing migration tooling formally head toward deprecation was one of the factors that finally pushed them to commit to the upgrade.
The one deprecation I’ll admit some reluctance about is Settings Tray. It’s a genuinely useful feature when it fits a project, and I’ve used it myself in the right contexts. But from what I understand, part of the reasoning behind moving it to contrib is that it currently doesn’t work properly with any of the core themes — which is a legitimate technical reason, not just a “let’s trim core” decision. Moving it to contrib means it can evolve and get fixed at its own pace instead of being stuck waiting on core release cycles. If anything, it should make Settings Tray easier to maintain properly going forward, even if it adds a small extra step of pulling in a contrib module for projects that want it.
Moving Olivero out also makes sense to me. Bundling a specific front-end theme with core has always felt like a slightly awkward fit, especially now that recipes make it easy to enable exactly the theme setup a project needs without core needing to ship a default front-end theme at all.
My Take: Should You Upgrade Now?
If you’re running anything customer-facing, the database and cache lookup improvements alone are worth the upgrade — that’s not a marginal gain, that’s the kind of change that shows up directly in your response time metrics. For teams doing decoupled Drupal work, the resolvable URI property alone is worth prioritizing this upgrade for, since it removes real, recurring engineering work.
The parts I’d stay cautious about are the experimental admin theme and anything touching Layout Builder’s relationship with navigation, until that’s clarified further. And if your project depends on any of the modules or themes now marked for deprecation, it’s worth tracking their move to contrib early rather than waiting until Drupal 12 forces the issue.
Overall, this is one of those releases that reinforces something I’ve believed for a while — Drupal’s core team isn’t just adding features anymore, they’re deliberately trimming the platform down to what belongs in core versus what belongs in contrib, while simultaneously modernizing the underlying architecture toward object-oriented patterns and better performance characteristics. That’s a hard balance to strike in a project with Drupal’s history and install base, and 11.4 strikes it about as well as I’ve seen in a while.