PHP 8.2 traci wsparcie 31 grudnia. Jaka wersja PHP dla WordPressa na 2027

W skrócie

Trzydziestego pierwszego grudnia 2026 PHP 8.2 dostaje ostatnią łatkę bezpieczeństwa. PHP 8.1 nie dostaje ich już od grudnia 2025. Jeśli Twoja strona działa na którejś z tych wersji, wchodzisz w 2027 z oprogramowaniem, w którym nowe dziury nie będą już łatane, a WordPress.org od wydania 7.0 oficjalnie rekomenduje PHP 8.3 lub nowsze. Rozsądny wybór na dziś to PHP 8.4, wspierane do końca 2028 i zgodne z całym aktualnym ekosystemem wtyczek. Do tego 19 listopada wychodzi PHP 8.6, o którym piszemy niżej, ale na produkcję jeszcze go nie bierz. Reszta artykułu to tabela dat, które warto znać, procedura sprawdzenia własnej wersji i bezpieczna ścieżka zmiany.

Terminarz, który powinien wisieć nad biurkiem

PHP ma prosty cykl życia: każda wersja dostaje dwa lata aktywnego wsparcia i dwa lata samych łatek bezpieczeństwa. Potem koniec, bez wyjątków i bez przedłużeń.

Wersja	Wydana	Koniec łatek bezpieczeństwa	Status we wrześniu 2026
PHP 8.1	listopad 2021	31 grudnia 2025	martwa, bez łatek od grudnia 2025
PHP 8.2	grudzień 2022	31 grudnia 2026	ostatnie tygodnie wsparcia
PHP 8.3	listopad 2023	31 grudnia 2027	tylko łatki bezpieczeństwa
PHP 8.4	listopad 2024	31 grudnia 2028	pełne wsparcie, rekomendowana
PHP 8.5	listopad 2025	31 grudnia 2029	pełne wsparcie, młoda
PHP 8.6	19 listopada 2026	31 grudnia 2030	RC od 24 września, jeszcze nie na produkcję

Ta tabela wystarczy, żeby podjąć decyzję. Wszystko poniżej PHP 8.3 to dług techniczny z odsetkami.

Co naprawdę grozi stronie na starym PHP

Nie chodzi o to, że strona przestanie działać 1 stycznia. Będzie działać. Problem jest gdzie indziej i narasta po cichu.

Dziury bez łatek. Gdy po EOL ktoś znajdzie podatność w interpreterze PHP, poprawka wyjdzie dla 8.3, 8.4 i 8.5. Dla 8.2 nie wyjdzie nigdy. Boty skanujące internet w poszukiwaniu starych wersji wiedzą o tym szybciej niż Ty. W praktyce strona na porzuconym PHP jest tania w ataku, a przy sklepie z danymi klientów robi się z tego temat z kategorii RODO, nie tylko techniczny.

WordPress rekomenduje nowsze wersje, a ekosystem idzie za rekomendacją. Oficjalne wymagania WordPress.org wskazują PHP 8.3 lub nowsze jako wersję rekomendowaną. Core technicznie odpali się jeszcze na starszym PHP, ale rekomendacja wyznacza, na czym autorzy core i wtyczek naprawdę testują swój kod. Historycznie WordPress podnosi minimalną wersję stopniowo i zawsze wypadają najstarsze, więc siedząc na 8.1 albo 8.2 stoisz pierwszy w kolejce do odcięcia. O samym wydaniu 7.0 pisaliśmy w osobnym tekście, a w grudniu wychodzi WordPress 7.2, dystans będzie rósł z każdym wydaniem.

Wtyczki uciekają do przodu. WooCommerce, Elementor i większość poważnych wtyczek testuje nowe wydania na wersjach PHP, które mają wsparcie. Autorzy porzucają zgodność ze starymi wersjami bez rozgłosu, zwykle jedną linijką w changelogu. Na starym PHP każda aktualizacja wtyczki to loteria.

Wydajność zostaje na stole. Każde wydanie od PHP 8.0 w górę przynosi realne przyspieszenie interpretera i JIT. Migracja z 8.1 na 8.4 na typowej stronie WooCommerce to zwykle kilkanaście procent szybszego TTFB za darmo, bez zmiany ani linijki kodu. Jeśli walczysz z wolną stroną, zacznij od diagnozy przyczyn, ale wersję PHP i tak podbij.

Którą wersję wybrać na 2027

