Drupal 10 koniec wsparcia: aktualizacja do Drupala 11 czy migracja

Drupal 10 traci wsparcie 9 grudnia 2026 r., sześć tygodni po publikacji tego tekstu. Po tej dacie rdzeń nie dostanie już żadnej poprawki bezpieczeństwa. Masz trzy drogi: aktualizację do Drupala 11, szukanie dodatkowego czasu albo migrację na inną platformę. Pracuję zarówno przy Drupalu, jak i przy WordPressie, więc piszę o obu kierunkach. Dla dużego urzędu, uczelni czy serwisu z wieloma redaktorami Drupal 11 jest zwykle właściwym wyborem. Dla małej strony, którą prowadzi jedna osoba, migracja do WordPressa bywa tańsza w utrzymaniu przez następne lata. Poniżej znajdziesz daty ze źródłami, tabelę decyzji, procedurę aktualizacji, którą stosuję, typowe problemy i listę zadań na najbliższe tygodnie.

Stan na 28 października 2026 r. Daty i wymagania pochodzą z dokumentacji na drupal.org, linki stoją przy każdej z nich.

#Drupal 10 koniec wsparcia: kiedy dokładnie i co z tego wynika

Harmonogram wydań Drupala podaje jedną datę: Drupal 10 osiąga koniec życia 9 grudnia 2026 r. i po niej nie powstanie żadne nowe wydanie tej wersji. Ostatnią wersją minor jest 10.6. W tym samym tygodniu, który zaczyna się 7 grudnia, ukazują się Drupal 12.0.0 i Drupal 11.5.0, a wsparcie bezpieczeństwa tracą jednocześnie gałęzie 10.6.x i 11.3.x.

Najnowsze wydanie gałęzi 10 w chwili pisania to 10.6.20 z 21 października 2026 r. (według kanału wydań rdzenia). Jeśli twoja strona działa na starszej wersji 10.x, jest już bez wsparcia dziś. Wsparcie dla 10.5.x skończyło się w tygodniu 29 czerwca 2026 r., kiedy wyszedł Drupal 11.4.0.

Co oznacza koniec życia w praktyce, opisuje strona zespołu bezpieczeństwa Drupala: zespół zajmuje się tylko wspieranymi wersjami, a użytkownikom wersji niewspieranych zaleca aktualizację. Strona na Drupalu 10 nie wyłączy się 10 grudnia. Gdy ktoś znajdzie lukę w rdzeniu, poprawka trafi do Drupala 11 i 12, a do 10 już nie. Moduły społeczności też będą stopniowo kończyć wydania dla 10.

Drupal 11 nie ma jeszcze opublikowanej daty końca wsparcia. Zasady cyklu wydań mówią, że każda wersja główna ma wsparcie co najmniej przez cztery lata, do wydania dwóch kolejnych wersji głównych, a nowe wersje główne wychodzą co dwa lata. Po wydaniu Drupala 12 gałąź 11 przechodzi w fazę długoterminowego wsparcia, w której co pół roku wychodzi wersja konserwacyjna. Konkretnej daty nie podaję, bo drupal.org jej nie podał.

#Aktualizacja, dodatkowy czas czy migracja: tabela decyzji

Decyzja zależy przede wszystkim od tego, jak strona jest zbudowana i kto ją prowadzi. Tak rozkładam typowe profile, kiedy klient pyta mnie o Drupala 10:

Jeśli twój profil to pierwsze trzy wiersze, zajrzyj do opisu mojej pracy jako programista Drupal, tam opisuję zakres aktualizacji i audytu. Szersze porównanie platform dla dużych serwisów, z tabelą ról i wielojęzyczności, jest w rankingu CMS dla dużych stron firmowych.

#Czy można kupić przedłużone wsparcie dla Drupala 10?

