Strona nie działa po zmianie PHP – przyczyny i plan naprawy

Autor: Grzegorz Wojterzak. Aktualizacja: 12 października 2026. Czas czytania: około 12 minut.

Ta awaria ma charakterystyczny przebieg. Strona działała latami, nikt nic nie zmieniał, a jednego dnia pokazuje błąd krytyczny. Po kilku telefonach okazuje się, że hosting przełączył konta na nowszą wersję PHP, o czym uprzedzał mailem kilka tygodni wcześniej. Albo właściciel sam zmienił wersję, bo panel WordPressa wyświetlał ostrzeżenie o przestarzałym PHP.

W obu przypadkach strona nie jest zepsuta na zawsze. Jej kod po prostu nie pasuje do nowej wersji języka, w którym jest napisana.

Dlaczego hostingi wymuszają zmianę wersji PHP

PHP, tak jak każde oprogramowanie, ma ograniczony czas wsparcia. Każda wersja przez dwa lata dostaje poprawki błędów, a potem jeszcze przez dwa lata tylko poprawki bezpieczeństwa. Po tym czasie nikt nie łata w niej luk. Hosting, który trzyma tysiące stron na starym PHP, ryzykuje bezpieczeństwo całych serwerów, dlatego co jakiś czas wycofuje stare wersje.

Stan na 12 października 2026 roku według tabeli wspieranych wersji na php.net:

WordPress na stronie z wymaganiami zaleca PHP w wersji 8.3 lub nowszej. Rdzeń WordPressa działa na nowych wersjach PHP poprawnie. Problemem są dodatki: wtyczki i motywy, które nie były aktualizowane od lat, oraz kod pisany na zamówienie.

Co się psuje przy przejściu z PHP 7.4 na 8.x

Najwięcej awarii zdarza się przy przeskoku z gałęzi 7 na 8. PHP 8.0 usunął część starych funkcji i zamienił wiele dawnych ostrzeżeń na błędy, które zatrzymują wykonanie kodu. Poniżej przykłady, które najczęściej widuję w logach. Treść komunikatów sprawdziłem na PHP 8.3, a opisy zmian pochodzą z oficjalnych przewodników migracji na php.net: zmiany niekompatybilne w PHP 8.0, przestarzałe elementy w PHP 8.1 i w PHP 8.2.

Jest jeszcze jedna zmiana, która potrafi wyglądać jak awaria: od PHP 8.0 domyślny poziom raportowania błędów obejmuje wszystkie komunikaty, także te, które wcześniej były ukryte. Jeśli serwer ma włączone wyświetlanie błędów, ostrzeżenia mogą pojawić się na stronie jako tekst nad nagłówkiem albo rozbić odpowiedzi formularzy. Na stronie produkcyjnej wyświetlanie błędów powinno być wyłączone, a błędy zapisywane do logu.

Szybki powrót do poprzedniej wersji PHP

Gdy strona leży, najpierw przywróć jej działanie, a dopiero potem szukaj przyczyny. Jeśli hosting nadal oferuje poprzednią wersję PHP, powrót trwa kilka minut.

1. Znajdź w panelu hostingu ustawienia PHP

   Każdy hosting nazywa to miejsce inaczej, ale zawsze jest to część ustawień domeny, strony lub konta. Szukaj wyboru wersji PHP przy konkretnej domenie albo w ustawieniach całego konta. Na wielu hostingach wersję PHP można ustawić osobno dla każdej strony, więc upewnij się, że zmieniasz ją dla właściwej domeny.

   

2. Wybierz wersję, na której strona działała

   Jeśli nie wiesz, która to była, sprawdź mail od hostingu o zmianie wersji albo zapytaj pomoc techniczną. Zapisz zmianę i odczekaj chwilę, bo na części serwerów zmiana wersji nie działa natychmiast.

3. Sprawdź stronę i zanotuj termin

   Otwórz stronę w oknie prywatnym. Jeśli działa, masz czas na przygotowanie. Dowiedz się od hostingu, jak długo stara wersja będzie dostępna. Ten termin to Twój termin na naprawę.

Wersję PHP, na której faktycznie działa strona, sprawdzisz w WordPressie w Narzędzia, Zdrowie witryny, zakładka Informacje, sekcja Serwer. Panel Zdrowia witryny ostrzega też, gdy wersja PHP jest przestarzała.

Jak znaleźć winny dodatek

Kolejność postępowania ilustruje drzewo poniżej. Kluczowe jest rozróżnienie: czy strona stoi teraz, czy przygotowujesz ją do zmiany, która dopiero nastąpi.

1. Włącz zapis błędów

   W pliku wp-config.php, powyżej komentarza „stop editing”, zamień linię z WP_DEBUG na:

   define( 'WP_DEBUG', true );
   define( 'WP_DEBUG_LOG', true );
   define( 'WP_DEBUG_DISPLAY', false );
   @ini_set( 'display_errors', 0 );

   Jeśli strona działa już na starym PHP, rób to na kopii strony z nową wersją PHP, nie na stronie produkcyjnej.

2. Odczytaj ścieżkę z linii Fatal error

   Otwórz wp-content/debug.log i znajdź na końcu linię PHP Fatal error. Fragment ścieżki po wp-content/plugins/ lub wp-content/themes/ to nazwa winnego dodatku. Szczegółowy opis budowy tej linii znajdziesz w artykule o błędzie krytycznym WordPress.

