PL
Kontakt
Kontakt

Artykuły

PHP 8.2 traci wsparcie 31 grudnia 2026. Co zrobić w czasie, który został

OpublikowanoDaty i wersje sprawdzone 25 października 2026.

Wsparcie PHP 8.2 ze strony projektu PHP kończy się 31 grudnia 2026 (php.net, strona supported versions). Wersja ukazała się 8 grudnia 2022, aktywne wsparcie straciła 31 grudnia 2024 i od tego czasu dostaje już tylko poprawki bezpieczeństwa. Najnowsze wydanie w chwili pisania to 8.2.35 z 21 października 2026. Po 31 grudnia php.net nie wyda już żadnej wersji 8.2. Wszystkie daty końca wsparcia PHP, Laravela i Symfony znajdziesz w naszym kalendarzu końca wsparcia.

Październikowe wydanie nie było rutynowe. Według komunikatu bezpieczeństwa php.net z 21 października 2026 PHP 8.2.35 łata dwie krytyczne podatności, CVE-2026-109618 i CVE-2026-109619, które mogą pozwolić na zdalne wykonanie kodu bez uwierzytelnienia. Te same poprawki trafiły do 8.3.36, 8.4.27 i 8.5.12, a php.net napisał, że „nie ma pełnych sposobów obejścia, jedynym bezpiecznym wyjściem jest aktualizacja”. Jeśli podobna luka wyjdzie na jaw w styczniu, poprawki dla 8.2 już nie będzie.

Z tego artykułu dowiesz się, co zmienia się 1 stycznia, jak sprawdzić, co trzyma Twoją aplikację na 8.2, na którą wersję przejść i co zrobić, jeśli nie zdążysz.

Co zmienia się 1 stycznia 2027

Nic się nie wyłącza. Aplikacja działa dokładnie tak jak wcześniej. Zmienia się to, co stanie się następnym razem, gdy ktoś znajdzie podatność w samym PHP, tak jak w październiku: poprawka wyjdzie dla wspieranych gałęzi, a dla 8.2 nie. W fazie samych poprawek bezpieczeństwa php.net i tak wydaje nowe wersje „w miarę potrzeb”, więc tracisz każdą poprawkę luki znalezionej po 31 grudnia, niezależnie od tego, ile ich będzie.

Ta sama data ma znaczenie jeszcze z trzech powodów.

  • PHP 8.4 traci aktywne wsparcie 31 grudnia 2026 i od tego dnia dostaje tylko poprawki bezpieczeństwa, do 31 grudnia 2028. Od stycznia regularne poprawki błędów dostają wyłącznie 8.5 i 8.6. Harmonogram wydania PHP 8.6 (wiki.php.net) zakłada wersję stabilną 19 listopada 2026.
  • Platformy mają własne terminy. Google App Engine standard kończy wsparcie środowiska php82 31 grudnia 2026, a wyłącza je 31 grudnia 2027. Od tego dnia wdrożenia na tym środowisku przestaną działać. AWS Elastic Beanstalk planuje wycofanie platformy PHP 8.2 na 31 marca 2027. Niektórzy hostingodawcy biorą dopłatę za utrzymywanie starej wersji, gdy projekt PHP przestaje ją łatać: mittwald pobiera obecnie 5 € netto miesięcznie za każdą wersję PHP w każdym projekcie, jeśli społeczność tej wersji już nie łata (dziś 8.1 i starsze), a w drugiej fazie, bez gwarantowanych poprawek, 15 €.
  • Paczki z dystrybucji nie trzymają się dat php.net. Debian 12 ma PHP 8.2 jako domyślną wersję i sam utrzymuje paczkę php8.2. Długoterminowe wsparcie (LTS) Debiana 12 ma potrwać do 30 czerwca 2028 (Debian LTS wiki). Jeśli Twoje PHP pochodzi z repozytoriów Debiana, sprawdź php8.2 w Debian security tracker, zanim zaczniesz planować pod 31 grudnia. Twoją datą końca może być data Debiana, a nie php.net.

Krok 1: sprawdź, co naprawdę działa na serwerze

Sprawdź to na serwerze produkcyjnym, i to w dwóch miejscach: w wierszu poleceń i w procesie, który obsługuje żądania HTTP, bo mogą to być różne wersje:

php -v
php -m
ps aux | grep -E "php-fpm" | head -3

Na Debianie i Ubuntu proces master PHP-FPM pokazuje ścieżkę do swojej konfiguracji, na przykład /etc/php/8.2/fpm/php-fpm.conf. To jest wersja, na którą trafiają Twoi użytkownicy. Zapisz też, skąd pochodzi binarka: paczka z dystrybucji, zewnętrzne repozytorium, tag obrazu Dockera albo ustawienie w panelu hostingu. Każde z tych źródeł ma własną ścieżkę aktualizacji i własną datę końca wsparcia.

