W witrynie wystąpił błąd krytyczny po aktualizacji PHP – jak naprawić problem?

Błąd „W witrynie wystąpił błąd krytyczny” po aktualizacji PHP niemal zawsze oznacza niezgodność wtyczki, motywu lub samego CMS (WordPress/PrestaShop) z nową wersją PHP, co wywołuje fatalny błąd. Naprawa polega na tymczasowym przywróceniu działania (np. przez wyłączenie problematycznych elementów lub cofnięcie wersji PHP), włączeniu debugowania i krok po kroku zidentyfikowaniu źródła konfliktu.

1. Co oznacza komunikat „W witrynie wystąpił błąd krytyczny”?

W WordPressie komunikat „W witrynie wystąpił błąd krytyczny” to ogólna informacja, że w czasie wykonywania kodu wystąpił poważny błąd PHP, który przerwał działanie strony (fatal error).

W praktyce dzieje się zwykle jedno z poniższych:

• strona wyświetla biały ekran albo lakoniczny komunikat o błędzie krytycznym, często bez szczegółów dla użytkownika końcowego,
• panel administracyjny może być niedostępny, działać częściowo lub również zwracać błąd,
• serwer w logach pokazuje błędy typu „Fatal error”, „Uncaught Error”, „Uncaught Exception” lub klasyczny kod HTTP 500 Internal Server Error.

Po aktualizacji PHP najczęstszą przyczyną jest to, że stary kod (wtyczka, motyw, skrypt) używa funkcji usuniętych lub zmienionych w nowej wersji PHP, albo łamie bardziej restrykcyjne zasady języka.

2. Dlaczego aktualizacja PHP psuje stronę?

Aktualizacja PHP (np. z 7.4 do 8.1 lub wyżej) przynosi zmiany w języku – część funkcji jest oznaczona jako deprecated, inne są usuwane, a nowe wersje PHP ostrzej egzekwują typy i błędy składni.

Typowe scenariusze po aktualizacji PHP to:

• Niezgodne wtyczki – jedna z wtyczek używa starych funkcji, które w nowym PHP generują fatalne błędy;
• Stary motyw – motyw nie był aktualizowany od lat i nie wspiera współczesnych wersji PHP;
• Nieaktualny WordPress/PrestaShop – sam system CMS jest zbyt stary w stosunku do wersji PHP wymuszanej przez hosting;
• Zmiana ustawień serwera – aktualizacja PHP idzie w parze ze zmianą domyślnych limitów (pamięci, czasu wykonywania), co ujawnia problemy wydajnościowe;
• Błąd 500 po aktualizacji – przy aktualizacji mogą przestać działać niektóre reguły w pliku .htaccess, co kończy się błędem 500 i krytycznym błędem w WordPressie.

Traktuj aktualizację PHP jak poważną zmianę środowiska – najpierw testuj, potem wdrażaj.

3. Zanim zaczniesz – podstawowe przygotowanie

Przed naprawą błędu krytycznego upewnij się, że masz podstawy do bezpiecznej diagnozy i zmian:

1. Kopia zapasowa (backup) – sprawdź datę ostatniej pełnej kopii na hostingu; jeśli nie masz backupu, pobierz pliki przez FTP/SFTP i wykonaj eksport bazy przez phpMyAdmin.
2. Dostęp do serwera plików – przy błędzie krytycznym panel WP bywa niedostępny; przygotuj dostęp FTP/SFTP lub menedżer plików w hostingu.
3. Dostęp do panelu hostingu – w panelu zmienisz wersję PHP, podstawowe ustawienia oraz sprawdzisz logi błędów serwera.
4. Podstawowa znajomość struktury WordPressa – kluczowe pliki: wp-config.php, .htaccess; katalogi: wp-content (wtyczki, motywy) i folder główny instalacji.

4. Szybka ścieżka ratunkowa – cofnięcie wersji PHP

Jeśli strona przestała działać tuż po zmianie PHP, a musisz natychmiast przywrócić jej dostępność, cofnij wersję PHP w panelu hostingu do poprzedniej, na której działała poprawnie.

