Biały ekran i krytyczny błąd WordPressa — plan bezpiecznej naprawy

Biały ekran, komunikat „Wystąpił krytyczny błąd” i odpowiedź 500 mogą być różnymi objawami tego samego błędu PHP. Nie wskazują jednak automatycznie wadliwej wtyczki. Przyczyną może być motyw, własny kod, niezgodna wersja PHP, brak pamięci, uszkodzona aktualizacja albo problem infrastruktury.

Krótka odpowiedź: nie odświeżaj strony bez końca i nie aktualizuj kolejnych elementów. Zapisz zakres awarii i ostatnią zmianę, sprawdź skrzynkę administratora pod kątem wiadomości trybu odzyskiwania, wykonaj kopię obecnego stanu i przejrzyj log z chwili błędu. Jeśli log wskazuje jeden komponent, wyłącz go kontrolowanie lub wróć do zgodnej wersji. Gdy panel nie działa, użyj SFTP/panelu plików dopiero po zabezpieczeniu danych. Po przywróceniu strony usuń pierwotną przyczynę, przetestuj funkcje i nie traktuj samego zniknięcia komunikatu jako pełnej naprawy.

Najpierw sprawdź zakres awarii

Otwórz bez wielokrotnego odświeżania:

• stronę główną;
• jedną podstronę;
• /wp-admin/;
• stronę logowania;
• dokładne działanie, po którym pojawia się błąd;
• odpowiedź z innej przeglądarki bez aktywnej sesji.

Zapisz status HTTP i godzinę. Jeżeli nie działa tylko panel, przyczyna może dotyczyć kodu uruchamianego administracyjnie. Jeśli błąd występuje przy zapisie formularza albo zadaniu cron, zwykłe otwarcie strony głównej może go nie odtworzyć.

Sprawdź też panel hostingu: stan PHP, limit miejsca, komunikaty o awarii i ostatnie kopie. Biały ekran nie zawsze pochodzi z WordPressa.

Ustal ostatnią zmianę, ale jej nie obwiniaj bez dowodu

Najważniejsze pytania:

• czy właśnie aktualizowano WordPressa, motyw lub wtyczkę;
• czy zmieniono wersję PHP;
• czy edytowano functions.php, wp-config.php albo .htaccess;
• czy instalowano nowe rozszerzenie;
• czy hosting przywracał kopię lub migrował serwis;
• czy wyczerpało się miejsce albo limit plików;
• czy błąd pojawia się stale czy przy konkretnych danych.

Zbieżność czasowa tworzy hipotezę. Log powinien ją potwierdzić.

Tryb odzyskiwania WordPressa

WordPress ma wbudowany Recovery Mode, który w niektórych przypadkach fatalnego błędu PHP wysyła wiadomość na administracyjny adres e-mail. Specjalny link pozwala zalogować się do sesji, w której wadliwy motyw lub wtyczka jest wstrzymana dla administratora, aby można było przeprowadzić diagnozę.

Postępuj tak:

1. sprawdź skrzynkę administratora i spam;
2. zweryfikuj domenę linku przed otwarciem;
3. zaloguj się przez specjalny adres;
4. przeczytaj informację o komponencie i błędzie;
5. wyłącz wskazany element lub popraw własny kod;
6. przetestuj stronę przed wyjściem z trybu;
7. po naprawie wybierz zakończenie Recovery Mode.

Wiadomość nie zawsze przyjdzie. Tryb nie obejmuje każdego błędu, a poczta witryny mogła przestać działać. Brak e-maila nie wyklucza fatalnego błędu PHP.

Zabezpiecz stan przed zmianami

Jeżeli hosting tworzy kopie, nie zakładaj, że ostatnia jest kompletna i możliwa do odtworzenia. Pobierz lub oznacz kopię plików i bazy. Zachowaj także logi, wersje komponentów i czas awarii.

Przy stronie z zamówieniami nie cofaj całej bazy do wczoraj tylko dlatego, że dostępna jest kopia. Utraciłbyś nowe dane. Często bezpieczniej przywrócić poprzednią wersję jednego pliku lub komponentu po diagnozie.

Zdobądź konkretny komunikat błędu

Sprawdź kolejno:

1. wiadomość Recovery Mode;
2. error log PHP/serwera w panelu;
3. log aplikacji, jeśli był już bezpiecznie skonfigurowany;
4. tymczasowy WP_DEBUG_LOG z wyłączonym wyświetlaniem błędów;
5. dziennik wdrożenia albo aktualizacji.

Nie pokazuj display_errors publicznie. Szczegóły mogą ujawnić ścieżki serwera i fragmenty działania aplikacji. Bezpieczną konfigurację opisuje poradnik WP_DEBUG — jak włączyć logowanie błędów.

W logu szukaj pierwszego fatalnego błędu w czasie testu, pliku, linii oraz stosu wywołań. Allowed memory size exhausted nie oznacza automatycznie, że wystarczy podnieść limit; komponent może zużywać pamięć w pętli.