Krok 2: znajdź, co trzyma Cię na 8.2

Większość aplikacji zostaje na 8.2, bo trzyma je tam framework albo któraś zależność. Composer powie Ci, która:

composer why-not php 8.4

Polecenie wypisuje zainstalowane paczki, których ograniczenie wersji PHP wyklucza 8.4. To minimalny zakres pracy: paczka z otwartym ograniczeniem, na przykład >=7.2, nie pojawi się na tej liście, a i tak może się wysypać na 8.4.

Potem sprawdź framework, bo to on wyznacza sufit:

FrameworkWspierane PHPKoniec poprawek bezpieczeństwa
Laravel 108.1–8.34 lutego 2025 (już minął)
Laravel 118.2–8.412 marca 2026 (już minął)
Laravel 128.2–8.524 lutego 2027
Laravel 138.3–8.517 marca 2028
Symfony 6.48.1 lub nowszelistopad 2027
Symfony 7.48.2 lub nowszelistopad 2029

Źródła: laravel.com/docs/13.x/releases i symfony.com/releases, oba sprawdzone 25 października 2026.

Aplikację na Laravelu 10 przeniesiesz najwyżej na PHP 8.3, a sam Laravel 10 przestał dostawać poprawki bezpieczeństwa w lutym 2025. Wtedy aktualizacja PHP i aktualizacja frameworka to jeden projekt i taniej jest zaplanować je razem.

Na koniec rozszerzenia. W PHP 8.4 IMAP, OCI8, PDO_OCI i PSpell wypadły z dystrybucji PHP i przeszły do PECL. Jeśli php -m pokazuje imap, a Twój kod wywołuje imap_open(), zacznij od tego. Hosting współdzielony, który przeniesie Cię na 8.4, może w ogóle nie oferować wersji z PECL.

Krok 3: wybierz wersję docelową

Wersja docelowaPoprawki bezpieczeństwa doCo daje od stycznia 2027
8.331 grudnia 2027rok, od początku tylko z poprawkami bezpieczeństwa
8.431 grudnia 2028dwa lata
8.531 grudnia 2029trzy lata, z poprawkami błędów do końca 2027

W większości projektów przejście z 8.2 na 8.4 to niewiele więcej pracy niż na 8.3, więc przystanek na 8.3 rzadko się opłaca. Domyślnie wybieramy 8.4, a 8.5 wtedy, gdy pozwalają na nią już wszystkie zależności. Pokaże to composer why-not php 8.5. Wydanie sprzed kilku tygodni, a takie będzie 8.6 w grudniu, to kiepski cel, kiedy goni termin. Daj bibliotekom czas, żeby nadążyły.

Krok 4: sprawdź, co się psuje między 8.2 a 8.4

PHP 8.3 zmieniło niewiele z tego, co dotyczy typowych aplikacji webowych. Najwięcej pracy jest przy PHP 8.4, a większość tej pracy to deprecations, czyli ostrzeżenia o przestarzałym kodzie:

  • Niejawnie nullowalne parametry. Zapis function find(User $user = null) jest przestarzały i trzeba go zmienić na ?User $user = null. W starszych projektach to zdecydowanie najczęstsza zmiana, do tego mechaniczna.
  • Ustawienia sesji. session.sid_length i session.sid_bits_per_character są przestarzałe. Sprawdź php.ini, pliki .user.ini i wywołania ini_set().
  • trigger_error() z E_USER_ERROR jest przestarzałe. Zamiast tego rzuć wyjątek.
  • E_STRICT zniknął jako poziom błędu, a stała jest przestarzała. Stare własne handlery błędów często się do niej odwołują.
  • Ostrzejsze zachowanie. exit() rzuca TypeError przy nieprawidłowym typie argumentu, round() odrzuca nieprawidłowe tryby zaokrąglania, a atrybuty PDO MySQL, takie jak ATTR_EMULATE_PREPARES, oczekują teraz wartości logicznych.

Domyślnie PHP zapisuje deprecations w logu i działa dalej. Najpierw sprawdź swój handler błędów: starsze frameworki i wiele własnych callbacków set_error_handler() zamienia każdy notice w wyjątek, a wtedy pierwsze ostrzeżenie o przestarzałym kodzie kończy się błędem krytycznym. Nawet z domyślnym handlerem aplikacja może przejść wszystkie testy na 8.4 i nadal zapisywać tysiące ostrzeżeń na godzinę. Uruchom ją na 8.4 na stagingu z logowaniem E_DEPRECATED, przeklikaj najważniejsze ścieżki i przeczytaj log, zanim przełączysz produkcję.

Krok 5: mechaniczną część zostaw narzędziom

