Drupal 11.4 : nouveautés par rapport à 11.3 | Droptica

Was ist neu in Drupal 11.4: Überblick über die Änderungen gegenüber 11.3

Drupal
Droptica Team
Droptica Team
05.06.2026

Drupal 11.4 ist das nächste Minor-Release in der 11.x-Linie, mit einem stabilen Release für die Woche ab dem 22. Juni 2026. Es bricht die Abwärtskompatibilität öffentlicher APIs nicht, bringt aber konkrete Verbesserungen: PHP-Attribut-Routing, ein neuer Bootstrap auf Basis von Symfony Runtime, Brotli-Kompression für Assets, SEO-Anpassungen in robots.txt und eine Reihe von Deprecations, die Custom-Module betreffen.

Die Version 11.4.0-beta1 ist bereits verfügbar (seit 3. Juni 2026), Sie können also alle unten beschriebenen Änderungen testen — Beta ist jedoch nicht für Produktion empfohlen. Im Folgenden gehe ich durch die Unterschiede zu Drupal 11.3.

In diesem Artikel:

Wann Drupal 11.4 erscheint und wie lange es unterstützt wird

Drupal 11.4.0-beta1 wurde am 3. Juni 2026 veröffentlicht, das stabile 11.4.0 ist für die Woche ab dem 22. Juni 2026 geplant (laut offiziellem Zeitplan, aktualisiert am 4. Juni 2026; die Verschiebung von beta1 hat den gesamten Zyklus nach hinten verschoben). Als Minor-Release fügt 11.4 Funktionen hinzu, ohne öffentliche APIs zu brechen. Interne APIs und experimentelle Module können sich ändern — Contrib- und Custom-Module müssen ggf. angepasst werden.

Die Support-Daten sind wichtig. Die Branch 11.4.x erhält Security-Support bis Juni 2027, die Branch 11.3.x bis Dezember 2026. Mit 11.4 endet Security-Support für 11.2.x und 10.5.x. Die gesamte Drupal-11-Linie wird bis zur Veröffentlichung von Drupal 13 unterstützt.

In der Praxis: Auf 11.3 haben Sie Zeit bis Dezember 2026; ein Wechsel auf 11.4 verlängert das Security-Fenster um sechs Monate und ist relativ günstig — Minor ohne BC-Breaks. Wenn Sie die Linie neu entdecken, haben wir Ziele und Funktionen von Drupal 11 in einem separaten Artikel beschrieben.

PHP-Attribut-Routing — die wichtigste Neuerung für Entwickler

Die interessanteste Entwickler-Änderung in 11.4: Routen können direkt im Code per PHP-Attribute definiert werden, nicht nur in *.routing.yml-Dateien. Jede Klasse im Controller-Namespace eines Moduls (z. B. Drupal\example\Controller) mit dem Attribut Symfony\Component\Routing\Attribute\Route wird als Routendefinition erkannt.

Das Attribut #[Route] funktioniert auf Methoden- und Klassenebene, wobei die Klassenebene gemeinsame Standardwerte setzt. Die Schlüssel defaults, requirements und options werden zusammengeführt (Methodenebene hat Vorrang), während name und path konkateniert werden — Sie können also ein Präfix auf Klassenebene und Suffixe auf Methodenebene definieren. Routen über __invoke werden unterstützt.

Der Mechanismus gilt auch für Formulare. Klassen mit Drupal\Core\Form\FormInterface im Form-Namespace eines Moduls und Route auf Klassenebene werden als Routen erkannt. Das Attribut muss auf der Klasse stehen; Attribute auf Formularmethoden werden ignoriert. Entity-Form-Routen bleiben beim Route Provider in der Entity-Definition.

Das ergänzt *.routing.yml, ersetzt es aber nicht. Für Teams mit viel Custom-Code bedeutet das weniger Wechsel zwischen YAML und PHP und Routendefinitionen näher an der Controller-Logik.

Symfony Runtime und der neue Bootstrap

Drupal 11.4 nutzt symfony/runtime für einen vereinfachten und getrennten Bootstrap. Für die meisten Sites unsichtbar; bei Custom-Front-Controllern (index.php oder anderer Einstiegspunkt) lohnt sich das Change Record, denn die Initialisierung der Anwendung ändert sich.

Gute Nachricht: Bestehende Front-Controller funktionieren mindestens bis Drupal 12 — kein Druck, alles sofort umzuschreiben. Es signalisiert vor allem die Richtung der Bootstrap-Architektur.

Zusätzlich macht symfony/polyfill-php86 ausgewählte PHP-8.6-Funktionen in Drupal 11.4 verfügbar, unabhängig von der PHP-Version auf dem Server.

Performance: Brotli, schnellere Recipes und neuer Cache