Po cofnięciu wersji PHP odśwież stronę – jeśli działa, masz potwierdzenie, że przyczyną jest niezgodność z nową wersją PHP.

To rozwiązanie tymczasowe (starsze wersje PHP tracą wsparcie bezpieczeństwa), ale daje czas na diagnozę, aktualizację wtyczek/motywu oraz WordPressa.

5. Włączenie debugowania w WordPressie (WP_DEBUG)

Aby zobaczyć konkretny błąd stojący za komunikatem „błąd krytyczny”, włącz debugowanie w pliku wp-config.php wykonując te kroki:

1. Połącz się z serwerem przez FTP/SFTP lub menedżer plików.
2. Otwórz plik wp-config.php w głównym katalogu WordPressa.
3. Znajdź linię:

Wklej/znajdź dokładnie taki zapis w pliku konfiguracyjnym:

define('WP_DEBUG', false);

4. Zmień ją na poniższe ustawienia (logowanie do pliku, bez wyświetlania na froncie):

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Co oznaczają powyższe dyrektywy:

• WP_DEBUG – włącza tryb debugowania;
• WP_DEBUG_LOG – zapisuje błędy do pliku wp-content/debug.log;
• WP_DEBUG_DISPLAY – ustawione na false ukrywa szczegóły błędów przed użytkownikami.

Następnie przejdź do folderu wp-content i otwórz plik debug.log – tam znajdziesz informację, który plik lub wtyczka powoduje błąd.

6. Jak czytać logi błędów?

W pliku debug.log lub logach serwera wyszukuj wpisów oznaczonych jako Fatal error lub Uncaught Error/Exception. Najczęściej zobaczysz:

• Fatal error – undefined function/class (np. funkcja usunięta w nowym PHP);
• ścieżkę do pliku – wskazuje miejsce wystąpienia błędu i numer linii;
• /wp-content/plugins/nazwa-wtyczki/… – problem powoduje konkretna wtyczka;
• /wp-content/themes/nazwa-motywu/… – błąd w aktywnym motywie;
• /wp-includes/… lub /wp-admin/… – błąd w rdzeniu WP (często skutek niezgodnego dodatku).

Powtarzająca się ścieżka do tej samej wtyczki/motywu to jasny sygnał, co należy tymczasowo wyłączyć.

7. Dezaktywacja problematycznych wtyczek (bez panelu)

Gdy logi wskazują konkretną wtyczkę lub podejrzewasz plugin aktualizowany przed zmianą PHP, wyłącz go przez FTP/SFTP:

Wyłączenie pojedynczej wtyczki

1. Wejdź do katalogu wp-content/plugins/.
2. Znajdź folder podejrzanej wtyczki (np. woocommerce, elementor).
3. Zmień nazwę folderu, aby wymusić dezaktywację (np. woocommerce → woocommerce-dezaktywacja, elementor → elementor-dezaktywowany).

WordPress nie znajdzie folderu, uzna wtyczkę za nieaktywną i automatycznie ją wyłączy.

Wyłączenie wszystkich wtyczek naraz

Jeśli nie wiesz, która wtyczka powoduje błąd, wyłącz je zbiorczo:

1. W katalogu wp-content zmień nazwę folderu plugins na np. plugins-off.
2. Odśwież stronę – jeśli zacznie działać, problem leży w jednej z wtyczek.
3. Przywróć nazwę folderu plugins, a następnie włączaj wtyczki pojedynczo z panelu WP i obserwuj, przy której błąd wraca.

8. Zmiana motywu na domyślny

Jeśli logi wskazują na motyw lub podejrzewasz niezgodność z nowym PHP, przełącz stronę na motyw domyślny.

Tymczasowe wyłączenie motywu przez FTP

1. Przejdź do katalogu wp-content/themes/.
2. Zmień nazwę folderu aktualnego motywu (np. moj-motyw → moj-motyw-backup).

WordPress spróbuje uruchomić inny dostępny motyw – jeśli masz zainstalowany domyślny (np. Twenty Twenty‑Five), przełączy się właśnie na niego.

