Strona WordPress nie działa na PHP 8 – konflikty

Spis treści

Problemy z kompatybilnością WordPress i PHP 8

Po zmianie wersji PHP strona WordPress może wyświetlać błąd krytyczny, zwracać kod 500 albo przestać poprawnie obsługiwać formularz czy sklep. Nie oznacza to automatycznie, że winny jest sam WordPress: problem może leżeć we wtyczce, motywie, własnym kodzie lub konfiguracji serwera.

Jeśli awaria już wystąpiła, sprawdź pocztę administratora: WordPress może wysłać link do trybu odzyskiwania. Pozwala on zalogować się mimo niektórych błędów i wskazuje problematyczny dodatek. Wiadomość nie zawsze dotrze, a tryb nie wykryje każdej awarii.

Zapisz godzinę błędu i ostatnią zmianę, a następnie sprawdź log PHP w panelu hostingu. Nie publikuj pełnych logów: mogą zawierać ścieżki i dane użytkowników.

Główne zmiany w PHP 8 – co wpływa na WordPress

PHP 8.0 usunął między innymi funkcje each() i create_function() oraz obsługę __autoload(). Niektóre nieprawidłowe argumenty funkcji powodują teraz TypeError lub ValueError. Kolejne wersje 8.x także wprowadzają zmiany, dlatego zgodność z 8.0 nie gwarantuje zgodności z 8.4 czy 8.5.

Ostrzeżenie Deprecated oznacza funkcję lub sposób użycia przewidziany do wycofania; samo w sobie nie musi zatrzymać strony. Błąd krytyczny może przerwać żądanie. Konkretne różnice opisuje przewodnik migracji PHP 8.0.

Sprawdzenie kompatybilności – wersja WordPress i wtyczek

  1. W panelu WordPress wybierz Narzędzia → Zdrowie witryny → Informacje → Serwer albo sprawdź wersję PHP przypisaną domenie w panelu hostingu. Wersja w terminalu może być inna niż wersja obsługująca stronę.
  2. Porównaj wersję WordPress i docelową wersję PHP z tabelą zgodności WordPress. Dotyczy ona rdzenia, nie gwarantuje działania dodatków.
  3. Sprawdź dokumentację i listy zmian producentów wtyczek oraz motywu. Data aktualizacji jest wskazówką, ale sama nie potwierdza zgodności.
  4. Wybierz wersję PHP z aktualnymi poprawkami bezpieczeństwa i sprawdź jej okres wsparcia. PHP 8.0 i 8.1 nie są już wspierane przez projekt PHP; dostawca może udostępniać własne poprawki.

Sprawdź również rozszerzenia i ustawienia PHP wymagane przez konkretną witrynę. Przy migracji na inne środowisko ich brak może dawać objawy podobne do konfliktu kodu.

Błędy deprecated functions – przestarzałe funkcje w PHP 8

Zacznij od aktualizacji wskazanego dodatku, sprawdzonej na kopii. Jeśli błąd dotyczy własnego kodu, przekaż programiście komunikat, ścieżkę i numer linii. Nie wykonuj globalnej zamiany nazw funkcji: pozorny zamiennik może działać inaczej.

Na stagingu można włączyć diagnostykę w wp-config.php, przed linią /* That's all, stop editing! Happy publishing. */. Jeśli stałe już istnieją, zmień ich wartości zamiast definiować je ponownie:

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

WordPress zapisuje wtedy log zwykle w wp-content/debug.log, o ile ma uprawnienia do zapisu. Taki plik może być publicznie dostępny i zawierać dane wrażliwe: ogranicz dostęp na serwerze albo użyj ścieżki poza webrootem. Na produkcji zacznij od logów hostingu; po diagnozie wyłącz tymczasowe logowanie i bezpiecznie usuń log zgodnie z polityką przechowywania danych. Dokumentacja debugowania WordPress opisuje ustawienia i ich ograniczenia.

Problemy z typowaniem strict – strict typing w PHP 8

Ścisłe typowanie nie zostało wprowadzone dopiero w PHP 8. Zmieniły się natomiast niektóre reguły i reakcje na błędne argumenty. Na przykład w PHP 8 porównanie 0 == 'tekst' daje false, a 0 == '0' nadal daje true.

Przy TypeError sprawdź w komunikacie oczekiwany i otrzymany typ, a następnie ustal, skąd pochodzi wartość. Waliduj dane przed konwersją; bezmyślne rzutowanie może ukryć błędne dane. Dodanie strict_types do istniejącego kodu nie jest uniwersalną naprawą.

Więcej o diagnozie znajdziesz w artykule Jak naprawić błędy po aktualizacji wersji PHP w WordPress.

Błędy we wtyczkach – identyfikacja niekompatybilnych rozszerzeń

Ścieżka w logu często wskazuje plik wtyczki, ale źródłem problemu może być także przekazana do niej wartość lub konflikt między dodatkami. Najpierw odtwórz problem na kopii testowej i sprawdź aktualizację wskazanego komponentu.

Jeśli panel nie działa, na stagingu możesz przez SFTP lub menedżer plików zmienić nazwę katalogu wskazanej wtyczki w wp-content/plugins i ponowić próbę. Przywróć nazwę po teście. Na produkcji wyłączanie dodatków może wyłączyć płatności, zabezpieczenia lub inne funkcje; rób to tylko ze świadomością skutków. Zmiana nazwy całego katalogu plugins może dezaktywować wszystkie zwykłe wtyczki i wymagać ich ponownej aktywacji. Nie obejmuje wtyczek mu-plugins ani wszystkich dodatków specjalnych.