Performance ist einer der Schwerpunkte dieser Version.

  • Brotli für CSS und JS. Drupal erzeugt nun .br-Versionen (Brotli) aggregierter CSS- und JS-Dateien, wenn der Server die PHP-Erweiterung ext-brotli hat. Das läuft parallel zu gzip; Brotli liefert typisch 15–25 % bessere Kompression, also kleinere Dateien und schnelleres Laden. Die Konfiguration wurde vereinheitlicht: system.performance.css.gzip und js.gzip werden durch css.compress und js.compress ersetzt; ein Post-Update-Hook (system_post_update_migrate_compress_setting()) migriert alte Einstellungen automatisch. Auf Apache funktioniert das out of the box (aktualisiertes .htaccess liefert .br mit gzip-Fallback); auf Nginx brotli_static konfigurieren (Modul ngx_brotli erforderlich).
  • Schnelleres Recipe-System. Die Recipe-Performance wurde durch Batch-Installation von Extensions verbessert. Entwickler sollten RecipeRunner::installModules() nutzen, das mehrere Module in einem Durchlauf verarbeitet.
  • Neuer Cache-Bin cache.file_parsing. Ein dedizierter Bin für persistentes Caching von Datei-Parsing-Ergebnissen (FileParsingCacheCollectorBase, YamlCacheCollector, u. a. für libraries.yml und routing.yaml). Im Gegensatz zu APCu-basiertem FileCache überlebt dieser Cache Cache-Clears und bleibt zwischen CLI und mehreren Webservern konsistent — bessere Antwortzeiten lokal (häufige Clears per CLI) und in Produktion direkt nach Deployments.
  • Font-Preloading. Library-Definitionen (und Overrides in SDC-Komponenten) unterstützen einen fonts-Key zum Vorladen von Schriftarten. Zuvor gab es keine offizielle API dafür; Links mussten manuell im HTML-Header gesetzt werden.

Diese Änderungen greifen nach dem Upgrade weitgehend automatisch. Typisches Beispiel dafür, wie aktuelles Drupal konkret in Performance übersetzt wird — mehr dazu in unserem Artikel zu häufigen Drupal-Wartungsproblemen.

Änderungen für Site Builder und Redakteure

Nicht alles passiert im Code. Einige Änderungen betreffen auch die Menschen, die Seiten bauen und Inhalte pflegen.

  • Neue „Manage display“-Übersicht. Unter /admin/structure/types/manage/{bundle}/display ist eine neue Seite die Standardzielseite des Tabs „Manage display“. Statt direkt das Formular des Standard-Anzeigemodus zu öfnen, listet sie alle Modi mit Label, Beschreibung und Aktiv-Status, editierbar aus dieser Ansicht. Die Seite ist unabhängig von einem bestimmten Builder — einfachere Integration von Layout Builder, Drupal Canvas und anderen Tools. Module mit funktionalen Tests, die das alte Routing-Verhalten voraussetzen, sollten aktualisiert werden.
  • Neues Recht für unveröffentlichte Blöcke. Die Berechtigung „view unpublished block content“ erlaubt Nutzern, unveröffentlichte Block-Content-Entitäten zu sehen.

  • Node-Suche als separates Sub-Modul. Das Plugin node_search wurde in das Sub-Modul search_node des Search-Moduls verschoben. Custom-Plugins, die \Drupal\node\Plugin\Search\NodeSearch erweitern, sollten auf \Drupal\search_node\Plugin\Search\SearchNode umstellen.

    Weiterlesen: Wenn Sie planen, wie KI Redakteure nach dem Upgrade unterstützen soll, finden Sie in unserem Leitfaden, wie Sie Website-Inhalte mit Drupal-AI-Modulen erstellen.

SEO und Sicherheit

Drupal 11.4 verbessert mehrere Standardeinstellungen, die Sichtbarkeit in Suchmaschinen und Robustheit bei ungültigen Daten betreffen.

  • robots.txt blockiert Suchergebnisseiten. Die Standard-robots.txt blockiert nun die Indexierung von Ergebnisseiten mit Query-Parametern. Die Regeln Disallow: /search? und Disallow: /index.php/search? wurden ergänzt. Suchmaschinen indexierten dynamische Ergebnisse und crawllten quasi unendliche facettierte Kombinationen — Serverlast und schlechtere SEO-Qualität. Bei custom robots.txt diese Regeln manuell ergänzen. Mehr zu SEO in Drupal: 10 SEO-Funktionen, die ein modernes CMS haben sollte.
  • UUID-Validierung. Der Feldtyp uuid, der automatisch UUIDs von Content-Entitäten speichert, prüft nun, ob der Wert eine gültige UUID ist.
  • Cacheable 404. Router::matchRequest() wirft nun CacheableResourceNotFoundException statt ResourceNotFoundException; ein neuer Cache-Context für Exception-Status wurde ergänzt. In der Praxis verbessert das das Caching von 404- und 403-Antworten.

Front-end, Twig und CKEditor