Gdy log wskazuje jedną wtyczkę

Jeśli panel działa w trybie odzyskiwania, wyłącz wskazaną wtyczkę tam. Następnie sprawdź, czy jej funkcja jest krytyczna: wyłączenie formularza, płatności, wielojęzyczności lub zabezpieczenia może przywrócić HTML, ale zepsuć proces biznesowy.

Gdy panel nie działa, oficjalna dokumentacja WordPressa opisuje awaryjne wyłączenie przez zmianę nazwy katalogu konkretnej wtyczki, np.:

wp-content/plugins/nazwa-wtyczki
wp-content/plugins/nazwa-wtyczki.wylaczona

Warunki bezpieczeństwa:

• działasz na komponencie wskazanym przez log lub ostatnią zmianę;
• masz kopię i dostęp do cofnięcia;
• zapisujesz poprzednią nazwę;
• nie usuwasz katalogu;
• po zmianie testujesz stronę, panel i funkcję wtyczki;
• później instalujesz zgodną, czystą wersję albo wdrażasz poprawkę.

Nie pozostawiaj przypadkowej nazwy jako trwałej „naprawy”.

Gdy nie wiadomo, która wtyczka zawiniła

Zmiana nazwy całego wp-content/plugins może awaryjnie dezaktywować wtyczki i umożliwić logowanie, ale ma duży wpływ. Rób to tylko w kontrolowanym oknie, z kopią i świadomością skutków. Po przywróceniu nazwy wtyczki mogą wymagać ręcznej aktywacji.

Bezpieczniejsza kolejność na stagingu:

1. odtwórz błąd;
2. zachowaj log;
3. wyłącz połowę niekrytycznych wtyczek;
4. sprawdź identyczny scenariusz;
5. zawężaj zbiór;
6. testuj wykrytą wtyczkę z motywem bazowym;
7. sprawdź kompatybilność wersji.

Na produkcji nie wyłączaj całego zestawu w godzinach sprzedaży tylko po to, aby szukać metodą prób.

Gdy log wskazuje motyw lub własny kod

Jeśli błąd powstał po edycji własnego kodu, przywróć ostatnią działającą wersję z repozytorium lub kopii. Nie poprawiaj składni na produkcji bez kontroli wersji.

Przełączenie motywu może zmienić układ, widgety i funkcje, dlatego najpierw sprawdź rozwiązanie na stagingu. Motyw potomny i nadrzędny mogą być zależne; log pokaże miejsce ujawnienia błędu, ale przyczyną może być brak funkcji z drugiego komponentu.

Gdy problem zaczął się po zmianie PHP

Nie każda wtyczka obsługuje każdą wersję PHP. Porównaj wymagania WordPressa i komponentów, log deprecacji/fatal error oraz wersję działającą przed zmianą.

Jeżeli musisz wykonać rollback PHP, potraktuj go jako krótkie przywrócenie usługi, nie rozwiązanie na zawsze. Stara, niewspierana wersja może nie otrzymywać poprawek bezpieczeństwa. Zaplanuj aktualizację lub wymianę niezgodnego kodu.

Czego nie robić

• Nie przywracaj losowej starej kopii bez oceny utraty danych.
• Nie podmieniaj całego WordPressa plikami z nieznanego archiwum.
• Nie usuwaj katalogów wtyczek przed zachowaniem dowodów.
• Nie zwiększaj bez końca memory_limit i czasu wykonania.
• Nie włączaj publicznego wyświetlania błędów.
• Nie wykonuj jednocześnie aktualizacji rdzenia, motywu, PHP i wszystkich wtyczek.
• Nie uznawaj strony za naprawioną tylko dlatego, że działa jej ekran główny.

Test po przywróceniu strony

Sprawdź co najmniej:

• stronę główną i kilka szablonów podstron;
• logowanie oraz edycję;
• formularze i dostarczenie wiadomości;
• menu mobilne;
• zadania zaplanowane;
• integracje, rezerwacje lub płatności;
• logi po wykonaniu testów;
• monitoring i kopię po naprawie.

Zapisz przyczynę pierwotną, wersje, działanie awaryjne, rozwiązanie docelowe i sposób zapobiegania. Jeśli winna była niezgodna aktualizacja, potrzebujesz stagingu i procedury wdrożeń — nie trwałego zakazu aktualizowania.

Przywrócenie usługi to dopiero połowa pracy

Awaryjne wyłączenie komponentu może szybko przywrócić stronę, lecz jednocześnie wyłączyć ważną funkcję. Pełna naprawa usuwa lub zastępuje wadliwy kod, potwierdza zgodność, testuje procesy biznesowe i pozostawia aktualną kopię oraz dokumentację.

Najkrótsza bezpieczna droga prowadzi przez dowód: zakres awarii, log, jedna odwracalna zmiana i powtórzenie tego samego testu.