Dla Drupala 7 taki rynek istnieje. Na stronie partnerów przedłużonego wsparcia drupal.org wymienia HeroDevs i Tag1 Consulting. Oferta HeroDevs dotyczy wyłącznie Drupala 7, a strona Tag1 o Drupalu odmówiła mi dostępu, więc nie potwierdziłem jej zakresu. Dla Drupala 10 nie znalazłem 28 października 2026 r. żadnej oferty wsparcia po 9 grudnia. Jeśli któryś dostawca ją ogłosi, sprawdź, co obejmuje: sam rdzeń czy także moduły, których używasz.

Najprostszy sposób na zyskanie czasu to Drupal 11. Gałąź 11 dostaje poprawki według zasad opisanych wyżej, a każda wersja minor ma wsparcie przez rok, w tym przez pierwsze pół roku poprawki błędów i bezpieczeństwa, a przez drugie pół roku tylko bezpieczeństwa. Aktualizacja z 10 do 11 jest też mniejsza niż kiedyś przejścia między wersjami głównymi, bo od Drupala 8 kod zmienia się stopniowo, a przestarzałe funkcje są oznaczane z wyprzedzeniem.

#Jak zaktualizować Drupal 10 do 11 krok po kroku

Oficjalny przewodnik aktualizacji z 10 do 11 stawia trzy warunki wstępne: strona musi działać na Drupalu 10.3.0 lub nowszym, serwer musi mieć PHP 8.3.0 lub nowsze, a ty potrzebujesz dostępu do wiersza poleceń z Composerem i Drushem. Do tego dochodzą wymagania bazy danych: MySQL 8.0+, MariaDB 10.6+, PostgreSQL 16+ albo SQLite 3.45+. Serwer WWW to Apache 2.4.7+ albo Nginx, a Microsoft IIS od Drupala 11.0.0 nie jest obsługiwany.

Tak wygląda kolejność, w której pracuję:

1. Kopia i środowisko testowe. Uruchamiam Upgrade Status na kopii strony, nigdy na produkcji. Kopia stoi na serwerze z PHP 8.3 i bazą spełniającą wymagania Drupala 11, żeby problemy z serwerem wyszły od razu.
2. Rdzeń do najnowszej 10.6.x. Najpierw aktualizuję Drupala 10 do ostatniego wydania gałęzi 10.6. Część przestarzałych wywołań w modułach znika już na tym etapie, bo ich autorzy wydali wersje zgodne z 10.3+ i 11 jednocześnie.
3. Audyt modułem Upgrade Status. Upgrade Status sprawdza gotowość środowiska i każdego modułu oraz motywu do następnej wersji głównej. Na Drupalu 10 pokazuje gotowość do 11. Raport dzieli moduły na takie, które mają wydanie zgodne z 11, takie, które trzeba zaktualizować, i takie, które wydania nie mają.
4. Analiza kodu własnego. Własne moduły i motyw sprawdzam narzędziem drupal-check, które działa na PHPStan i wykrywa przestarzałe wywołania. Oficjalny przewodnik go nie wymienia, to mój dodatkowy krok. Część poprawek robi automatycznie Drupal Rector, którego reguły obejmują przestarzały kod od Drupala 10.0 do 11.4. Wynik Rectora zawsze przeglądam ręcznie przed zatwierdzeniem.
5. Moduły bez wydania dla 11. Jeśli moduł ma łatkę zgodności, ale brak wydania, używam wtyczki Composera composer-drupal-lenient. Pozwala zainstalować moduł mimo niezgodnego ograniczenia wersji rdzenia, pod warunkiem że wpiszesz go do listy extra.drupal-lenient.allowed-list. To rozwiązanie przejściowe: łatka wymaga przeglądu, a moduł wraca na listę zadań, dopóki autor nie wyda wersji dla 11.
6. Moduły usunięte z rdzenia. Jeśli strona używa któregoś z modułów wymienionych w następnej sekcji, przed aktualizacją dodaję do projektu jego wersję ze społeczności.
7. Aktualizacja przez Composer. Podnoszę ograniczenia pakietów drupal/core-recommended, drupal/core-composer-scaffold i pokrewnych do ^11, uruchamiam composer update, potem drush updatedb i eksport konfiguracji.
8. Testy. Sprawdzam logowanie i role, edycję każdego typu treści, formularze, wyszukiwarkę, widoki Views, tłumaczenia, zadania cron i integracje. Na stronach podmiotów publicznych dochodzi przegląd dostępności, o którym piszę niżej.
9. Wdrożenie z planem powrotu. Przed wdrożeniem mam kopię bazy i poprzednią wersję kodu gotowe do przywrócenia.