Die Präsentationsschicht und decoupled Projekte profitieren ebenfalls.

  • Funktionen aus twig/html-extra. Das Paket twig/html-extra stellt html_cva, html_attr und html_classes bereit — nun in Twig-Templates verfügbar, um Attribute und CSS-Klassen einfacher zu bauen.
  • CKEditor 5 auf 47.6.2 aktualisiert. Der Editor erhielt ein Versions-Update sowie zahlreiche Front-end-Dependency-Updates.
  • #url in responsive image wird Url-Objekt. Im Theme-Element responsive_image_formatter ist #url nun ein Drupal\Core\Url-Objekt statt String — URL-Optionen lassen sich damit manipulieren.
  • Neue Eigenschaft resolvable_uri am Link-Feld. Das Link-Feld liefert resolvable_uri, einen fertigen href-Wert. Wichtig für decoupled und JSON:API: statt rohem internal:/ mit separatem Fragment liefert die API direkt nutzbares /#main-content. Ein Token [entity:field_link:resolvable_uri] wurde ergänzt; das Setzen von resolvable_uri initialisiert die anderen Link-Eigenschaften (uri, query, fragment).

Was vor dem Upgrade zu prüfen ist

Einige Punkte vor dem Produktions-Upgrade.

Weiterlesen: Drupal-Upgrade Schritt für Schritt — Vorbereitung und häufige Herausforderungen.

  • Template drupal/legacy-project ist abandoned. Projekte auf drupal/legacy-project sollten auf drupal/recommended-project wechseln.
  • Pfad zu Drupal 12. Sites müssen mindestens 11.3.0 haben, bevor ein Upgrade auf 12.x möglich ist — Drupal 12 hat Update-Hooks vor 11.3 entfernt. 11.4 positioniert Sie gut für diese Migration.
  • HTML5-Validierung. In settings.php wurde enable_html5_validation ergänzt. In Drupal 12 ist HTML5-Validierung standardmäßig deaktiviert; setzen Sie den Wert bewusst für Ihre Formulare.
  • Nginx und Brotli. Auf Nginx mit Brotli-Vorkompression Server-Konfiguration mit brotli_static ergänzen (Apache braucht keine Änderung). Code, der css.gzip/js.gzip setzt, auf css.compress/js.compress umstellen. Hosting-Hinweise: Drupal-Hosting richtig wählen.
  • Custom-Search-Plugins. Plugins auf Basis von NodeSearch für das Sub-Modul search_node aktualisieren.

Die wichtigsten Deprecations in 11.4

In dieser Version wurden viele API-Elemente als deprecated markiert. Eigene Module sollten Sie planmäßig prüfen. Die wichtigsten:

  • check_markup() ist deprecated, ohne direkten Ersatz. Empfehlung: Render-Array statt flachem Markup zurückgeben, um Cacheability-Metadaten zu erhalten.
  • Render-Funktionen hide() und show() sind deprecated. Nutzen Sie das Flag #printed im Render-Array.
  • file_get_file_references() wird durch den Service FileReferenceResolver ersetzt.
  • node_access_rebuild() und node_access_grants werden durch Services ersetzt (u. a. NodeGrantsHelper).
  • \Drupal\node\Controller\NodeViewController wird durch EntityViewController ersetzt.
  • Die Routen user.pass.http, user.login.http, user.login_status.http und user.logout.http wurden ins Modul rest verschoben.
  • Zugriff auf die globale Variable autoload ist deprecated; stattdessen vendor/autoload.php einbinden.
  • Mehrere Locale-Funktionen (locale.batch.inc, locale.bulk.inc, locale.compare.inc) werden durch neue Services ersetzt, u. a. LocaleSource, LocaleFileManager und LocaleFetch.

Alle Deprecations haben Ersatz in den Change Records auf drupal.org; der Code funktioniert in 11.4 weiter. Entfernung erfolgt erst im nächsten Major.

Lohnt sich ein Upgrade auf 11.4?

Auf 11.3 ist 11.4 ein Low-Risk-Move: Minor ohne BC-Breaks auf öffentlichen APIs, dafür längerer Security-Support (bis Juni 2027), echte Performance-Gewinne (Brotli, schnellere Recipes, neuer Cache), besseres Standard-SEO und komfortableres Routing für Entwickler.

Die größte Aufmerksamkeit braucht Custom-Code: Deprecations prüfen, ggf. Custom-Front-Controller gegen Symfony Runtime testen, Regeln in custom robots.txt ergänzen. Für typische Sites mit Standardmodulen sollte das Upgrade schnell gehen und die Vorteile direkt nach dem Deployment sichtbar sein. Unseren Schritt-für-Schritt-Upgrade-Guide finden Sie in einem separaten Artikel.

Upgrade oder Wartung — brauchen Sie Unterstützung?

Bei Droptica arbeiten wir seit über einem Jahrzehnt mit Drupal: Upgrades, Wartung und Enterprise-Plattformen, Intranets und komplexe Webanwendungen. Wir führen Minor-Upgrades ohne Unterbrechung durch und klären Deprecations im Custom-Code, damit Ihr Projekt auch für Drupal 12 bereit ist.

Planen Sie ein Upgrade auf Drupal 11.4 oder möchten Sie sicherstellen, dass Ihr Projekt sicher und performant bleibt? Unsere Drupal-Entwicklung oder direkter Kontakt — wir besprechen gerne Ihre Situation.

Check related blog posts