Rector stosuje do kodu zestawy reguł dla kolejnych wersji PHP, ale sprawdza też, na jakiej wersji PHP działa projekt, i pomija każdą regułę, która wymaga nowszej. Jeśli nie ustawisz withPhpVersion(), bierze tę wersję z dolnej granicy require.php w composer.json. Dlatego ->withPhpSets(php84: true) działa różnie w zależności od ograniczenia:

  • przy "php": "^8.2" Rector stosuje tylko reguły do 8.2. Reguły dla 8.4 są pomijane, łącznie z tą, która jawnie oznacza parametry jako nullowalne;
  • przy "php": "^8.4" Rector stosuje wszystko do 8.4 włącznie, także składnię, która istnieje dopiero w 8.3 i 8.4, na przykład typowane stałe klas. Taki kod nie zadziała na 8.2.

Na czas przejścia zostaw "php": "^8.2", a jedyną potrzebną teraz regułę z 8.4 uruchom osobną, małą konfiguracją: ->withRules([ExplicitNullableParamTypeRector::class])->withPhpVersion(PhpVersion::PHP_84). Zapis ?User, który wstawia ta reguła, działa na PHP 7.1 i nowszych. Ograniczenie podnieś do ^8.4 w dniu przełączenia i dopiero wtedy uruchom cały zestaw php84. Za każdym razem zacznij od --dry-run i przejrzyj diff. W dużym projekcie diff jest długi i prawie cały jest poprawny.

PHPStan 2 przyjmuje zakres, phpVersion: {min: 80200, max: 80400}, i wtedy zgłasza sporą część tego, co zepsuje się na którejkolwiek z tych wersji. Dodaj 8.4 do macierzy CI obok 8.2, żeby do dnia przełączenia każda zmiana była testowana na obu.

Jednego narzędzia Ci nie dadzą: dowodu, że aplikacja nadal robi to, co robiła. Jeśli ścieżki, na których firma zarabia (logowanie, zamówienie, fakturowanie, nocny eksport), nie mają testów, napisz kilka, które utrwalą dzisiejsze zachowanie, zanim wymienisz pod nimi wersję PHP.

Jeśli nie zdążysz do 31 grudnia

To się zdarza i da się z tym rozsądnie poradzić, w tej kolejności:

  1. Jeśli korzystasz z paczek z dystrybucji, sprawdź, jak długo Twoja dystrybucja będzie łatać php8.2. Możesz mieć więcej czasu, niż wynika z php.net.
  2. Kup czas świadomie. Łatane buildy PHP od dostawców takich jak Freexian, TuxCare czy Zend albo Extended Support u hostingodawcy zapewniają dalsze poprawki samego interpretera. Nie łatają Twojego frameworka ani zależności z Composera, więc traktuj je jak pomost z datą końca.
  3. Zmniejsz ryzyko na czas prac. Wszystko inne trzymaj na bieżąco, uruchamiaj composer audit co tydzień jako zaplanowane zadanie w CI, wyłącz nieużywane rozszerzenia PHP i ustal datę przełączenia.

Kilka tygodni na 8.2 w styczniu to ryzyko, które da się kontrolować, jeśli data przełączenia jest ustalona i zapisana.

Plan na pozostałe tygodnie

Od końca października zostaje około dziewięciu tygodni, a w większości zespołów dwa ostatnie to święta i urlopy. Plan, który się w tym mieści: tydzień na kroki 1 i 2, tydzień na wybór wersji docelowej i aktualizację zależności, 2–3 tygodnie na zmiany w kodzie i testy, 1–2 tygodnie na stagingu, a potem przełączenie produkcji przed połową grudnia, z rozpisanym planem wycofania. Jeśli na liście z kroku 2 jest aktualizacja frameworka, załóż, że przełączenie przesunie się na pierwszy kwartał, i już teraz przygotuj pomost.

Jeśli chcesz, żeby ktoś jeszcze spojrzał na tę listę, wyślij nam swój composer.lock. Odpowiemy z datami wsparcia Twojej wersji PHP i frameworka oraz z liczbą znanych podatności i porzuconych paczek, które widać w tym pliku. Bezpłatnie i bez dostępu do kodu. Jeśli potrzebujesz pełnego obrazu, Debt Check (1300 zł) dokłada krótką ankietę, a raport dostajesz w ciągu trzech dni roboczych: ryzyka według priorytetu, to, co blokuje przejście na wspieraną wersję, i rekomendowaną ścieżkę z widełkami cenowymi. Na jego podstawie przejęcie aplikacji albo opiekę (Care) często da się od razu wycenić stałą ceną. Aktualizację wyceniamy stałą ceną po audycie kodu (Code Audit).

Źródła

Sprawdzone 25 października 2026.

Chcesz, żeby ktoś jeszcze spojrzał na Twoją aplikację?

Wyślij nam swój composer.lock. Odpowiemy z datami wsparcia Twojej wersji PHP i frameworka oraz z liczbą znanych podatności i porzuconych paczek, które widać w tym pliku. Bezpłatnie i bez dostępu do kodu.

Wyślij nam composer.lock Zamów Debt Check