Jak zmienić wersję PHP na hostingu bez problemów z WordPressem

Zmiana wersji PHP na hostingu zwykle zajmuje w panelu kilka kliknięć. Ryzyko nie leży jednak w samym przełączniku, lecz w tym, czy używany WordPress, motyw, wtyczki i własny kod są zgodne z nowym interpreterem.

Dlatego bezpieczna aktualizacja PHP nie powinna zaczynać się od wyboru najwyższej dostępnej wersji. Najpierw trzeba sprawdzić obecne środowisko, przygotować możliwość powrotu, zaktualizować aplikację i dopiero wtedy wykonać zmianę oraz przetestować najważniejsze funkcje strony.

Zmiana PHP jest zmianą środowiska wykonawczego strony. Backup jest ważny, ale równie istotna jest możliwość szybkiego przywrócenia poprzedniej wersji PHP, jeśli po przełączeniu strona przestanie działać.

Jakie wersje PHP są obecnie wspierane?

We wrześniu 2026 r. projekt PHP utrzymuje gałęzie 8.2, 8.3, 8.4 i 8.5. Nie wszystkie znajdują się jednak na tym samym etapie cyklu życia.

Wersja PHP	Status we wrześniu 2026 r.	Wsparcie bezpieczeństwa do
PHP 8.2	Tylko poprawki bezpieczeństwa	31.12.2026
PHP 8.3	Tylko poprawki bezpieczeństwa	31.12.2027
PHP 8.4	Aktywne wsparcie	31.12.2028
PHP 8.5	Aktywne wsparcie	31.12.2029

Sam fakt, że hosting nadal pozwala wybrać starszą wersję PHP, nie oznacza więc, że warto na niej pozostawać. Operator może utrzymywać starsze środowisko dla zgodności ze starymi aplikacjami, mimo że dana gałąź PHP zakończyła już aktywne wsparcie albo zbliża się do końca poprawek bezpieczeństwa.

Aktualne daty należy sprawdzać na stronie projektu PHP, ponieważ cykl wsparcia jest związany z konkretną gałęzią i zmienia się wraz z kolejnymi wydaniami.

Jaką wersję PHP wybrać dla WordPressa?

WordPress rekomenduje obecnie PHP 8.3 lub nowsze. Aktualna tabela zgodności dokumentuje obsługę PHP 8.5 w WordPressie 6.9 i nowszych oraz PHP 8.4 w WordPressie 6.7 i nowszych.

Nie oznacza to jednak, że każda istniejąca strona WordPress może zostać bez testów przełączona na najwyższą wersję dostępną w panelu.

WordPress to nie tylko jego rdzeń. Instalacja może zawierać:

motyw,
kilkanaście lub kilkadziesiąt wtyczek,
własne fragmenty PHP,
integracje sklepu, płatności i wysyłki,
kod zapisany w motywie potomnym,
starsze biblioteki dostarczane przez rozszerzenia.

Każdy z tych elementów może mieć własne wymagania dotyczące PHP. Dlatego zgodność rdzenia WordPressa z PHP 8.5 nie jest automatycznie potwierdzeniem zgodności całej strony.

Czy zawsze warto wybierać najnowsze PHP?

Docelowo warto korzystać ze wspieranej wersji PHP, ale „najnowsza dostępna” i „najlepsza do natychmiastowego przełączenia konkretnej strony” nie zawsze oznaczają to samo.

Jeżeli wszystkie komponenty obsługują nowszą wspieraną wersję PHP, zwykle nie ma powodu pozostawać na starszej tylko z przyzwyczajenia. Nowsze wydania otrzymują poprawki i rozwój, podczas gdy wersje po zakończeniu wsparcia nie dostają już standardowych aktualizacji bezpieczeństwa.

Z drugiej strony produkcyjnego sklepu lub rozbudowanej strony nie warto przełączać bez sprawdzenia tylko po to, aby numer wersji był najwyższy. Najpierw należy potwierdzić zgodność używanego oprogramowania.

Jak sprawdzić obecną wersję PHP w WordPressie?

W WordPressie można zacząć od:

Narzędzia → Stan witryny → Informacje → Serwer.

Znajdziesz tam wersję PHP używaną przez działającą stronę. To lepszy punkt odniesienia niż wynik polecenia uruchomionego bezpośrednio w SSH.

Przykładowo:

php -v