Czasu na całość nie podaję bez audytu. Zależy od liczby modułów, ilości kodu własnego i od tego, czy serwer ma PHP 8.3. Raport z kroku 3 to pierwszy konkretny dokument, na podstawie którego da się zaplanować pracę i budżet.

#Moduły usunięte z rdzenia Drupala 11 i ich zamienniki

Lista przestarzałych i usuniętych modułów na drupal.org podaje, co zniknęło z rdzenia w Drupalu 11.0 i dokąd się przeniosło:

Kolejność ma znaczenie: moduł społeczności dodajesz, kiedy strona jest jeszcze na Drupalu 10, bo wtedy obie wersje mogą istnieć obok siebie. Po aktualizacji rdzenia jest już za późno, a Composer albo Drupal zgłosi błąd brakującego modułu.

Ta sama strona pokazuje następną falę. W gałęzi 11.x jako przestarzałe oznaczono między innymi Ban, Contact, Field Layout, History, Telephone, Search, Settings Tray, Shortcut i Migrate Drupal UI. Wszystkie znikają z rdzenia w Drupalu 12.0. Pasek narzędzi Toolbar też został usunięty z rdzenia w 12.0.0. Motywy Claro i Olivero są przestarzałe od 11.5.0 i znikają w 12.0.0, a w miejsce Claro projekt zaleca nowy motyw Default Admin. Moduły Contact i Search są na stronach urzędów bardzo częste, więc warto je wpisać do planu już przy przejściu na 11.

#Dlaczego nie przechodzić od razu na Drupal 12 w grudniu?

Drupal 12.0.0 wychodzi w tygodniu 7 grudnia 2026 r., czyli tuż przed końcem życia Drupala 10. Kusi, żeby od razu przeskoczyć dwie wersje. Trzy fakty przemawiają przeciw temu.

Po pierwsze, ścieżki 10 do 12 nie ma. Upgrade Status sprawdza zawsze następną wersję główną, więc najpierw przechodzisz na 11, a z 11 na 12.

Po drugie, wymagania serwera. Tabela wymagań PHP dla Drupala 12.0 ma tylko jedną pozycję oznaczoną jako obsługiwana: PHP 8.5. PHP 8.3 i 8.4 są przy 12.0 oznaczone jako nieobsługiwane. Od Drupala 12.0 PHP powinno też być skompilowane z obsługą argon2 do haszowania haseł. Wymagania bazy rosną do MariaDB 10.11+, MySQL 8.0+ albo PostgreSQL 18+. Drupal 11.1 do 11.4 działa z PHP 8.3 i 8.4, a od 11.3 także z 8.5.

Po trzecie, moduły społeczności. W dniu wydania nowej wersji głównej część modułów nie ma jeszcze wydania zgodnego. Drupal 12.0.0-beta2 ukazał się 14 października 2026 r., więc autorzy modułów mają mało czasu.

Moja kolejność dla strony, która dziś stoi na Drupalu 10: aktualizacja do 11.4 albo 11.5 przed 9 grudnia, potem spokojne przejście na 12, kiedy serwer ma PHP 8.5, a moduły mają wydania zgodne. Gałąź 11 daje na to czas według zasad długoterminowego wsparcia.

#Drupal 7 w 2026 roku: co dalej z taką stroną

Wsparcie bezpieczeństwa Drupala 7 skończyło się 5 stycznia 2025 r. i od tej daty Drupal 7 nie dostaje ani poprawek bezpieczeństwa, ani aktualizacji zgodności. Strony na Drupalu 7 wciąż działają, także w instytucjach publicznych, i od blisko dwóch lat nie mają poprawek rdzenia, chyba że ich właściciel wykupił wsparcie u jednego z partnerów wymienionych na drupal.org.

