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

Drupal 11.4 to kolejne wydanie minor w gałęzi 11.x, planowane na stabilną premierę w tygodniu rozpoczynającym się 22 czerwca 2026. Nie łamie kompatybilności wstecznej publicznych API, ale wprowadza sporo konkretów: routing przez atrybuty PHP, nowy bootstrap oparty o Symfony Runtime, kompresję Brotli dla assetów, zmiany w robots.txt pod SEO oraz całą listę deprecji, które warto ogarnąć w modułach custom. Wersja 11.4.0-beta1 jest już dostępna (od 3 czerwca 2026), więc wszystkie opisane niżej zmiany są już w kodzie i możesz je przetestować od teraz (beta nie jest jednak rekomendowana na produkcję). Poniżej przechodzę przez to, co faktycznie zmienia się względem Drupala 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 ukazał się 3 czerwca 2026, a stabilne wydanie 11.4.0 zaplanowano na tydzień rozpoczynający się 22 czerwca 2026 (zgodnie z oficjalnym harmonogramem zaktualizowanym 4 czerwca 2026; beta1 wyszła z poślizgiem, więc cały cykl się przesunął). To wydanie minor, czyli zgodnie z polityką Drupala wnosi nowe funkcje i usprawnienia, ale nie łamie kompatybilności wstecznej publicznych API. Mogą natomiast zmienić się wewnętrzne API i moduły eksperymentalne, więc moduły kontrybuowane i custom mogą wymagać aktualizacji.

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

Najciekawszą zmianą deweloperską w 11.4 jest możliwość definiowania tras bezpośrednio w kodzie za pomocą atrybutów PHP, zamiast wyłącznie w plikach *.routing.yml. Każda klasa w przestrzeni nazw Controller modułu (np. Drupal\example\Controller), która ma atrybut Symfony\Component\Routing\Attribute\Route, zostanie wykryta jako definicja trasy.

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 przyjmuje komponent symfony/runtime, żeby uprościć i oddzielić proces bootstrapu. Dla większości sajtów jest to zmiana niewidoczna, ale jeśli masz własny front controller (custom index.php lub inny skrypt wejściowy), warto przeczytać dedykowany change record, bo sposób inicjalizacji aplikacji się zmienia.

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

Wydajność to jeden z mocniejszych obszarów tego wydania.

• 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.

SEO i bezpieczeństwo

Drupal 11.4 poprawia kilka domyślnych ustawień, które wpływają na widoczność w wyszukiwarkach i odporność na nieprawidłowe dane.

• 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?

Jeśli jesteś na 11.3, aktualizacja do 11.4 to nisko ryzykowny ruch: wydanie minor, bez łamania BC dla publicznych API, a w zamian dostajesz dłuższe wsparcie bezpieczeństwa (do czerwca 2027), realne usprawnienia wydajności (Brotli, szybsze recipe, nowy cache), lepsze domyślne SEO i wygodniejszy routing dla deweloperów.

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.