PHP 8.2 kończy wsparcie bezpieczeństwa 31 grudnia 2026 — po tej dacie żadna nowa podatność w interpreterze nie dostanie łaty. To nie „kiedyś warto", to deadline z konkretną datą: zostały dwa miesiące, a aktualizacja z 8.2 na 8.4 jest jedną z najprostszych migracji w historii PHP — kod napisany pod 8.2 zwykle wymaga kosmetycznych poprawek. Ten artykuł pokazuje, jak sprawdzić, czy problem dotyczy Twojego systemu, jakie masz opcje i jak zaplanować działanie przed końcem roku.
Najważniejsze: PHP 8.2 przechodzi 31.12.2026 do kategorii wersji bez wsparcia — razem z 8.1, 8.0, 7.4 i starszymi. Droga wyjścia to aktualizacja na 8.3 lub 8.4. Dla większości aplikacji to praca dni, nie miesięcy: audyt zgodności, poprawki deprecation, testy i wdrożenie na staging, potem produkcja.
Co dokładnie kończy się 31 grudnia 2026
PHP 8.2 zostało wydane 8 grudnia 2022. Zgodnie z cyklem wydawniczym PHP (od 2024 roku cztery lata: dwa lata poprawek błędów i dwa lata poprawek bezpieczeństwa) wersja 8.2 ma wsparcie bezpieczeństwa do końca 2026 roku.
Do 31 grudnia 2026 PHP 8.2 dostaje jeszcze krytyczne poprawki bezpieczeństwa — jeśli luka zostanie zgłoszona i naprawiona przed tą datą, łata trafi również do 8.2. Po 31 grudnia 2026 gałąź 8.2 przechodzi do archiwum: żadnych poprawek, żadnych wydań, nawet dla krytycznych podatności.
Co to oznacza w praktyce dla systemu na 8.2.
- Nowe podatności w interpreterze pozostają bez łaty na zawsze — system staje się celem, a nie „ryzykiem teoretycznym".
- Nie dostaniesz też poprawek błędów — problemy, które społeczność znajdzie i naprawi w 8.4, w 8.2 zostaną na zawsze.
- Coraz więcej bibliotek podniesie minimalną wersję PHP — aktualizacje pakietów przestaną być możliwe bez migracji.
- Hostingi zaczynają wygaszać stare wersje — po EOL zwykle zostają one na serwerach jeszcze rok–dwa, potem znikają albo stają się płatnym „dodatkiem legacy".
Historię poprzednich EOL widać w liczbach: PHP 7.4 przestał dostawać łaty w listopadzie 2022, PHP 8.0 w listopadzie 2023, PHP 8.1 na koniec 2025. Każda z tych dat to dla systemów produkcyjnych moment, w którym koszt pozostania rośnie skokowo. Pełna tabela dat — w artykule o wersjach PHP i datach wsparcia.
Kogo dotyczy ten deadline
Na PHP 8.2 działa dziś szeroka grupa systemów — i wcale nie chodzi tylko o „stare aplikacje".
- Aplikacje custom i systemy wewnętrzne — wdrożone w latach 2023–2024 na ówczesną, aktualną wersję PHP. Nikt ich nie aktualizował, bo „działa".
- Sklepy i strony na popularnych platformach — PrestaShop 8.x wspiera PHP 8.2 (i nowsze), WordPress od wersji 6.x działa na 8.2 bez problemów. Ale sama platforma to nie wszystko — decydują wtyczki, moduły i motywy.
- Aplikacje na frameworkach — Laravel 10/11 wspierają PHP 8.2; jeśli aplikacja stoi na starszej wersji frameworka, przed aktualizacją PHP czeka też aktualizacja frameworka.
- Systemy z hostingów zarządzanych — część hostingów utrzymuje domyślnie 8.2, bo to „bezpieczny kompromis" między nowością a kompatybilnością. Po EOL to nastawienie się zmieni.
Jeśli nie wiesz, na jakiej wersji działa Twój system, sprawdzisz to w minutę.
Jak sprawdzić wersję PHP swojego systemu
Najprostsze sposoby, w kolejności od najmniej inwazyjnego.
# Z linii poleceń (SSH)
php -v
# Albo przez zapytanie do aplikacji (jeśli masz dostęp do pliku)
php -r "echo PHP_VERSION;"
Bez dostępu do serwera wersję odczytasz z panelu hostingu (sekcja „wersje PHP" albo „konfiguracja PHP") albo z poziomu aplikacji — WordPress pokazuje ją w Narzędzia → Zdrowie witryny → Informacje, PrestaShop w Zaawansowane → Informacje, a aplikacje custom często w stopce panelu administracyjnego.
Wskazówka: Jeśli zarządzasz kilkoma projektami, zrób jednorazowy przegląd wszystkich — wersja PHP, wersja frameworka/platformy i data ostatniej aktualizacji zależności. To 15 minut, które dają mapę ryzyk na najbliższe miesiące.
Trzy scenariusze — co zrobić przed końcem roku
Dla systemu na PHP 8.2 masz trzy drogi. Dwie pierwsze są sensowne, trzecia to odraczanie problemu.
Scenariusz A — aktualizacja na PHP 8.3 lub 8.4. Droga domyślna i zwykle najtańsza. Przejście 8.2 → 8.3 → 8.4 to najmniejszy skok między wersjami w całej historii PHP 8 — większość zmian to deprecation, które działają dalej, ale zaśmiecają logi. Dla typowej aplikacji: audyt zgodności, poprawki, testy, wdrożenie. Dni do dwóch tygodni pracy, zależnie od rozmiaru projektu i stanu testów. Szczegóły przejścia opisuję w artykule o migracji PHP 7.4 na 8.x — sekcja o 8.2 → 8.4 dotyczy dokładnie tego scenariusza.
Scenariusz B — zostanie na 8.2 z komercyjnym wsparciem (extended support). Istnieją firmy (np. Zend, TuxCare), które sprzedają przedłużone łaty bezpieczeństwa dla wersji po EOL. To rozwiązanie ma sens w jednym przypadku: system jest tak duży, że migracja zajmie kwartały, a Ty potrzebujesz łatek „na już". Koszt to zwykle kilka–kilkanaście tysięcy złotych rocznie i — co ważne — to nie zastępuje migracji, tylko kupuje czas. Podatności łata dostawca, nie społeczność PHP.
Scenariusz C — zostawić jak jest i „zobaczyć, co się stanie". Odradzam. Po EOL rośnie ryzyko, a koszt migracji nie maleje — rośnie, bo z czasem dochodzą kolejne wersje do nadrobienia i kolejne zaktualizowane biblioteki wymagające nowszego PHP. Do tego dochodzą wymiary pozatechniczne: audyty bezpieczeństwa, RODO, wymagania ubezpieczycieli i klientów B2B coraz częściej pytają o wspierane wersje komponentów.
Plan działania do 31 grudnia 2026
Dwa miesiące to wystarczający czas na uporządkowaną migrację 8.2 → 8.4. Realistyczny rozkład pracy wygląda tak.
| Termin | Etap | Efekt |
|---|---|---|
| Do końca października | Audyt zgodności (PHPCompatibility, PHPStan), inwentaryzacja zależności | Lista blokad i plan |
| Pierwsza połowa listopada | Poprawki deprecation, aktualizacja zależności | Kod zgodny z 8.4, testy zielone |
| Druga połowa listopada | Staging na 8.4 z realnymi danymi, testy ścieżek krytycznych | Potwierdzona zgodność |
| Grudzień | Wdrożenie produkcyjne poza szczytem, monitoring | System na 8.4 przed EOL |
Jeśli projekt jest mały, całość zmieści się w jednym tygodniu. Jeśli system jest duży i bez testów — zacznij od razu, a jeśli nie zdążysz do końca roku, scenariusz B (komercyjne wsparcie) daje bufor na dokończenie migracji bez zostawiania systemu bez łatek.
Co się psuje przy przejściu 8.2 → 8.4
Skok z 8.2 na 8.4 to dwie wersje różnicy i — dobra wiadomość — żadna z nich nie usunęła funkcji, z których korzystają typowe aplikacje. Problemy, które faktycznie zobaczysz, to głównie deprecation i kilka zmian zachowania.
- Typowane stałe klas (8.3) — kod, który nadpisywał stałe w klasach potomnych ze zmienionym typem, dostaje błąd. W praktyce dotyczy to głównie bibliotek — aktualizacja je naprawia.
get_class()bez argumentu (8.3) — deprecation; wywołanie wewnątrz klasy trzeba zamienić nastatic::classalboself::class. Rector robi to automatycznie.- Niejawne parametry nullowalne (8.4) —
function f(string $x = null)to od 8.4 deprecation; poprawna forma to?string $x = null. Zmiana kosmetyczna, ale wymaga przejścia po sygnaturach — znowu: Rector. - Deprecation interpolacji i dynamicznych właściwości (z 8.2) — jeśli system przeszedł na 8.2 niedawno, te ostrzeżenia nadal siedzą w logach; przy okazji migracji warto je wyczyścić do zera, bo zaśmiecają monitoring.
- Zmiany w zależnościach — najczęstszy realny problem: podnosząc PHP, musisz podnieść też biblioteki, a część z nich zmieniła API między wersjami. To praca, którą trzeba zaplanować — nie niespodzianka.
Po migracji zostaw w logach monitoring deprecation na kilka tygodni. Ostrzeżenia, które zostaną, to lista do posprzątania przed kolejnym krokiem (8.5, a potem 8.6, którego premiera spodziewana jest pod koniec 2026).
Ile to trwa i ile kosztuje
Migracja z 8.2 to najtańszy typ migracji PHP — kod jest już nowoczesny, a różnice między wersjami niewielkie.
| Projekt | Zakres pracy | Czas | Koszt (netto) |
|---|---|---|---|
| Mała aplikacja / strona | audyt, poprawki deprecation, testy dymne | 1–3 dni | 1 500 – 5 000 zł |
| Średnia aplikacja | audyt, poprawki, aktualizacja zależności, staging | 1–2 tygodnie | 5 000 – 15 000 zł |
| Duży system bez testów | testy zabezpieczające + migracja etapami | 3–8 tygodni | 15 000 zł+ (etapami) |
Do tego doliczyć trzeba ewentualne koszty przedłużonego wsparcia, jeśli zdecydujesz się na scenariusz B jako bufor. Widełki dla pełnych migracji ze starych wersji (5.6, 7.x) opisuję w artykule o koszcie migracji PHP, a zakres usługi na stronie modernizacji legacy PHP.
Najczęściej zadawane pytania
Czy PHP 8.2 przestanie działać 1 stycznia 2027?
Nie — system będzie działał dalej. Kończy się wsparcie, nie działanie. Po 31 grudnia 2026 PHP 8.2 nie dostaje żadnych poprawek, więc nowo odkryte podatności zostają bez łaty. Ryzyko nie jest natychmiastowe, ale rośnie z każdym miesiącem — dlatego migrację planuje się przed EOL, nie po.
Jaka jest różnica między „active support" a „security support" dla PHP?
Active support (pierwsze dwa lata) obejmuje poprawki błędów i bezpieczeństwa. Security support (kolejne dwa lata) to wyłącznie krytyczne poprawki bezpieczeństwa — bez poprawek błędów. PHP 8.2 jest w fazie security support od 1 stycznia 2025 i wyjdzie z niej 31 grudnia 2026.
Czy mogę od razu przeskoczyć z PHP 8.2 na 8.5?
Tak — i to sensowna opcja, jeśli chcesz uniknąć kolejnej migracji za rok. Przejście 8.2 → 8.5 obejmuje trzy kroki różnic, ale nadal są to głównie deprecation i zmiany w zależnościach. Warunek jest jeden: framework i biblioteki muszą wspierać 8.5. Jeśli nie — migruj na 8.4 (pełne wsparcie do końca 2028) i zaplanuj 8.5 później.
Czy WordPress działa na PHP 8.2 po zakończeniu wsparcia?
WordPress działa na 8.2 i nie „przestanie" — ale WordPress sam podnosi wymagania z czasem, a wtyczki i motywy coraz częściej wymagają nowszych wersji PHP. Strona na 8.2 po EOL to rosnące ryzyko bezpieczeństwa, zwłaszcza jeśli na pokładzie są wtyczki bez aktualizacji. Proces bezpiecznej aktualizacji opisuję w artykule o WordPress i PHP 8.
Czy migracja z 8.2 wymaga zatrzymania systemu?
Nie. Pracujesz na stagingu na kopii danych, a na produkcji robisz tylko podmianę wersji PHP poza szczytem ruchu, z możliwością natychmiastowego powrotu na 8.2 (stara wersja zostaje na serwerze). Cała weryfikacja dzieje się przed wdrożeniem.
Ile kosztuje zostanie na PHP 8.2 po EOL?
Bezpośrednio — nic, dopóki nie zostanie odkryta podatność, którą da się wykorzystać. Pośrednio: komercyjne wsparcie to zwykle kilka–kilkanaście tysięcy złotych rocznie, a ryzyko incydentu w systemie bez łatek rośnie z czasem. W praktyce najdroższą opcją jest „nic nie robić" — koszt awarii bezpieczeństwa i przymusowej migracji pod presją jest wyższy niż zaplanowanej aktualizacji.