3. Wyłącz dodatek i powtórz

   Zmień nazwę katalogu wtyczki (np. dopisując .off) albo wyłącz ją przez WP-CLI: wp plugin deactivate nazwa --skip-plugins --skip-themes. Odśwież stronę. Często po wyłączeniu jednej wtyczki ujawnia się kolejna, więc powtarzaj, aż strona zadziała, i notuj wszystkie nazwy.

4. Zdecyduj o każdym dodatku z listy

   Sprawdź, czy jest nowsza wersja i czy autor deklaruje zgodność z nowym PHP. Na stronach wtyczek w katalogu wordpress.org widać datę ostatniej aktualizacji i minimalną wersję PHP. Wtyczka bez aktualizacji od kilku lat najpewniej nie zostanie już poprawiona.

Sprawdzenie kodu przed zmianą: PHP Compatibility

Jeśli masz dostęp do SSH lub możesz pobrać kopię strony na komputer, sprawdź kod automatycznie, zanim zmienisz wersję PHP. Służy do tego zestaw reguł PHPCompatibilityWP dla narzędzia PHP_CodeSniffer, przygotowany z myślą o WordPressie. Instaluje się go przez Composer, a uruchamia na katalogu z wtyczkami i motywami:

# instalacja w osobnym katalogu roboczym
composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev phpcompatibility/phpcompatibility-wp:"*"

# sprawdzenie zgodności z PHP 8.3 i nowszymi
vendor/bin/phpcs -p ścieżka/do/wp-content --standard=PHPCompatibilityWP --extensions=php --runtime-set testVersion 8.3-

Narzędzie analizuje kod bez uruchamiania go, więc nie wyłapie wszystkiego. Dobrze znajduje usunięte funkcje i przestarzałe konstrukcje, gorzej problemy z typami danych, które wychodzą dopiero w działaniu. Dlatego wynik traktuj jako listę podejrzanych, a ostateczny test rób na kopii strony.

Plan migracji na PHP 8.3 lub nowsze

Najlepiej przygotować stronę, zanim hosting zmieni wersję za Ciebie. Biorąc pod uwagę, że PHP 8.2 traci wsparcie 31 grudnia 2026 roku, a 8.1 i starsze już go nie mają, wiele stron czeka ta zmiana w najbliższych miesiącach. Plan, który stosuję:

1. Inwentaryzacja

   Sprawdź obecną wersję PHP (Zdrowie witryny) i zrób listę wtyczek i motywów z wersjami: wp plugin list --fields=name,status,version,update. Datę ostatniej aktualizacji każdej wtyczki sprawdź na jej stronie w katalogu wordpress.org. Zaznacz te bez aktualizacji od ponad roku i te z płatnych źródeł.

2. Aktualizacja na obecnym PHP

   Zaktualizuj WordPressa, wtyczki i motyw, jeszcze na starej wersji PHP. Nowe wersje dodatków zwykle zawierają poprawki zgodności. Zrób to z kopią zapasową, zgodnie z procedurą z artykułu Strona nie działa po aktualizacji.

3. Kopia testowa z nowym PHP

   Postaw kopię strony (staging) i ustaw na niej docelową wersję PHP. Włącz log błędów. Przejdź wszystkie ważne ścieżki: strona główna, podstrony, formularze, koszyk i zamówienie, logowanie i panel.

4. Wymiana i poprawki

   Dodatki, które zgłaszają Fatal error i nie mają nowszych wersji, wymień na rozwijane odpowiedniki. Kod na zamówienie, w tym functions.php motywu potomnego, popraw zgodnie z komunikatami z logu.

5. Przełączenie strony

   Zmień wersję PHP na stronie produkcyjnej w godzinach małego ruchu, z kopią zrobioną tuż przed zmianą. Sprawdź stronę jako gość i przez kilka dni przeglądaj log. Gdy wszystko działa, wyłącz debugowanie i usuń debug.log.

Jeśli wszystkie dodatki deklarują zgodność z PHP 8.4, wybierz 8.4, bo ma wsparcie bezpieczeństwa do końca 2028 roku. PHP 8.3 jest bezpiecznym wyborem do końca 2027 roku i ma najszersze wsparcie wśród starszych wtyczek.

Kiedy nie robić tego samemu

Powrót do starego PHP i znalezienie winnej wtyczki zrobisz samodzielnie. Pomoc programisty przyda się, gdy:

• błędy są w motywie lub kodzie pisanym na zamówienie, a nie ma kto go poprawić,
• stara wersja PHP nie jest już dostępna, a strona musi działać od zaraz,
• strona używa porzuconych dodatków, których nie da się po prostu wymienić, bo na nich opiera się sklep lub ważna funkcja,
• PHP Compatibility zwraca setki błędów i nie wiesz, od czego zacząć.

Proste przypadki z jedną winną wtyczką mieszczą się w Szybkiej Interwencji. Migracja strony z dużą ilością własnego kodu jest wyceniana indywidualnie, przed rozpoczęciem prac. Więcej o tym, od czego zależy koszt, w artykule Ile kosztuje naprawa strony internetowej.

Najczęstsze pytania