pokazuje wersję PHP uruchamianego w CLI. Hosting może jednak używać dla strony WWW innej wersji przez PHP-FPM lub inny handler. Dlatego wynik z terminala nie musi odpowiadać wersji obsługującej żądania WordPressa.

Ten sam problem dotyczy konfiguracji limitów PHP. Szerzej opisaliśmy to w poradniku o limitach PHP na hostingu.

Co zrobić przed zmianą wersji PHP?

Najbezpieczniejsza procedura składa się z kilku niezależnych kroków. Każdy zmniejsza inne ryzyko.

1. Sprawdź, czy masz możliwość powrotu

Zanim zmienisz PHP, sprawdź w panelu hostingu, czy poprzednia wersja nadal będzie dostępna po przełączeniu.

To istotne, ponieważ w przypadku błędu najszybszym rollbackiem często nie jest odtwarzanie całej strony z backupu, ale ponowne ustawienie poprzedniej wersji interpretera.

Jeżeli operator usuwa starą wersję z serwera i zmiana jest jednokierunkowa, procedurę trzeba potraktować ostrożniej.

2. Wykonaj kopię zapasową

Backup powinien obejmować co najmniej pliki strony i bazę danych. Sama zmiana PHP normalnie ich nie modyfikuje, ale podczas rozwiązywania problemów mogą być potrzebne dodatkowe aktualizacje, zmiany wtyczek albo korekty konfiguracji.

Kopia jest więc zabezpieczeniem całej procedury, a nie tylko samego kliknięcia „zmień PHP”.

3. Zaktualizuj WordPress, motyw i wtyczki

Stary plugin może zawierać kod napisany dla wcześniejszej wersji PHP, mimo że jego obecne wydanie zostało już dostosowane do PHP 8.x.

Przed testem nowego PHP warto więc najpierw doprowadzić aktywnie używane komponenty do aktualnych, wspieranych wersji — oczywiście po wykonaniu backupu i zgodnie z normalną procedurą aktualizacji strony.

4. Sprawdź wymagania najważniejszych rozszerzeń

Szczególną uwagę warto poświęcić komponentom krytycznym dla działania strony:

WooCommerce,
bramkom płatniczym,
integracjom wysyłkowym,
systemom rezerwacji,
formularzom,
wtyczkom bezpieczeństwa,
własnym integracjom API.

Brak deklaracji zgodności nie musi automatycznie oznaczać, że rozszerzenie nie zadziała. Oznacza jednak, że przed zmianą na produkcji warto wykonać realny test.

Najlepiej testować zmianę PHP na stagingu

Jeżeli hosting zapewnia staging, jest to naturalne miejsce do pierwszego przełączenia wersji PHP.

Kopia strony powinna możliwie dobrze odzwierciedlać produkcję: tę samą wersję WordPressa, motyw, wtyczki i konfigurację aplikacji. Sam pusty WordPress z tym samym motywem nie sprawdzi zgodności wszystkich elementów rzeczywistej strony.

Po zmianie PHP na stagingu nie wystarczy zobaczyć, czy otwiera się strona główna. Trzeba przetestować funkcje zależne od kodu PHP.

Jeżeli chcesz ocenić staging jako funkcję konkretnego pakietu hostingowego, zobacz poradnik Staging WordPress na hostingu — kiedy naprawdę się przydaje?.

Co sprawdzić po zmianie PHP?

Zakres testu zależy od strony, ale dobra lista kontrolna obejmuje co najmniej:

stronę główną,
kilka typów podstron i wpisów,
logowanie do WordPressa,
edycję i zapis treści,
upload pliku lub obrazu,
formularz kontaktowy,
wysyłkę poczty,
zadania cron,
cache,
operacje wykonywane przez najważniejsze wtyczki.

Dla WooCommerce dodatkowo warto przejść przez:

kartę produktu,
dodanie produktu do koszyka,
koszyk,
checkout,
wybraną metodę płatności w trybie testowym, jeśli jest dostępny,
e-maile transakcyjne,
panel zamówień.

Nie chodzi o wykonanie prawdziwej płatności na produkcji. Celem jest sprawdzenie tych fragmentów aplikacji, które wykonują więcej logiki niż zwykłe wyświetlenie strony.

Gdzie szukać błędów po zmianie wersji PHP?

Jeżeli po przełączeniu pojawia się biały ekran, HTTP 500 albo komunikat o krytycznym błędzie WordPressa, pierwszym krokiem powinny być logi.

Przydatne mogą być:

log błędów PHP dostępny w panelu hostingu,
log PHP-FPM, jeśli operator go udostępnia,
log serwera WWW,
WordPress debug.log w kontrolowanych warunkach diagnostycznych.

Sam kod HTTP 500 nie wskazuje, która wtyczka lub funkcja jest niezgodna. Log zwykle pozwala zawęzić problem do konkretnego pliku, funkcji albo typu błędu.

Nie należy natomiast pozostawiać publicznego wyświetlania szczegółowych błędów PHP na produkcji. Mogą ujawniać ścieżki i informacje o konfiguracji serwera.

Jakie problemy mogą ujawnić się po aktualizacji PHP?

Zmiana wersji PHP może ujawnić kilka rodzajów problemów.

Usunięta lub zmieniona funkcja

Kod może używać elementu języka albo API, które w nowszej gałęzi PHP zostało zmienione lub usunięte. Szczególnej ostrożności wymagają duże skoki ze starych wersji, na przykład z PHP 7.x do PHP 8.x.

Nowe ostrzeżenia i deprecations

PHP rozwija się również przez stopniowe oznaczanie starych konstrukcji jako przestarzałe. Kod może nadal działać, ale generować ostrzeżenia wskazujące, że przed kolejnym dużym wydaniem wymaga poprawy.

PHP 8.5 również wprowadza nowe deprecations i kilka zmian niezgodnych wstecz, dlatego projekt PHP zaleca sprawdzenie przewodnika migracyjnego przed przełączeniem środowiska produkcyjnego.

Niezgodność rozszerzenia PHP

Aplikacja może wymagać konkretnego rozszerzenia PHP, na przykład obsługi wybranego formatu, bazy danych albo biblioteki. Po zmianie wersji należy więc sprawdzić nie tylko numer PHP, ale również dostępne moduły.

Problem ze starym własnym kodem

Najtrudniejsze bywają fragmenty napisane specjalnie dla danej strony kilka lat wcześniej. Nie mają własnej strony w repozytorium WordPressa ani informacji o zgodności, więc wymagają testu lub przeglądu kodu.

Czy przeskakiwać od razu o kilka wersji PHP?

Z punktu widzenia samego celu końcowego nie ma obowiązku pozostawiania produkcji przez kilka tygodni na każdej pośredniej wersji PHP. Ważniejsze jest sprawdzenie zmian niezgodnych wstecz między wersją początkową a docelową i przetestowanie aplikacji.

Przy bardzo starej stronie przejście etapami może jednak ułatwić diagnostykę. Jeśli aplikacja działa na PHP 7.4, a nie działa na 8.4, sprawdzanie kolejnych etapów może pomóc ustalić, przy której rodzinie zmian pojawia się problem.

Nie oznacza to, że stara, niewspierana wersja powinna pozostać długoterminowym rozwiązaniem. Etapy są narzędziem diagnostycznym, nie celem samym w sobie.

Co zrobić, gdy strona przestaje działać?

Jeżeli problem pojawił się bezpośrednio po zmianie PHP, najpierw przywróć poprzednią działającą wersję, o ile hosting nadal ją udostępnia.

Potem można spokojnie:

sprawdzić log błędu,
zidentyfikować komponent powodujący problem,
sprawdzić jego aktualizację i wymagania,
naprawić albo zastąpić niezgodny komponent,
ponowić test na stagingu,
dopiero później przełączyć produkcję.

Nie warto utrzymywać niedziałającej strony na nowym PHP podczas eksperymentowania bezpośrednio na produkcji, jeśli prosty rollback wersji przywraca działanie.

Czy przywrócenie starszego PHP wystarczy jako rollback?

Jeżeli jedyną zmianą było ustawienie wersji interpretera, często tak. Trzeba jednak uważać, jeśli równocześnie zaktualizowano WordPress, motyw, wtyczki lub zmieniono konfigurację aplikacji.

Wtedy powrót samego PHP może nie odtworzyć wcześniejszego stanu całego środowiska.

Dlatego dobrze rozdzielać operacje. Jeżeli to możliwe, najpierw aktualizuj aplikację i sprawdź ją na obecnym PHP, a zmianę interpretera wykonuj jako osobny krok. Łatwiej wtedy ustalić, która zmiana odpowiada za problem.

Czy zmiana PHP może przyspieszyć WordPressa?

Nowsze wersje PHP mogą zawierać usprawnienia wydajnościowe, ale sama zmiana numeru interpretera nie powinna być traktowana jako uniwersalny sposób naprawy wolnej strony. Po zmianie wersji warto także sprawdzić konfigurację OPcache, ponieważ dotyczy ona sposobu przechowywania skompilowanego kodu PHP.

