Co nowego w Drupalu 11.4: przegląd zmian względem 11.3

Drupal 11.4 to kolejne wydanie minor w linii 11.x, którego stabilna premiera planowana jest na tydzień rozpoczynający się 22 czerwca 2026 roku. Jak przystało na wydanie minor, zachowuje kompatybilność publicznych API, jednocześnie wprowadzając szereg istotnych usprawnień technicznych. 

Wśród najważniejszych zmian znalazły się routing oparty na atrybutach PHP, nowy bootstrap wykorzystujący Symfony Runtime, obsługa kompresji Brotli dla assetów, aktualizacje związane z SEO oraz kolejne deprecacje, które warto uwzględnić podczas utrzymania modułów custom. Wersja 11.4.0-beta1 jest dostępna od 3 czerwca 2026 roku, dzięki czemu wszystkie opisane funkcje można już testować w środowiskach deweloperskich. W dalszej części artykułu przyglądamy się najważniejszym zmianom względem Drupal 11.3.

W tym artykule:

• Kiedy wychodzi Drupal 11.4 i jak długo będzie wspierany
• Routing przez atrybuty PHP, największa nowość dla deweloperów
• Symfony Runtime i nowy bootstrap
• Wydajność: Brotli, szybsze recipe i nowy cache
• Zmiany dla site builderów i edytorów
• SEO i bezpieczeństwo
• Front-end, Twig i CKEditor
• Co musisz wiedzieć przed aktualizacją
• Najważniejsze deprecje w 11.4
• Czy warto aktualizować do 11.4?

Kiedy wychodzi Drupal 11.4 i jak długo będzie wspierany

Drupal 11.4.0-beta1 został opublikowany 3 czerwca 2026 roku, natomiast wydanie stabilne zaplanowano na tydzień rozpoczynający się 22 czerwca 2026 roku. Zgodnie z polityką wydawniczą Drupala jest to wersja minor, która wprowadza nowe funkcje i usprawnienia bez naruszania kompatybilności publicznych API. Warto jednak pamiętać, że zmiany w wewnętrznych API oraz modułach eksperymentalnych mogą wymagać dostosowania niektórych modułów contrib i rozwiązań custom.

Ważne są daty wsparcia. Gałąź 11.4.x dostanie wsparcie bezpieczeństwa do czerwca 2027, a 11.3.x do grudnia 2026. Premiera 11.4 oznacza też koniec wsparcia bezpieczeństwa dla 11.2.x oraz 10.5.x. Cała linia Drupala 11 będzie wspierana aż do wydania Drupala 13.

W praktyce: jeśli jesteś na 11.3, masz czas do grudnia 2026, ale przejście na 11.4 wydłuża okno bezpieczeństwa o pół roku i jest stosunkowo tanie, bo to wydanie minor bez łamania BC. Jeśli dopiero poznajesz tę linię, opisaliśmy szerzej funkcje i założenia Drupala 11 w osobnym artykule.

Routing przez atrybuty PHP, największa nowość dla deweloperów

Jedną z najważniejszych zmian dla developerów jest możliwość definiowania tras bezpośrednio w kodzie PHP za pomocą atrybutów, bez konieczności korzystania wyłącznie z plików *.routing.yml. Pozwala to pr*echowywać definicję trasy bliżej l*giki aplikacji i ogranicza liczbę *lików konfiguracyjnych wymaganych *o utrzymania modułu.

Atrybut #[Route] można stosować na poziomie metody oraz na poziomie klasy, gdzie ustawia wspólne wartości domyślne. Klucze defaults, requirements i options są scalane (pierwszeństwo ma poziom metody), a name i path są konkatenowane, więc da się ustawić prefiks na poziomie klasy i sufiksy na metodach. Obsługiwane są też trasy oparte o metodę __invoke.

Co istotne, mechanizm rozszerzono również na formularze. Klasy implementujące Drupal\Core\Form\FormInterface w przestrzeni nazw Form modułu, oznaczone atrybutem Route na poziomie klasy, też zostaną wykryte jako definicje tras. Atrybut musi być na klasie, atrybuty na metodach formularza są ignorowane. Trasy formularzy encji nadal powinny być definiowane przez route provider w definicji typu encji.

