Drupal 11.4.0 landed on July 1, 2026 — the fourth feature release in the 11.x cycle and one that deserves more than a changelog glance. After digging into the release notes and the surrounding ecosystem activity this week, here's our honest read on what's useful, what's genuinely new infrastructure, and where agencies should focus their energy before the 11.5 window opens.
What shipped in 11.4
A few threads stand out from the broader release:
Composer-based Rector sets are now stable. The Drupal core team landed a standardized, Composer-installable Rector configuration that makes automated code upgrades dramatically more accessible. Previously, running Rector against a Drupal codebase meant wiring up your own ruleset and hoping the community-maintained sets covered your contrib modules. Now you can pull in official sets via composer require and get predictable, versioned upgrade automation out of the box. This is the most operationally significant change in 11.4 for agencies maintaining multiple client codebases.
The 11.4 delay exposed — and fixed — a dependency patching problem. The release was held back briefly because of how Composer dependencies are resolved when security patches land mid-cycle. The core team changed how selected dependencies are allowed to move during a release window, so future patch-level security updates won't create the same bottleneck. It's an infrastructure fix that most teams will never notice directly, but it matters for the reliability of Drupal's release cadence going forward.
Drupal Site Audit 1.0.11 shipped alongside 11.4 with Drupal 12 readiness checks and broader Drush compatibility. If you're not running site audit tooling on client projects, this is a good moment to add it — especially with Drupal 12 planning conversations starting to appear on the horizon.
PreviousNext's 11.x contributions summary (published alongside the release) details a sustained focus on performance, media handling, and configuration management improvements across the 11.x cycle. The work isn't dramatic headline-by-headline, but the cumulative effect on sites with complex content architectures is real — particularly the configuration management and media improvements that reduce the friction of multi-environment workflows.
The dependency delay also surfaced a broader conversation about how Drupal's release process handles upstream pressure. When a security fix in a third-party library lands between scheduled Drupal releases, the question of whether to hold, ship a patch, or adjust dependency constraints gets complicated fast. The 11.4 fix establishes clearer policy here, which is genuinely good news for agencies who plan client maintenance windows around predictable Drupal release dates.
Our take
The Composer-based Rector sets are the story we've been waiting for. We've written before about using AI-assisted Rector rules for Drupal upgrades, and the manual configuration overhead has always been the honest caveat in that conversation. With official, versioned sets now installable via Composer, that caveat shrinks considerably.
Here's what this looks like in practice on a real project: a mid-size Drupal 10 site with 30–40 contrib modules and a handful of custom modules. Before 11.4's Rector tooling, running automated upgrade analysis meant maintaining your own rector.php config, hand-selecting rules, and reconciling gaps where community sets hadn't caught up with the module in question. That overhead — not the migration work itself — was often the reason agencies quoted more hours than clients expected for Drupal major version upgrades.
With stable, Composer-managed sets, you can now run composer require drupal/rector-config (or whichever the official package lands as), execute a dry run, and get a realistic picture of the manual work remaining in under an hour. That changes how we scope upgrade projects, and it should change how you talk about them with clients. The honest trade-off: Rector handles API-level changes well, but it won't catch logic errors that arise when the behavior of a deprecated function changed subtly between versions. Human review of the output is still essential — Rector is a first pass, not a final answer.
The dependency policy fix is worth flagging to your project management process even if it's invisible to end users. If your team plans Drupal maintenance windows quarterly and relies on release dates being stable, the 11.4 change means fewer surprises when upstream security patches land at inconvenient times. It's not glamorous, but predictability has real dollar value in a managed-services context.
One thing we're watching: the Drupal 12 readiness checks in Site Audit 1.0.11. The advisory-policy caveat the maintainers note is real — don't treat automated audit output as a security baseline without human review. But as a planning tool for conversations with long-term Drupal clients about their 12.x migration timeline, it's useful. Starting that conversation now, while Drupal 11 support is healthy, puts clients in a much better position than scrambling when end-of-life dates become imminent.
What to actually do this week
If you maintain Drupal 11.x client sites:
- Add the new Composer-based Rector sets to your upgrade playbook now — even if you're not planning a major version move soon, familiarizing your team with the tooling before you need it is worth the hour.
- Run Drupal Site Audit 1.0.11 on any sites where Drupal 12 is on the three-year roadmap. Use the output to start the client conversation, not to make upgrade commitments.
If you're still on Drupal 10:
- 11.4 is a stable, well-tested target. The upgrade path is mature. The Rector tooling makes the first assessment cheaper than it's ever been. There's no strong reason to delay the scoping conversation.
If you're planning maintenance windows:
- The dependency resolution changes in 11.4 mean future patch releases should be more predictable. Adjust your maintenance SLA language accordingly if you've been hedging on release timing.
Originally referenced: Drupal 11.4.0 is now available on Drupal.org.
If you're running Drupal in production and want a realistic picture of your upgrade path — including what the new Rector tooling actually finds on your codebase — get in touch. We're happy to run a scoping assessment before you commit to a timeline.
Originally published by Drupal.org. Read the full announcement here.
