Drupal 11 Explained: What’s New and Why It Matters

Drupal 11 has been generally available since August 1, 2024 (release schedule on drupal.org). For most Drupal site owners, the practical question is not "what is Drupal 11?" but "do I need to act, and when?" The short answer: yes, and the deadline is December 9, 2026, when Drupal 10 reaches end of life and stops receiving security updates (drupal.org release schedule).

This guide walks through what Drupal 11 actually changed, what it requires from your hosting environment, and how to think about whether to upgrade now or wait for Drupal 12 (currently planned for 2026 release as well).

System requirements: PHP 8.3 and Symfony 7

Drupal 11 raises the floor under the platform. The two most consequential bumps:

• PHP 8.3.0 or later: Drupal 10 supported PHP 8.1 minimum. Drupal 11 requires PHP 8.3, dropping support for 8.1 and 8.2.
• Symfony 7: Drupal 11 ships with the Symfony 7 framework as its underlying foundation. Drupal 10 used Symfony 6.
• Drush 13: the command-line tool needs to be updated; older Drush versions are not compatible with Drupal 11.

If your hosting environment still runs PHP 8.2, that’s the first blocker to address. Most managed Drupal hosts (Pantheon, Acquia, Platform.sh) added PHP 8.3 support well in advance of Drupal 11’s release, but self-hosted environments may need an OS-level upgrade.

The Symfony 7 dependency is more than a version bump under the hood. Symfony 7 introduces incremental API changes that ripple through Drupal’s internals: services, event subscribers, route handlers, and form classes that custom modules expose all see subtle shifts. For most sites running purely contributed modules, this is invisible. For sites with substantial custom code, the upgrade requires running the Upgrade Status module and Drupal Rector to identify and fix anything that uses deprecated APIs.

We cover the full upgrade workflow in our companion guide: Migrating from Drupal 10 to Drupal 11.

Recipes: the biggest user-facing change

Of all the new features in Drupal 11, the Recipes system is the one most worth understanding because it changes how site builders compose Drupal sites.

A Recipe is a bundled set of configuration: modules to install, settings to apply, content types to create, blocks and menus to set up, all expressed as a YAML-driven package that can be applied to a site idempotently. Where Drupal Distributions historically tried to be "complete site templates" and tended to lock site builders into a specific opinionated structure, Recipes are smaller, composable, and additive.

Practical examples of where Recipes show their value:

• Spinning up a new section of a site: apply an “events” recipe that creates the Event content type, the relevant taxonomy, a calendar view, and the front-page block, all in one step.
• Standardizing setup across multiple sites: agencies maintaining many client sites can codify their baseline (security defaults, default content types, common modules) as a recipe and apply it to every new project.
• Refactoring existing sites: reorganizing a section of a site that grew organically becomes more like a code-driven migration and less like clicking through admin screens.

The Recipes API arrived experimental in Drupal 11.0, became stable in Drupal 11.1, and got default-unpacking plus 3–4× faster installation in Drupal 11.2 (released June 19, 2025). If you’re on 11.1 or later, Recipes are a first-class, production-ready part of the platform.

Single Directory Components for theme development

The other significant developer-facing addition is Single Directory Components (SDC): a way to define a self-contained UI component in a single folder with its template, JavaScript, CSS, and metadata all colocated.

Before SDC, the convention for organizing front-end code in a Drupal theme was scattered: templates in one directory, library JavaScript in another, CSS in a third, with .libraries.yml declarations gluing them together. SDC compresses this so a component like a "Card" or "Hero Banner" lives in one place:

• card.component.yml: metadata, props (typed inputs), slots (named content regions)
• card.twig: the template
• card.css: the styles
• card.js: behavior (if any)

The .component.yml file is where SDC earns its keep. It declares the component’s props with JSON Schema types, so a card component might declare title: string, image_url: string, is_featured: boolean. Twig then references those props with confidence that the data shape is enforced. Slots let parent components inject named content into a child, mirroring the named-slot pattern from Vue and web components.

The reason this matters in practice: front-end developers from a React, Vue, or Svelte background expect colocated components with typed props. SDC brings that ergonomic to Drupal theming, lowering the barrier for developers coming from modern JavaScript frameworks. Atomic design systems become easier to express, pattern libraries like Storybook can be wired up against an SDC catalog with less ceremony, and components become more portable across themes. A card defined as a single directory can be copied between projects without untangling references across the theme’s directory tree.

SDC also pairs cleanly with Recipes. A recipe can install a contributed module that ships a library of SDC components, giving you a tested baseline of UI elements without writing them from scratch. Several contributed component libraries have emerged on drupal.org since SDC stabilized; expect this ecosystem to keep growing as agencies codify their internal pattern libraries as installable packages.

A new admin navigation

Drupal 11 also ships a new vertical admin navigation, replacing the long-standing horizontal Toolbar. The admin menu now lives in a left sidebar, with sections collapsible and a layout closer to what users expect from modern SaaS administration interfaces: think Linear, Notion, or modern dashboards rather than the cramped horizontal strip of older Drupal.

The change went stable in Drupal 11.3 (December 2025). For content editors using Drupal day to day, it’s a meaningful usability improvement: the navigation occupies dedicated horizontal real estate rather than fighting the page content for vertical attention, and the collapsible sections let editors pin the parts of the admin they actually use. On large screens where the horizontal toolbar had become genuinely cramped (picture an editor working in the Block Layout interface with the old top toolbar consuming 60+ pixels of fixed height), the difference is immediate.