Jeżeli aktualizacja nie rozwiązuje problemu, zgłoś go autorowi z wersjami WordPress, PHP i dodatku oraz oczyszczonym z danych fragmentem logu. Przed zamianą wtyczki sprawdź możliwość przeniesienia ustawień i danych.

Aktualizacja motywu – dostosowanie do PHP 8

Na kopii testowej przełącz się na zainstalowany motyw domyślny zgodny z wersją WordPress i sprawdź, czy błąd nadal występuje. Przełączenie zmienia wygląd i może wpływać na ustawienia, dlatego nie traktuj go jako obojętnego testu na produkcji.

Sprawdź aktualizację motywu i kod własny, w tym motyw potomny. Motyw potomny pomaga zachować własne szablony przy aktualizacji, ale nie zastępuje automatycznie każdej funkcji z functions.php motywu nadrzędnego. Zmiany w kodzie przetestuj w kontekście konkretnego motywu.

Testowanie na środowisku deweloperskim – bezpieczne przejście

  1. Wykonaj kopię plików i bazy danych, przechowuj ją bezpiecznie poza serwerem i sprawdź możliwość przywrócenia.
  2. Przygotuj kopię strony z osobną bazą, zbliżoną konfiguracją serwera i docelową wersją PHP. Zabezpiecz ją hasłem; samo noindex nie chroni danych.
  3. Odłącz rzeczywiste płatności, wysyłkę wiadomości, webhooki, zadania cykliczne i inne integracje; korzystaj z trybów testowych. Nie używaj prawdziwych transakcji ani danych klientów bez odpowiednich zabezpieczeń.
  4. Sprawdź stronę, panel, logowanie, formularze oraz koszyk i składanie zamówienia w trybie testowym. Przejrzyj logi również po zadaniach działających w tle.
  5. Porównaj działanie i czas odpowiedzi przed zmianą i po niej. Poprawa wydajności zależy od witryny i konfiguracji, nie jest gwarantowana.

Rozwiązywanie najczęstszych błędów – praktyczne przykłady

  • Biały ekran lub HTTP 500: sprawdź log PHP i log serwera z czasu żądania. Kod 500 ma różne przyczyny, nie tylko błąd PHP.
  • Call to undefined function each(): zaktualizuj wskazany kod. foreach bywa rozwiązaniem, lecz trzeba uwzględnić pierwotną iterację i wskaźnik tablicy.
  • TypeError: sprawdź typy i źródło argumentów; popraw wywołanie lub walidację zamiast na ślepo zmieniać deklarację funkcji.
  • Cannot redeclare: komunikat wskazuje kolidującą funkcję i pliki. Usuń przyczynę podwójnego ładowania lub popraw własny kod; samo function_exists() może jedynie ukryć konflikt.
  • Allowed memory size exhausted: ustal, która operacja zużywa pamięć. Zwiększenie limitu bez diagnozy może tylko odsunąć problem.

Podsumowanie – plan migracji na PHP 8

Najpierw sprawdź zgodność, wykonaj kopię i przygotuj plan powrotu. Na odizolowanym stagingu zaktualizuj komponenty, przetestuj docelową wersję PHP i napraw błędy. Dopiero potem zaplanuj zmianę na produkcji oraz sprawdź działanie i logi po wdrożeniu.

Jeżeli po zmianie witryna nie działa, hosting może pozwolić na tymczasowy powrót do poprzedniej wersji PHP. Wersja bez wsparcia bezpieczeństwa nie jest rozwiązaniem docelowym. Przywrócenie całej kopii bazy może też usunąć zamówienia lub inne dane powstałe od jej wykonania; plan odtworzenia uzgodnij z administratorem.

Najczęstsze pytania o WordPress i PHP 8

Jak sprawdzić wersję PHP strony WordPress?

Sprawdź panel hostingu lub w WordPress przejdź do Narzędzia → Zdrowie witryny → Informacje → Serwer. Wersja PHP w terminalu może różnić się od wersji obsługującej stronę.

Co zrobić, gdy WordPress przestał działać po zmianie wersji PHP?

Sprawdź wiadomość o trybie odzyskiwania oraz logi serwera. Na ich podstawie ustal, czy błąd wskazuje wtyczkę, motyw lub własny kod. Zmiany najpierw sprawdź na kopii testowej.

Czy wszystkie wtyczki i motywy działają z PHP 8?

Nie. Zgodność zależy od konkretnej wersji PHP i danego dodatku. Sprawdź informacje producenta i przetestuj stronę na odizolowanej kopii.

Czy można wrócić do wcześniejszej wersji PHP?

Jeśli hosting na to pozwala, powrót do poprzedniej wersji może tymczasowo przywrócić działanie strony. Niewspierana wersja PHP jest ryzykiem bezpieczeństwa i wymaga możliwie szybkiej aktualizacji.

Jak naprawić błąd Call to undefined function each()?

Funkcja each() została usunięta w PHP 8. Najpierw poszukaj aktualizacji dodatku. Zmianę własnego kodu, na przykład na foreach, trzeba dopasować do sposobu użycia wskaźnika tablicy i przetestować.

Masz problemy z migracją WordPress na PHP 8? Możemy pomóc w diagnozie konfliktu i zaplanowaniu aktualizacji.