Zmiana motywu przez bazę danych

Gdy panel nie działa, wskaż motyw ręcznie w bazie danych:

1. Wejdź do phpMyAdmin.
2. Odszukaj tabelę wp_options (prefiks może być inny, np. wp_).
3. Znajdź wpisy template oraz stylesheet i ustaw nazwę domyślnego motywu (np. twentytwentyfive).

9. Sprawdzenie wersji PHP i kompatybilności

Po zidentyfikowaniu źródła błędu zweryfikuj zgodność całego oprogramowania z wersją PHP wymuszaną przez hosting:

1. Zaloguj się do panelu hostingu i sprawdź wersję PHP ustawioną dla domeny/konta.
2. Porównaj wymagania z dokumentacją poszczególnych komponentów.

Zwróć uwagę na kluczowe zależności:

• aktualna wersja WordPressa – zwykle rekomenduje nowoczesne wersje PHP,
• wtyczki i motyw – producenci podają zakresy kompatybilności z PHP,
• PrestaShop – konkretne wydania mają określone zakresy wspieranego PHP.

Gdy używasz zbyt starego WordPressa, motywu lub wtyczek, a hosting wymusił nowy PHP, zastosuj kolejność działań:

• aktualizacja WordPressa do najnowszej wersji,
• aktualizacja motywu i wtyczek do wersji zgodnych z nowym PHP,
• ponowna zmiana PHP na docelową wersję (np. 8.1/8.2).

Jeśli pełna aktualizacja wszystkiego jest trudna, możesz tymczasowo pozostać przy starszej, ale jeszcze wspieranej wersji PHP i zaplanować stopniową modernizację strony.

10. Typowe błędy po aktualizacji PHP i ich rozwiązania

Poza komunikatem „błąd krytyczny” mogą pojawić się inne symptomy wskazujące na niezgodność z nowym środowiskiem.

Błąd 500 / biały ekran

Błąd HTTP 500 Internal Server Error zwykle oznacza problem z konfiguracją serwera lub kodem. Najczęstsze przyczyny to:

• nieprawidłowe reguły w pliku .htaccess,
• fatalny błąd PHP wywołany przez wtyczkę lub motyw,
• przekroczenie limitów serwera (pamięć, czas wykonywania).

Co możesz zrobić: zrób kopię pliku .htaccess, zmień jego nazwę (np. na .htaccess_old), a po przywróceniu panelu zapisz ponownie ustawienia bezpośrednich odnośników, aby wygenerować nowy plik.

Następnie wyłącz wtyczki i motyw zgodnie z opisem powyżej i obserwuj, przy którym komponencie błąd znika.

Brak pamięci (Allowed memory size exhausted)

Jeśli logi wskazują przekroczony limit pamięci, zwiększ go w WordPressie:

define('WP_MEMORY_LIMIT', '256M');

Jeśli hosting pozwala, ustaw także wyższy limit w PHP:

memory_limit = 256M

Pamiętaj, że nadmierne zużycie pamięci przez jedną wtyczkę często oznacza, że sama wtyczka jest problematyczna.

Zbyt krótki czas wykonywania (Maximum execution time exceeded)

Komunikat oznacza, że skrypt wykonuje się zbyt długo. Zwiększ limit czasu w konfiguracji PHP (np. max_execution_time = 60 lub wyżej). Jeśli nie masz dostępu do php.ini, część hostingów pozwala nadpisać ten limit w .htaccess.

11. Schemat diagnostyczny „WordPress nie działa”

Przy problemach po aktualizacji PHP zastosuj uporządkowany schemat:

1. Strona i panel całkowicie nie działają (błąd krytyczny / 500)
   • włącz debugowanie (WP_DEBUG, WP_DEBUG_LOG),
   • sprawdź debug.log i zidentyfikuj wtyczkę/motyw powodujący błąd,
   • wyłącz wskazany dodatek lub wszystkie naraz, jak opisano wyżej,
   • jeśli to nie pomaga – cofnij wersję PHP tymczasowo.