To rozwiązanie uzupełnia, a nie zastępuje deklaracje w *.routing.yml. Dla zespołów piszących dużo customu oznacza to mniej skakania między plikami YAML a klasami PHP i trzymanie definicji trasy bliżej logiki kontrolera.

Symfony Runtime i nowy bootstrap

Drupal 11.4 wprowadza komponent symfony/runtime, który porządkuje i upraszcza proces bootstrapowania aplikacji. Dla większości projektów zmiana pozostanie niezauważalna, jednak zespoły korzystające z własnych front controllerów powinny przeanalizować jej wpływ na sposób uruchamiania aplikacji.

Dobra wiadomość: istniejące front controllery będą działać co najmniej do Drupala 12, więc nie ma presji na natychmiastowe przepisywanie. To raczej sygnał, w którą stronę idzie architektura bootstrapu.

Dodatkowo doszedł symfony/polyfill-php86, dzięki czemu część funkcji wprowadzonych w PHP 8.6 jest dostępna już w Drupalu 11.4, niezależnie od wersji PHP na serwerze.

Wydajność: Brotli, szybsze recipe i nowy cache

Obszar wydajności należy do najmocniejszych elementów wydania 11.4. Kilka zmian może przełożyć się na szybsze ładowanie stron, sprawniejsze wdrożenia oraz bardziej efektywne wykorzystanie cache bez konieczności przebudowy istniejących projektów.

• Kompresja Brotli dla CSS i JS. Drupal generuje teraz wersje .br (Brotli) zagregowanych plików CSS i JS, jeśli serwer ma rozszerzenie PHP ext-brotli. Działa to obok dotychczasowego gzip, a Brotli daje zwykle o 15-25% lepszą kompresję, czyli mniejsze pliki i szybsze ładowanie. Przy okazji ujednolicono konfigurację: ustawienia system.performance.css.gzip i js.gzip zastąpiono przez css.compress i js.compress, a post-update hook (system_post_update_migrate_compress_setting()) migruje stare ustawienia automatycznie. Sajty na Apache działają od razu (zaktualizowany .htaccess serwuje .br z fallbackiem do gzip); na Nginx trzeba ręcznie dodać konfigurację z dyrektywą brotli_static (wymaga modułu ngx_brotli).
• Szybszy system recipe. Wydajność systemu receptur poprawiono dzięki instalowaniu rozszerzeń w paczkach (batchach). Deweloperzy powinni używać RecipeRunner::installModules(), które wykorzystuje przetwarzanie wielu modułów naraz.
• Nowy bin cache cache.file_parsing. Dodano dedykowany bin do trwałego cache’owania wyników parsowania plików (wraz z FileParsingCacheCollectorBase i YamlCacheCollector używanym m.in. do libraries.yml i routing.yaml). W odróżnieniu od dotychczasowego FileCache opartego o APCu ten cache przeżywa czyszczenie cache i jest spójny między CLI a wieloma serwerami WWW, co poprawia czasy odpowiedzi lokalnie (częste cache clear z CLI) oraz na produkcji zaraz po deployu.
• Preloading fontów. Definicje bibliotek (oraz overrides w komponentach SDC) obsługują teraz klucz fonts do preloadowania fontów. Wcześniej nie było na to oficjalnego API i trzeba było ręcznie dodawać linki w nagłówku HTML.

Te zmiany są o tyle przyjemne, że w dużej mierze działają z automatu po aktualizacji. To typowy przykład tego, że utrzymywanie Drupala w aktualnej wersji po prostu zwraca się wydajnością.

Zmiany dla site builderów i edytorów

Nie wszystko w 11.4 dzieje się w kodzie. Kilka zmian odczują też osoby budujące i redagujące strony.