Druga data dotyczy narzędzi migracji. Według listy przestarzałych modułów moduł Migrate Drupal UI jest przestarzały od Drupala 11.3.0, a Migrate Drupal UI i Migrate Drupal znikają z rdzenia w Drupalu 12.0. Żaden z nich nie zostanie przeniesiony do modułów społeczności, co potwierdza zamknięte zgłoszenie meta o usunięciu Migrate Drupal. Drupal 12 zachowuje samo API migracji, ale bez źródeł dla Drupala 6 i 7.

Wniosek dla właściciela strony na Drupalu 7: jeśli chcesz przenieść treść ścieżką rdzenia, robisz to na Drupalu 11. Migracja z 7 to w praktyce budowa nowej strony z przeniesieniem treści, użytkowników i plików. Dlatego przy Drupalu 7 zawsze porównuję dwa warianty: nowy Drupal 11 albo WordPress. O wyborze decyduje profil z tabeli powyżej.

#Strona podmiotu publicznego: dostępność cyfrowa i zamówienie publiczne

Drupal jest w Polsce częsty na stronach urzędów, uczelni i instytucji kultury. Dla nich koniec życia Drupala 10 łączy się z dwiema sprawami spoza techniki.

Pierwsza to dostępność. Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848) obowiązuje podmioty publiczne i jest polskim odpowiednikiem dyrektywy (UE) 2016/2102 o dostępności stron sektora publicznego. Ustawa nie mówi nic o wersji CMS. Aktualizacja wersji głównej zmienia jednak to, co widzi redaktor i odwiedzający: motyw panelu, edytor treści, czasem szablony formularzy. Dlatego po każdej aktualizacji powtarzam test dostępności najważniejszych szablonów i formularzy, a przy przejściu na Drupal 12 planuję go także dla nowego motywu panelu. Firmy prowadzące sklep internetowy mają dodatkowo Europejski akt o dostępności (dyrektywa 2019/882), który od 28 czerwca 2025 r. obejmuje usługi dla konsumentów, w tym handel elektroniczny.

Druga to zamówienie publiczne i budżet. Jeśli aktualizację zlecasz zewnętrznie w trybie zamówienia publicznego, przygotowanie postępowania trwa, a 9 grudnia wypada pod koniec roku budżetowego. W opisie przedmiotu zamówienia sprawdzają się konkretne elementy: wersja docelowa (Drupal 11, z przygotowaniem do 12), raport Upgrade Status jako załącznik, lista modułów usuniętych z rdzenia, test dostępności po aktualizacji i plan powrotu. Opis “aktualizacja CMS do najnowszej wersji” bez tych punktów kończy się zwykle sporem o zakres. Więcej o stronach dla urzędów, w tym o wymaganiach dostępności, piszę na stronie strony internetowe dla urzędów.

Hosting też trzeba sprawdzić wcześnie. Drupal 11 wymaga PHP 8.3, a nie każdy polski hosting współdzielony czy serwer w serwerowni urzędu ma tę wersję włączoną. Wersję PHP sprawdzisz w panelu hostingu albo poleceniem php -v na serwerze. Jeśli serwer jest w zarządzie działu IT, zmiana wersji PHP to osobne zadanie z własnym terminem.

#Migracja z Drupala do WordPressa: co przeniesie wtyczka, a co zrobisz ręcznie

WordPress ma według W3Techs, stan na 28 października 2026 r., 39,5% wszystkich stron internetowych i 58,3% rynku CMS. Drupal ma 0,6% wszystkich stron i 0,9% rynku CMS. Ta różnica przekłada się na liczbę wykonawców i gotowych wtyczek, ale sama nie jest argumentem za migracją dużego serwisu.