2. Panel działa, ale front strony nie – sprawdź, czy problem dotyczy wszystkich podstron czy wybranych (np. sklep, blog), a następnie wyłącz wtyczki powiązane z tą sekcją (np. WooCommerce, page builder).
3. Front działa, panel nie – często winne są wtyczki administracyjne (zabezpieczenia, edytory). Wyłącz je przez FTP, jeśli nie masz dostępu do panelu.

12. PrestaShop i inne CMS-y – krytyczne błędy po aktualizacji PHP

Choć komunikat jest charakterystyczny dla WordPressa, podobne problemy po aktualizacji PHP pojawiają się także w innych systemach, np. w PrestaShop.

Najczęstsze problemy w PrestaShop po aktualizacji PHP:

• brak zgodności wersji PrestaShop z nowym PHP (np. stare wydanie nie działa z PHP 8.x),
• moduły (odpowiednik wtyczek) powodują fatalne błędy,
• problemy z override’ami i niestandardowym kodem.

Ogólne kroki naprawy:

• sprawdź w dokumentacji PrestaShop, jakie wersje PHP wspiera Twoja wersja sklepu,
• jeśli sklep padł po zmianie PHP, tymczasowo cofnij wersję, a następnie zaktualizuj PrestaShop do kompatybilnej edycji,
• wyłącz problematyczne moduły przez panel lub FTP (zmiana nazwy katalogów modułów).

13. Przywrócenie kopii zapasowej – gdy debugowanie nie wystarcza

Jeśli mimo wyłączania wtyczek, zmiany motywu, cofnięcia PHP i analizy logów strona nadal nie działa, a liczy się czas, przywróć ostatnią kopię zapasową z momentu, gdy wszystko działało.

Większość hostingów oferuje przywracanie kopii plików oraz bazy danych – często niezależnie.

Po przywróceniu kopii zaplanuj bezpieczną ścieżkę aktualizacji: najpierw backup, potem aktualizacja WordPressa, wtyczek i motywu, a na końcu zmiana wersji PHP.

14. Kiedy skorzystać z pomocy specjalisty?

Są sytuacje, gdy samodzielne zmiany mogą bardziej zaszkodzić niż pomóc. Rozważ wsparcie, jeśli:

• brakuje Ci doświadczenia z FTP, bazą danych i plikami konfiguracyjnymi,
• prowadzisz sklep lub serwis biznesowy, w którym przestój oznacza realne straty,
• w logach pojawiają się skomplikowane błędy (własny kod, integracje, API).

W takich przypadkach skontaktuj się z supportem hostingu (często wskażą źródło problemu) lub zleć analizę developerowi WordPress/PrestaShop (staging, Health Check, testy).

15. Jak przygotować się na przyszłe aktualizacje PHP?

Aby kolejne aktualizacje PHP nie kończyły się „błędem krytycznym”, wdroż poniższe dobre praktyki:

1. Regularnie aktualizuj CMS i dodatki – nie odkładaj aktualizacji na lata; im większy skok wersji, tym więcej potencjalnych konfliktów.
2. Rób pełne kopie zapasowe przed zmianami – przed aktualizacją PHP, dużych wtyczek i motywu wykonaj backup plików oraz bazy.
3. Korzystaj ze środowiska testowego (staging) – przetestuj nowy PHP i aktualizacje „na kopii” strony zanim wdrożysz je na produkcji.
4. Monitoruj wymagania techniczne – sprawdzaj wersje PHP zalecane przez CMS i wtyczki; unikaj przeskakiwania na świeżo wydane PHP, jeśli dodatki nie są jeszcze kompatybilne.
5. Minimalizuj liczbę wtyczek – im mniej dodatków, tym mniejsze ryzyko konfliktów; usuwaj zbędne i wybieraj rozwiązania aktywnie rozwijane.

Dzięki temu aktualizacje PHP będą przede wszystkim wzmocnieniem bezpieczeństwa i wydajności, a nie początkiem kryzysu.