• Nowa strona przeglądowa „Manage display”. Pod /admin/structure/types/manage/{bundle}/display pojawiła się nowa strona, na którą domyślnie kieruje teraz zakładka „Manage display”. Zamiast od razu otwierać formularz edycji domyślnego trybu wyświetlania, pokazuje listę wszystkich trybów z labelką, opisem i statusem włączony/wyłączony, który można przełączać bezpośrednio z tego widoku. Strona jest niezależna od konkretnego buildera, co ułatwia integrację Layout Buildera, Drupal Canvas i innych narzędzi. Jeśli twój moduł ma testy funkcjonalne zakładające stare zachowanie routingu, trzeba je zaktualizować.
• Nowe uprawnienie do podglądu nieopublikowanych bloków. Doszło uprawnienie „view unpublished block content”, które pozwala nadać użytkownikom prawo oglądania nieopublikowanych encji typu block content.
• Wyszukiwarka node’ów jako osobny sub-moduł. Plugin node_search został przeniesiony do nowego sub-modułu search_node w module Search. Jeśli masz custom plugin rozszerzający \Drupal\node\Plugin\Search\NodeSearch, przejdź na \Drupal\search_node\Plugin\Search\SearchNode.

Przeczytaj też: jeśli planujesz, jak AI ma wspierać redaktorów po aktualizacji, sprawdź nasz przewodnik o tworzeniu treści na stronie z użyciem modułów AI w Drupalu.

SEO i bezpieczeństwo

Drupal 11.4 wprowadza również kilka zmian związanych z SEO, bezpieczeństwem oraz kontrolą jakości danych. Choć nie są to funkcje widoczne na pierwszy rzut oka, mogą mieć realny wpływ na wydajność indeksowania, stabilność systemu i codzienne utrzymanie serwisu.

• robots.txt blokuje strony wyników wyszukiwania. Domyślny plik robots.txt blokuje teraz indeksowanie stron wyników wyszukiwania z parametrami query. Dodano reguły Disallow: /search? oraz Disallow: /index.php/search?. Powód: wyszukiwarki indeksowały dynamiczne wyniki i crawlowały nieskończone kombinacje stron faceted search, co obciążało serwer i pogarszało jakość SEO. Jeśli masz własny, zmodyfikowany robots.txt, musisz dodać te reguły ręcznie.
• Walidacja UUID. Pole typu uuid, używane automatycznie do przechowywania UUID encji treści, sprawdza teraz, czy wartość faktycznie jest poprawnym UUID.
• Cacheowalne odpowiedzi 404. Router::matchRequest() rzuca teraz CacheableResourceNotFoundException zamiast zwykłego ResourceNotFoundException, a doszedł też nowy cache context dla statusu wyjątku. W praktyce oznacza to lepsze cache’owanie odpowiedzi 404 i 403.

Front-end, Twig i CKEditor

Warstwa prezentacji i projekty decoupled również dostają kilka usprawnień.

• Funkcje z twig/html-extra. Dodano pakiet twig/html-extra, który udostępnia funkcje html_cva, html_attr oraz html_classes. Wszystkie trzy są teraz dostępne w szablonach Twig, co upraszcza budowanie atrybutów i klas CSS.
• CKEditor 5 zaktualizowany do 47.6.2. Edytor dostał aktualizację wersji wraz z licznymi mniejszymi aktualizacjami zależności front-endowych.
• #url w responsive image to obiekt Url. W elemencie theme responsive_image_formatter właściwość #url jest teraz obiektem Drupal\Core\Url zamiast stringa, co pozwala manipulować opcjami URL.
• Nowa właściwość resolvable_uri na polu link. Pole link dostało property resolvable_uri, które zwraca link gotowy do użycia w atrybucie href. To istotne dla projektów decoupled i JSON:API: zamiast surowego internal:/ z osobnym fragmentem, API zwraca od razu gotowy /#main-content. Doszedł też token [entity:field_link:resolvable_uri], a ustawienie resolvable_uri inicjalizuje pozostałe właściwości linku (uri, query, fragment).

Co musisz wiedzieć przed aktualizacją

Kilka rzeczy, które warto sprawdzić, zanim zaktualizujesz produkcję.

Przeczytaj też: aktualizacja Drupala krok po kroku, przygotowanie i typowe wyzwania.