PHP 8.4 to najlepszy wybór dla większości stron. Ma pełne wsparcie do końca 2028, prawie dwa lata dojrzewania w ekosystemie i cały liczący się rynek wtyczek deklaruje z nim zgodność. To wersja, którą ustawiamy domyślnie klientom opieki serwisowej.

PHP 8.3 to dopuszczalne minimum. Jeśli któraś wtyczka albo stary motyw nie przechodzi na 8.4, zejście na 8.3 kupuje Ci czas do końca 2027. Traktuj to jako przystanek, nie cel.

PHP 8.5 działa dobrze, ale niczego nie musisz. Rok na rynku, stabilne, szybkie. Jeśli Twój hosting je oferuje i wtyczki są zgodne, śmiało. Przewagi nad 8.4 z perspektywy zwykłej strony firmowej są kosmetyczne.

PHP 8.6 zostaw na później. Wersja RC pojawia się 24 września, finalna 19 listopada 2026. Nowości są ciekawe dla programistów: częściowa aplikacja funkcji, wbudowana funkcja clamp() do ograniczania wartości, natywne API do pollingu. Dla właściciela strony na WordPressie znaczenie ma co innego: pierwsze tygodnie po premierze to czas, w którym autorzy wtyczek dopiero łatają zgodność. Sensowny moment na 8.6 to wiosna 2027.

Jak sprawdzić, na czym jedzie Twoja strona

Trzy sposoby, od najprostszego.

W kokpicie WordPressa wejdź w Narzędzia -> Stan witryny -> Informacje -> Serwer. Pozycja Wersja PHP mówi wszystko.

Przez WP-CLI:

wp cli info | grep "PHP version"

Na hostingu mDiv wersję widzisz i zmieniasz w panelu, sekcja Witryny -> [domena] -> PHP. Dropdown pokazuje dostępne wersje od 7.4 do 8.4, zmiana przeładowuje php-fpm automatycznie i wchodzi w życie w mniej niż minutę.

Jak podbić wersję i nie wywalić strony

Procedura jest krótka, ale kolejność ma znaczenie.

Krok 1, backup. Pełna kopia plików i bazy przed jakąkolwiek zmianą. Na hostingu z codziennym backupem i tak ją masz, ale kopia na żądanie tuż przed zmianą to 2 minuty, które potrafią uratować wieczór.

Krok 2, spis podejrzanych. Wypisz aktywne wtyczki i wyłap te, które już dziś sypią ostrzeżeniami:

wp plugin list --status=active --format=csv > active-plugins.csv
tail -n 50 wp-content/debug.log | grep -i "deprecated"

Wtyczki z komunikatami Deprecated: Creation of dynamic property albo bez aktualizacji od dwóch lat to kandydaci do problemów. Sprawdź, czy mają nowsze wydania, zanim ruszysz wersję PHP.

Krok 3, staging. Jeśli masz środowisko testowe, podbij wersję najpierw tam i przeklikaj krytyczne ścieżki: strona główna, formularz kontaktowy, a w sklepie koszyk i płatność. Na hostingu mDiv staging dostajesz na życzenie.

Krok 4, zmiana na produkcji. Najlepiej rano w dzień roboczy, nie w piątek wieczorem. Po zmianie od razu sprawdź te same ścieżki co na stagingu i zerknij w debug.log.

Krok 5, plan odwrotu. Jeśli coś się sypie, wracasz dropdownem na poprzednią wersję i strona działa jak wcześniej. Zmiana wersji PHP jest w pełni odwracalna, dlatego to najbezpieczniejsza duża aktualizacja, jaką możesz zrobić.

Całość na typowej stronie firmowej zajmuje kwadrans. Na sklepie z dwudziestoma wtyczkami licz godzinę z testami.

Nie chcesz tego robić sam

To dokładnie ten rodzaj pracy, który zdejmujemy z głowy w ramach opieki serwisowej: testujemy zgodność wtyczek, podbijamy wersję na stagingu, potem na produkcji, i pilnujemy logów po zmianie. A jeśli Twój obecny hosting oferuje tylko PHP 8.1 albo każe dopłacać za nowsze wersje, migracja do mDiv jest darmowa i zawiera przeniesienie strony razem z ustawieniem właściwej wersji PHP.

Stary interpreter nie zepsuje Ci strony jutro. Ale różnica między stroną, która dostaje łatki, a stroną, która ich nie dostaje, ujawnia się zawsze w najgorszym możliwym momencie. Grudniowy termin jest dobrym pretekstem, żeby zamknąć temat w kwadrans, zanim zrobi się z tego projekt.