The new navigation also paves the way for module developers to register admin pages and sections in a more structured way. Plugin definitions can now declare a navigation slot and an icon; the navigation system handles layout and grouping. Expect contributed modules to start surfacing themselves in the new pattern through 2026; early adopters include Webform, Paragraphs, and most of the major Drupal commerce modules.

Mobile considerations: the vertical nav collapses to an icon rail on smaller viewports, with section names appearing on hover or expansion. Not as deeply polished as some SaaS admins (yet), but a clear step forward from the prior mobile experience, which was effectively "use a tablet or larger."

Performance: the 11.3 step-change

The performance story for Drupal 11 isn’t the initial 11.0 release. It’s 11.3, released December 17, 2025, which delivered what drupal.org described as the biggest performance boost in a decade:

• 26–33% more requests served with the same database load on benchmark workloads (source: drupal.org 11.3 announcement)
• ~50% reduction in database queries on partially-warmed caches
• Native HTMX integration, replacing portions of Drupal’s JavaScript with server-driven interactions, up to 71% less JavaScript on equivalent pages (source: drupal.org HTMX in 11.3.0)
• Use of PHP 8.1+ Fibers in Drupal’s render pipeline, allowing parts of the page to compute in parallel

These aren’t incremental tweaks. They’re the result of a sustained performance-engineering effort across 11.2 and 11.3. For high-traffic sites, the cumulative effect is a meaningfully larger budget for the same hosting cost.

BigPipe, Drupal’s progressive-rendering technology that’s been in core since Drupal 8.1, remains available and continues to be useful for sites with expensive dynamic blocks. In 11.3 it interoperates with the new placeholder-warming logic so that when caches are warm enough to skip BigPipe entirely, the BigPipe JavaScript doesn’t load at all.

The current stable minor as of mid-2026 is Drupal 11.3.x (with security support through December 2026).

What about the rest of the Drupal landscape?

Drupal 11 doesn’t exist in isolation. The current Drupal version landscape:

• Drupal 7: end of life since January 5, 2025. No further security releases from the Drupal Security Team. Commercial support is available from Certified D7 EOL Support Partners (Pantheon, Acquia, others), but sites still on D7 should be planning their migration urgently.
• Drupal 8 and 9: both reached end of life prior to 2024. No security support.
• Drupal 10: currently supported, but EOL on December 9, 2026. Sites on D10 need to upgrade to D11 (or wait briefly for D12; see next bullet).
• Drupal 12: planned for release in 2026. The exact date depends on when beta requirements are met, with release windows in August 2026 or December 2026 (drupal.org schedule).

For a deeper look at the Drupal 10 EOL implications specifically, see our companion piece: Drupal 10 End of Life: What December 9, 2026 Means for Your Site.

Should you upgrade now?

The honest answer is: it depends on three things: your hosting environment, your custom code, and your appetite for being on the latest version.

Upgrade now if:

• You’re running Drupal 10.3 or later and your hosting supports PHP 8.3. The upgrade is straightforward in this case, mostly Composer commands.
• Your site relies primarily on well-maintained contributed modules. Most major contrib modules had Drupal 11 compatibility releases within weeks of D11’s launch.
• You want to start using Recipes or SDC in production rather than waiting.

Wait a bit if:

• You’re still on Drupal 10.0–10.2. Upgrade to Drupal 10.3+ first (which is itself low-risk), then upgrade to Drupal 11. The migration documentation requires the 10.3 floor.
• You have substantial custom code that hasn’t been audited with Upgrade Status yet. Run that audit before scheduling the upgrade window.
• You depend on a contributed module that hasn’t released a Drupal 11–compatible version. Check the module’s release history on drupal.org and decide whether to wait, swap, or fork.

Don’t wait too long, though. December 9, 2026 is the hard deadline. Working back from that, the practical recommendation: audit your site by mid-2026, schedule the upgrade for late summer or early fall, leaving buffer for any contributed-module gaps to be resolved.

The Symfony connection matters here

One under-discussed aspect of Drupal 11 is how tightly it’s now coupled to Symfony’s release cadence. Drupal 11’s Symfony 7 dependency isn’t just a version bump. It’s an architectural commitment. Drupal sits on top of Symfony’s HttpKernel, EventDispatcher, DependencyInjection, Routing, and a half-dozen other Symfony components. When Symfony deprecates an API, Drupal’s deprecation timeline follows. When Symfony’s LTS rolls over, Drupal’s major-version cadence rolls with it.

For developers, this is a feature: Drupal benefits from improvements in the broader Symfony ecosystem (where investment is sustained and the contributor base is much larger than Drupal’s), and Symfony’s release cadence is predictable enough to plan around. For site owners, it means Drupal version timelines are now meaningfully influenced by an upstream project’s roadmap. A Symfony 7 → 8 transition will, in some sense, set the clock for Drupal 12 → 13.

The deeper architecture story (which Symfony components Drupal uses, how HttpKernel wraps Drupal’s request lifecycle, why the legacy hook system is being gradually replaced by EventDispatcher subscribers) lives in our companion piece How Drupal Is Built on Symfony.

Frequently Asked Questions