Najczęściej używane narzędzie do przeniesienia treści to wtyczka FG Drupal to WordPress. W wersji 3.95.7 autor podaje, że testował ją z Drupalem od 4 do 11. Darmowa wersja przenosi artykuły, strony podstawowe, kategorie, tagi i obrazy, poprawia linki wewnętrzne i obsługuje bazy MySQL, PostgreSQL i SQLite. Wersja płatna dodaje komentarze, użytkowników, własne typy treści, własne taksonomie, pola, menu, przekierowania starych adresów Drupala na nowe adresy WordPressa, media Drupala i import przez WP-CLI. Sam WP-CLI nie ma importera z Drupala, polecenie wp import przyjmuje tylko plik WXR.

Wtyczka przenosi treść. Logikę strony odtwarzam zawsze ręcznie:

Docelowy serwer dla WordPressa ma zalecane wymagania: PHP 8.3 lub nowsze, MariaDB 10.11+ albo MySQL 8.0+ i HTTPS. Aktualna wersja WordPressa to 7.1.3. Podobny proces dla innego CMS opisałem przy migracji z TYPO3 do WordPressa, a pełną listę kroków dla każdej migracji w przewodniku migracji WordPress. Jeśli chcesz wiedzieć, czy twoja strona nadaje się do przeniesienia, zacznij od oceny migracji do WordPressa.

#Kiedy zostać przy Drupalu, a kiedy przejść na WordPress?

Zostań przy Drupalu, jeśli strona ma wielu redaktorów z różnymi uprawnieniami, obieg akceptacji, kilka wersji językowych prowadzonych przez osobne zespoły albo wiele stron na jednej instalacji. Drupal robi te rzeczy w rdzeniu, a ich odtworzenie w innym systemie zajmuje więcej niż aktualizacja. Drupal CMS 2.0, wydany 28 stycznia 2026 r. na rdzeniu 11.3, dodał edytor wizualny Drupal Canvas i szablony stron, więc praca redakcji w Drupalu 11 wygląda dziś inaczej niż kilka lat temu.

Przejdź na WordPress, jeśli stronę prowadzi jedna albo dwie osoby, typów treści jest kilka, a największy koszt to utrzymanie i szukanie wykonawcy. Wtedy migracja przy okazji końca wsparcia ma sens, bo i tak musisz zaplanować prace. O tym, jak pracuję po stronie WordPressa, piszę na stronie WordPress developer.

Jeśli twoja instytucja rozważa też TYPO3, porównanie znajdziesz na stronie programista TYPO3.

#Najczęstsze problemy przy aktualizacji Drupala 10 do 11

Każdy z tych problemów rozwiązuje się szybciej, jeśli wyjdzie na kopii. Dlatego audyt zawsze robię przed podpisaniem terminu wdrożenia.

#Co zrobić w tym tygodniu, a co w tym miesiącu

W tym tygodniu:

• Sprawdź wersję rdzenia w raporcie stanu (/admin/reports/status) albo poleceniem drush status.
• Sprawdź wersję PHP i bazy danych na serwerze produkcyjnym.
• Zrób kopię strony i uruchom na niej Upgrade Status.
• Zapisz, czy strona używa któregoś z modułów Actions UI, Activity Tracker, Book, Forum, Statistics lub Tour.

W tym miesiącu, przed 9 grudnia 2026 r.:

• Zaktualizuj rdzeń do najnowszej wersji 10.6.x.
• Zdecyduj na podstawie raportu: aktualizacja do 11 albo migracja.
• Jeśli zlecasz pracę w zamówieniu publicznym, przygotuj opis przedmiotu zamówienia z raportem jako załącznikiem.
• Ustal z działem IT lub hostingiem termin włączenia PHP 8.3.
• Zaplanuj test dostępności po aktualizacji.

W pierwszym półroczu 2027 r.:

• Zaplanuj przejście na Drupal 12 dopiero wtedy, gdy serwer ma PHP 8.5, a moduły mają wydania zgodne.
• Usuń zależność od modułów przestarzałych w 11.x, zanim znikną w 12.

Jeśli chcesz, żebym przejrzał raport Upgrade Status twojej strony i ocenił zakres prac, napisz przez stronę programista Drupal. W odpowiedzi dostaniesz listę zadań dla twojej strony.