Jeśli wąskim gardłem jest wolne zapytanie SQL, zewnętrzne API, brak cache, przeciążone CPU albo duża liczba procesów, zmiana PHP może nie usunąć głównej przyczyny.

Po aktualizacji warto więc oceniać stronę normalnie: przez czas odpowiedzi, logi, wykorzystanie zasobów i konkretne operacje, a nie tylko przez numer PHP.

Jeżeli problemem jest ogólna wydajność WordPressa, zobacz również poradnik Dlaczego WordPress działa wolno — hosting czy sama strona?.

Jak ocenić obsługę PHP przed zakupem hostingu?

Informacja „obsługujemy PHP 8” jest zbyt ogólna. Przy wyborze hostingu bardziej praktyczne są pytania:

jakie aktualnie wspierane wersje PHP można wybrać,
czy wersję można zmienić samodzielnie,
czy można ustawić inną wersję dla każdej domeny,
jak długo operator utrzymuje starsze wersje potrzebne do rollbacku,
czy dostępny jest staging,
czy panel pokazuje konfigurację i logi błędów PHP,
czy użytkownik może zmieniać podstawowe limity PHP.

Możliwość wybrania bardzo starej wersji nie jest zaletą sama w sobie. Przydaje się przede wszystkim jako rozwiązanie przejściowe podczas migracji starego projektu albo rollbacku, podczas gdy docelowo aplikacja powinna działać na wspieranym środowisku.

Jeżeli masz już konkretną ofertę, możesz przejść przez audyt planu przed zakupem. Brak informacji o sposobie zarządzania PHP warto potraktować jako pytanie do operatora, a nie jako automatyczne potwierdzenie elastycznej konfiguracji.

Bezpieczna zmiana PHP — krótka checklista

Sprawdź aktualną wersję PHP używaną przez stronę WWW.
Ustal wersję docelową i jej status wsparcia.
Sprawdź możliwość szybkiego powrotu do poprzedniej wersji.
Wykonaj backup plików i bazy.
Zaktualizuj WordPress, motyw i aktywne wtyczki.
Sprawdź wymagania krytycznych rozszerzeń i własnego kodu.
Jeśli możesz, najpierw zmień PHP na stagingu.
Przetestuj funkcje strony, nie tylko homepage.
Sprawdź logi pod kątem błędów i nowych ostrzeżeń.
Dopiero potem przełącz produkcję.
Po zmianie ponownie wykonaj test funkcjonalny.

Najważniejsze wnioski

wersję PHP należy oceniać nie tylko po numerze, ale także po statusie wsparcia;
WordPress rekomenduje obecnie PHP 8.3 lub nowsze;
aktualna tabela zgodności dokumentuje PHP 8.5 dla WordPressa 6.9+ i PHP 8.4 dla WordPressa 6.7+;
zgodność rdzenia WordPressa nie gwarantuje zgodności wszystkich wtyczek, motywu i własnego kodu;
przed zmianą warto przygotować zarówno backup, jak i możliwość szybkiego powrotu do poprzedniej wersji PHP;
najbezpieczniej testować zmianę na środowisku stagingowym;
po przełączeniu trzeba sprawdzić funkcje aplikacji i logi, a nie tylko stronę główną;
wynik php -v przez SSH może dotyczyć innego PHP niż to obsługujące WWW;
bardzo stara wersja PHP może być przydatna jako tymczasowy rollback, ale nie powinna pozostawać długoterminowym rozwiązaniem po zakończeniu wsparcia.

Źródła

PHP — Supported Versions — aktualny cykl aktywnego i bezpieczeństwa dla poszczególnych gałęzi PHP.
PHP Manual — Migrating from PHP 8.4.x to PHP 8.5.x — zmiany, niezgodności i deprecations w PHP 8.5.
PHP 8.5 Release — informacje o PHP 8.5 i zmianach zgodności.
WordPress.org — Requirements — rekomendowana wersja PHP dla WordPressa.
Make WordPress Core — PHP Compatibility and WordPress Versions — tabela zgodności wersji WordPressa z PHP 8.4 i 8.5.
WordPress Documentation — Update PHP — backup, aktualizacje komponentów, testowanie zgodności i zmiana PHP u operatora.
WordPress Documentation — Site Health screen — sprawdzanie wersji PHP i informacji o środowisku.