Błąd 500 po zmianie PHP — co sprawdzić w WordPress i PrestaShop?

27 października, 2026 autor soban

Po przełączeniu PHP strona pokazuje błąd 500, biały ekran albo komunikat o krytycznym błędzie? Najważniejszą wskazówką jest moment zmiany i pierwszy rzeczywisty błąd w logach. Sam kod 500 nie określa przyczyny i nie przesądza o włamaniu.

Ten poradnik pomaga właścicielowi WordPressa lub PrestaShop przygotować diagnostykę i ograniczyć kolejne zmiany. Jeśli witryna jest potrzebna do sprzedaży, zacznij od zabezpieczenia danych i ustalenia sposobu przywrócenia działania.

Pomoc przy PHP i błędach po aktualizacji

Co zrobić w pierwszej kolejności?

  1. Zapisz, co i kiedy zmieniono. Zanotuj poprzednią i nową wersję PHP, godzinę przełączenia oraz ewentualne aktualizacje aplikacji, motywu i modułów wykonane równocześnie.
  2. Sprawdź zakres awarii. Czy nie działa cała witryna, tylko panel, produkt, formularz albo koszyk? Czy błąd występuje również bez zalogowania?
  3. Zachowaj logi i stan witryny. Skopiuj dostępne komunikaty oraz zabezpiecz pliki i bazę przed kolejną próbą naprawy. Nie nadpisuj jedynego sprawdzonego backupu.
  4. Wstrzymaj przypadkowe poprawki. Nie aktualizuj jednocześnie kolejnych dodatków i nie usuwaj plików na chybił trafił. Zmieniaj jeden element naraz i zapisuj wynik.
  5. Ustal możliwość wycofania. Jeśli zmieniono wyłącznie PHP, hosting może umożliwiać powrót do poprzedniej wersji. Jeżeli aktualizowano też aplikację lub bazę, trzeba uwzględnić ich zgodność i nowe dane.

W sklepie szczególnie ważne są zamówienia i płatności powstałe w czasie awarii. Odtworzenie starej bazy bez ich uwzględnienia może spowodować utratę informacji o sprzedaży.

Najczęstsze tropy po zmianie PHP

Co widać? Co sprawdzić?
Błąd wskazuje plik wtyczki, modułu lub motywu Zgodność konkretnego wydania dodatku z nowym PHP oraz dostępność poprawki. Nazwa pliku wskazuje miejsce błędu, nie zawsze pełną przyczynę.
Komunikat o brakującej klasie lub funkcji Wymagane rozszerzenia PHP, zależności aplikacji i zgodność kodu. Zmiana wersji może przełączyć również zestaw aktywnych rozszerzeń.
Komunikat o przekroczonym limicie pamięci Jaka operacja i jaki kod zużywają pamięć oraz jakie limity obowiązują. Samo zwiększenie limitu może jedynie przesunąć moment błędu.
Błąd tylko w panelu albo podczas składania zamówienia Moduły i integracje używane w tej konkretnej ścieżce. Działająca strona główna nie potwierdza sprawności sklepu.
Błąd pojawił się po zmianie konfiguracji serwera Log serwera WWW, ustawienia procesu PHP i konfigurację hostingu. Nie każdy błąd 500 pochodzi z kodu aplikacji.

Gdzie szukać informacji o błędzie?

Zacznij od panelu hostingu i logów błędów serwera oraz PHP. Szukaj wpisu odpowiadającego godzinie konkretnego żądania. Zapisz komunikat, ścieżkę pliku i numer linii, ale przed udostępnieniem usuń dane osobowe, tokeny i hasła.

WordPress: sprawdź także wiadomość o błędzie krytycznym wysłaną na adres administracyjny. Jeśli dostępny jest tryb odzyskiwania, może pomóc wskazać problematyczny element. Tymczasowe logowanie debugowania najlepiej uruchamiać na kopii testowej i zgodnie z dokumentacją WordPressa.

PrestaShop: lokalizacja logów i tryb diagnostyczny zależą od wersji sklepu oraz instalacji. Jeśli nie masz dostępu do panelu, poproś hosting lub administratora o właściwy log PHP i aplikacji. Nie włączaj publicznego pokazywania szczegółów błędu klientom sklepu.

Log diagnostyczny powinien być chroniony przed pobraniem przez internet. Nie publikuj pliku phpinfo(), kopii konfiguracji ani pełnego debug.log. Po diagnostyce wyłącz zbędne logowanie szczegółowe i sprawdź uprawnienia zapisanych plików.

Czy wynik php -v mówi, z czego korzysta strona?

Niekoniecznie. PHP uruchamiane w terminalu może mieć inną wersję, konfigurację i rozszerzenia niż proces obsługujący żądania WWW. Przy diagnozie potrzebna jest informacja o PHP faktycznie przypisanym do danej witryny. Najczęściej ustala się ją w panelu hostingu, ustawieniach aplikacji lub konfiguracji serwera.

Czego nie robić podczas awarii?

  • Nie wyłączaj wszystkich modułów sklepu na produkcji bez oceny skutków dla płatności, dostawy i zamówień.
  • Nie ustawiaj masowo uprawnień 777, aby „naprawić dostęp”. To nie rozwiązuje niezgodności kodu.
  • Nie traktuj ukrycia komunikatów błędów jako naprawy. Brak komunikatu na ekranie nie oznacza, że żądanie zakończyło się poprawnie.
  • Nie zostawiaj starej wersji PHP jako rozwiązania bez planu aktualizacji. Może to być przejściowy krok ratunkowy, jeśli jest dostępny i zgodny z aplikacją.

Jak potwierdzić, że naprawa się udała?

Sprawdź stronę główną i ścieżkę, która wywoływała błąd. W WordPressie mogą to być edycja treści, formularz i zadania cykliczne. W sklepie uwzględnij produkt z wariantami, koszyk, dostawę, panel i integracje. Płatności testuj w uzgodnionym trybie, bez przypadkowych rzeczywistych transakcji. Obserwuj nowe wpisy w logach.

Co podać administratorowi, żeby przyspieszyć diagnozę?

Przygotuj adres strony, poprzednią i nową wersję PHP, godzinę zmiany, opis niedziałającej funkcji oraz oczyszczony fragment komunikatu błędu. Napisz, czy aktualizowano bazę lub aplikację i z kiedy jest ostatnia sprawdzona kopia. W pierwszej wiadomości nie przesyłaj haseł.

Opisz błąd strony lub sklepu

Zakres pomocy i testów opisuję na stronie aktualizacja PHP w WordPress i PrestaShop. Jeśli zamiast typowego błędu pojawiają się obce przekierowania lub nieznane treści, sprawdź również pomoc po włamaniu.

Źródła i dalsza lektura: debugowanie WordPressa, typowe błędy WordPressa, konfiguracja błędów PHP, przewodniki migracji PHP. Sprawdzono 27 października 2026.

Gdy problem dotyczy składania zamówień

Jeśli po zmianie sklep nie pozwala zakończyć zakupu, sprawdź poradnik: sklep nie przyjmuje zamówień po aktualizacji. Obejmuje rozróżnienie błędu koszyka, płatności i zapisu zamówienia.

Gdy hosting wyłącza stare środowisko

Jeśli hosting zapowiada wyłączenie starego PHP lub ograniczył dostęp do witryny, sprawdź poradnik: hosting wyłączył stare PHP lub zablokował stronę. Pomoże przygotować diagnozę, kopię danych i plan aktualizacji lub migracji.