• Szablon drupal/legacy-project oznaczony jako abandoned. Jeśli twój projekt nadal bazuje na drupal/legacy-project, czas przejść na drupal/recommended-project.
• Ścieżka do Drupala 12. Sajty muszą być na wersji co najmniej 11.3.0 przed aktualizacją do 12.x, bo Drupal 12 usunął update hooki sprzed 11.3. Przejście na 11.4 ustawia cię w dobrej pozycji na tę migrację.
• HTML5 validation. Doszedł setting enable_html5_validation w settings.php. W Drupalu 12 walidacja HTML5 będzie domyślnie wyłączona, więc warto już teraz świadomie ustawić tę wartość pod swoje formularze.
• Nginx i Brotli. Jeśli hostujesz na Nginx i chcesz korzystać z prekompresji Brotli, dodaj konfigurację serwera z brotli_static (Apache nie wymaga zmian). Sprawdź też kod, który programowo ustawia css.gzip/js.gzip, i przejdź na css.compress/js.compress.
• Custom search pluginy. Jeśli masz plugin oparty o NodeSearch, zaktualizuj go pod nowy sub-moduł search_node.

Najważniejsze deprecje w 11.4

W tym wydaniu sporo elementów API zostało oznaczonych jako przestarzałe (deprecated). Jeśli utrzymujesz własne moduły, warto zaplanować ich przegląd. Oto najważniejsze z tych zmian:

• check_markup() jest deprecated, bez zamiennika. Rekomendacja: zwracaj renderable array zamiast spłaszczać do markup, żeby zachować metadane cacheability.
• Funkcje render hide() i show() są deprecated. Zamiast nich używaj flagi #printed w render array.
• file_get_file_references() zastępuje serwis FileReferenceResolver.
• node_access_rebuild() i node_access_grants zastępują serwisy (m.in. NodeGrantsHelper).
• \Drupal\node\Controller\NodeViewController zastępuje EntityViewController.
• Trasy user.pass.http, user.login.http, user.login_status.http i user.logout.http przeniesiono do modułu rest.
• Dostęp do globalnej zmiennej autoload jest deprecated, zamiast tego dołączaj vendor/autoload.php.
• Szereg funkcji locale (locale.batch.inc, locale.bulk.inc, locale.compare.inc) zastępują nowe serwisy, m.in. LocaleSource, LocaleFileManager i LocaleFetch.

Wszystkie deprecje mają zamienniki opisane w change recordach na drupal.org, a samo działanie kodu nie znika w 11.4. Usunięcie nastąpi dopiero w kolejnym majorze.

Czy warto aktualizować do 11.4?

Od ponad dekady pomagamy organizacjom rozwijać, utrzymywać i modernizować platformy Drupal — od stron korporacyjnych, przez intranety, aż po rozbudowane aplikacje biznesowe. Dzięki doświadczeniu zdobytemu przy aktualizacjach kolejnych generacji Drupala wiemy, jak bezpiecznie przeprowadzać migracje, eliminować deprecje i przygotowywać projekty na przyszłe wydania platformy.

Najwięcej uwagi wymaga kod custom: przejrzyj deprecje, sprawdź ewentualny własny front controller pod kątem Symfony Runtime i dodaj reguły do zmodyfikowanego robots.txt. Dla typowego sajtu zbudowanego na standardowych modułach aktualizacja powinna być szybka, a korzyści odczuwalne od razu po wdrożeniu. Jak w praktyce wygląda dobrze przygotowana aktualizacja Drupala, opisaliśmy w osobnym poradniku.

Potrzebujesz pomocy z aktualizacją lub utrzymaniem Drupala?

W Droptica pracujemy z Drupalem od ponad dekady: aktualizujemy, utrzymujemy i rozwijamy platformy enterprise, intranety oraz złożone aplikacje webowe. Wiemy, jak przeprowadzić aktualizację minor bez przestojów i jak ogarnąć deprecje w kodzie custom, żeby projekt był gotowy także na Drupala 12.

Jeśli planujesz aktualizację do Drupala 11.4 albo chcesz mieć pewność, że twój projekt jest bezpieczny i wydajny, sprawdź nasze usługi Drupal development lub napisz do nas bezpośrednio, żeby omówić szczegóły.