Biały ekran w WordPressie? Jak przywrócić stronę, gdy nic się nie wyświetla

Strona firmowa działała wieczorem, a rano w przeglądarce widać pustą, białą kartę albo jedno zdanie o błędzie krytycznym. Formularz kontaktowy, oferta i sklep są niedostępne, a do kokpitu często również nie da się wejść. To jedna z najczęstszych awarii WordPressa i w ogromnej większości przypadków da się ją usunąć bez utraty treści.

Ta instrukcja jest przeznaczona dla właścicieli firm i osób, które same opiekują się stroną na WordPressie. Opisuję w niej, jak rozpoznać rodzaj awarii, jak odczytać jej przyczynę z dziennika błędów i jak po kolei wykluczać wtyczkę, motyw, limit pamięci, wersję PHP oraz uszkodzone pliki.

Po lekturze czytelnik będzie umiał wejść do trybu odzyskiwania, włączyć zapis błędów w pliku wp-config.php, wyłączyć wtyczki z poziomu serwera, przywrócić kopię zapasową i uporządkować stronę po naprawie. Nazwy stałych i ścieżki podaję zgodnie z dokumentacją WordPressa, a nazwy z kokpitu zgodnie z jego polską wersją.

Jak wygląda biały ekran i komunikat o błędzie krytycznym?

Biały ekran to sytuacja, w której serwer odsyła pustą stronę: bez treści, bez menu i bez żadnego komunikatu. Dokumentacja WordPressa wyjaśnia, że w ten sposób mogą się objawiać zarówno błędy PHP, jak i błędy bazy danych. Dla właściciela strony oznacza to jedno: WordPress przerwał pracę, zanim zdążył cokolwiek wyświetlić.

Nowsze wersje WordPressa zamiast pustej strony pokazują zwykle krótki komunikat „W witrynie wystąpił błąd krytyczny.” oraz odnośnik „Dowiedz się więcej o rozwiązywaniu problemów z WordPressem.”. Na ekranie logowania i w kokpicie komunikat bywa dłuższy i odsyła do skrzynki e-mail administratora witryny. To ta sama awaria co biały ekran, jedynie opisana słowami.

Awaria może obejmować całą witrynę, sam kokpit albo pojedyncze podstrony. Ta różnica jest pierwszą wskazówką. Jeżeli nie działa tylko jedna podstrona, przyczyny trzeba szukać w tym, co ją obsługuje, na przykład we wtyczce formularza albo galerii. Jeżeli nie działa nic, zawiodło coś, co wczytuje się przy każdym wejściu.

Co sprawdzić, zanim zacznie się naprawę?

Najpierw trzeba się upewnić, że problem leży po stronie witryny, a nie przeglądarki. Stronę należy otworzyć w oknie prywatnym oraz na drugim urządzeniu, najlepiej przez sieć komórkową. Jeżeli w oknie prywatnym strona działa, wystarczy wyczyścić pamięć podręczną przeglądarki.

Następnie trzeba ustalić, co zmieniło się tuż przed awarią. Najczęściej jest to aktualizacja wtyczki, motywu lub samego WordPressa, instalacja nowego dodatku, wklejenie fragmentu kodu do pliku functions.php albo zmiana wersji PHP w panelu hostingu. Ostatnia zmiana jest pierwszym podejrzanym i od niej należy zacząć.

Trzecia czynność to zabezpieczenie obecnego stanu. Przed jakąkolwiek zmianą na serwerze trzeba pobrać na dysk plik wp-config.php i, jeśli panel hostingu na to pozwala, wykonać kopię plików oraz bazy danych. Uszkodzona strona z kompletem danych jest w lepszym położeniu niż strona, na której podczas naprawy coś nadpisano.

Jak skorzystać z wiadomości e-mail i trybu odzyskiwania?

Od wersji 5.2 WordPress ma wbudowany mechanizm, który wykrywa błąd krytyczny spowodowany przez wtyczkę lub motyw i wysyła o tym wiadomość. Trafia ona na adres wpisany w kokpicie w „Ustawienia” > „Ogólne”, w polu „Administracyjny adres e-mail”. W polskiej wersji temat wiadomości zawiera słowa „Twoja witryna ma problemy techniczne”.

W treści znajduje się wskazanie, która wtyczka lub który motyw wywołał błąd, szczegóły błędu oraz specjalny odnośnik do logowania. Odnośnik otwiera tryb odzyskiwania, w polskim kokpicie nazywany trybem awaryjnym. W tym trybie WordPress wstrzymuje wadliwy dodatek wyłącznie dla zalogowanego administratora, dzięki czemu kokpit znów się otwiera.

Odnośnik ma ograniczony czas ważności, podany w samej wiadomości. Jeżeli wygaśnie, a błąd wystąpi ponownie, WordPress wyśle nową wiadomość. Gdy poczty nie ma w skrzynce odbiorczej, trzeba zajrzeć do folderu ze spamem i sprawdzić, czy adres administracyjny nie należy do osoby, która już nie zajmuje się stroną.

1. Otwarcie wiadomości od WordPressa i kliknięcie odnośnika do trybu odzyskiwania.
2. Zalogowanie się zwykłym loginem i hasłem administratora. Na ekranie logowania widać informację o włączonym trybie awaryjnym.
3. Przejście do „Wtyczki” > „Zainstalowane wtyczki”. Przy wstrzymanej wtyczce widać informację, że nie została poprawnie załadowana.
4. Kliknięcie „Wyłącz” przy wadliwej wtyczce. Jeżeli błąd wywołał motyw, trzeba przejść do „Wygląd” > „Motywy” i włączyć inny motyw.
5. Kliknięcie „Wyjdź z trybu awaryjnego” na górnym pasku kokpitu i otwarcie strony w oknie prywatnym.

Trzeba mieć świadomość ograniczenia tego trybu: odwiedzający nadal widzą błąd, dopóki wadliwy dodatek nie zostanie wyłączony albo naprawiony. Samo wejście do trybu awaryjnego niczego jeszcze nie naprawia. Przycisk „Wznów” przy wstrzymanej wtyczce ma sens dopiero po usunięciu przyczyny, na przykład po wgraniu poprawionej wersji.

Jakie są przyczyny białego ekranu w WordPressie?

Dokumentacja WordPressa przy komunikacie o błędzie krytycznym wymienia pięć najczęstszych przyczyn: konflikt wtyczek, niezgodność motywu, niezgodną wersję PHP, wyczerpany limit pamięci oraz uszkodzone pliki WordPressa. Każdą z nich rozpoznaje się inaczej i każdą inaczej się usuwa.

Wtyczka jest winna najczęściej. Błąd pojawia się zaraz po jej aktualizacji lub instalacji, czasem po aktualizacji samego WordPressa, z którym starsza wtyczka przestała współpracować. Zdarza się też konflikt dwóch wtyczek, z których każda osobno działa poprawnie.

Motyw zawodzi zwykle po aktualizacji albo po ręcznej zmianie w jego plikach. Jeden brakujący średnik w functions.php wystarcza, żeby zatrzymać całą witrynę. Dokumentacja wskazuje motyw jako szczególnie prawdopodobną przyczynę wtedy, gdy biały ekran pojawił się tuż po włączeniu nowego motywu.

Limit pamięci PHP to ilość pamięci, jaką serwer pozwala zużyć przy jednym wczytaniu strony. Rozbudowana witryna z wieloma wtyczkami może go przekroczyć, szczególnie w kokpicie, podczas importu albo przy obróbce dużych zdjęć. Typowe jest wtedy to, że awaria występuje tylko przy niektórych czynnościach.

Wersja PHP ma znaczenie w obie strony. Zbyt stara nie obsłuży nowej wtyczki, a zbyt nowa nie uruchomi kodu, który od dawna nie był aktualizowany. Ostatnia grupa to uszkodzone pliki: przerwana aktualizacja, niepełne wgranie plików przez FTP, błąd w pliku .htaccess albo pozostawiony plik .maintenance.

Kolejność sprawdzania wynika z prawdopodobieństwa i z ryzyka. Zaczyna się od odczytania dziennika błędów, bo niczego nie zmienia na stronie, a często wskazuje wadliwy dodatek z nazwy. Dopiero potem wyłącza się wtyczki, przełącza motyw, zwiększa pamięć, zmienia wersję PHP i na końcu sięga po kopię zapasową.

Jak włączyć WP_DEBUG i dziennik błędów w wp-config.php?

WordPress potrafi zapisywać wszystkie błędy do pliku tekstowego. Służą do tego stałe wpisywane w pliku wp-config.php, który leży w głównym katalogu witryny, obok folderów wp-admin, wp-content i wp-includes. Dostęp do niego daje menedżer plików w panelu hostingu albo program do połączeń FTP lub SFTP.

Dokumentacja WordPressa podaje gotowy zestaw wierszy, który włącza tryb debugowania, kieruje błędy do pliku i jednocześnie ukrywa je przed odwiedzającymi:

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

Stała WP_DEBUG włącza tryb debugowania i domyślnie ma wartość false. WP_DEBUG_LOG z wartością true zapisuje błędy do pliku debug.log w katalogu treści, czyli zwykle w wp-content/debug.log. WP_DEBUG_DISPLAY z wartością false sprawia, że komunikaty nie pojawiają się na ekranie. Dokumentacja zawiera jeszcze stałą SCRIPT_DEBUG, ale przy szukaniu przyczyny białego ekranu nie jest ona potrzebna.

1. Zalogowanie się do menedżera plików w panelu hostingu albo połączenie z serwerem przez FTP lub SFTP.
2. Pobranie pliku wp-config.php na dysk jako kopii, do której da się wrócić.
3. Otwarcie pliku na serwerze w edytorze i odszukanie wiersza z WP_DEBUG. W większości instalacji istnieje już wiersz define( 'WP_DEBUG', false ); i wystarczy zmienić w nim false na true.
4. Dopisanie pod nim pozostałych trzech wierszy. Cały zestaw musi się znaleźć przed wierszem z komentarzem zaczynającym się od słów „That’s all, stop editing!”.
5. Zapisanie pliku i ponowne otwarcie w przeglądarce adresu, pod którym widać awarię.
6. Otwarcie katalogu wp-content i pobranie pliku debug.log, który powinien się tam pojawić po odświeżeniu strony.

W tym kroku najczęściej zawodzą dwie rzeczy. Pierwsza to zdublowana stała: jeżeli w pliku zostanie stary wiersz z false i nowy z true, zadziała tylko jeden z nich, a w dzienniku pojawi się ostrzeżenie. Druga to cudzysłowy drukarskie wklejone z edytora tekstu. W pliku muszą być proste apostrofy, dlatego do edycji należy używać edytora z panelu hostingu albo zwykłego notatnika.

Nie polecam ustawiania WP_DEBUG_DISPLAY na true na działającej stronie firmowej. Komunikaty błędów ujawniają ścieżki na serwerze i nazwy wtyczek, a widzi je każdy odwiedzający. Zapis do pliku daje te same informacje bez tego ryzyka.

Jak czytać plik debug.log?

Plik otwiera się w zwykłym edytorze tekstu. Najnowsze wpisy są na końcu, każdy zaczyna się od daty i godziny. Ostrzeżenia i uwagi można na razie pominąć. Liczą się wiersze zawierające słowa „PHP Fatal error” albo „PHP Parse error”, bo to one zatrzymują witrynę.

W takim wierszu najważniejsza jest ścieżka do pliku. Jeżeli zawiera wp-content/plugins/nazwa-wtyczki/, winna jest ta wtyczka. Jeżeli zawiera wp-content/themes/nazwa-motywu/, winny jest motyw. Ścieżka prowadząca do wp-includes lub wp-admin wskazuje na uszkodzone pliki samego WordPressa albo na dodatek, który wywołuje je w nieprawidłowy sposób.

Treść komunikatu podpowiada rodzaj błędu. Wpis „Allowed memory size of … bytes exhausted” oznacza wyczerpany limit pamięci. „Parse error: syntax error” oznacza błąd składni w pliku, zwykle po ręcznej edycji albo przy zbyt starej wersji PHP. „Call to undefined function” wskazuje na brakującą funkcję, czyli najczęściej na niezgodność wtyczki z motywem, z inną wtyczką albo z wersją PHP.

Kto na tym etapie woli nie zajmować się tym samodzielnie, może po prostu zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl. Chętnie przejmę sprawę: znajdę przyczynę białego ekranu, przywrócę stronę i zabezpieczę ją przed powtórką.

Jak wyłączyć wtyczki, gdy nie da się wejść do kokpitu?

Gdy kokpit działa, sprawa jest prosta: w „Wtyczki” > „Zainstalowane wtyczki” wyłącza się wszystkie dodatki, a potem włącza po jednym i po każdym sprawdza stronę. Gdy kokpit również pokazuje biały ekran, to samo robi się na serwerze, przez zmianę nazwy katalogu. WordPress nie znajduje wtedy plików wtyczek i ich nie uruchamia.

Jeżeli dziennik błędów albo wiadomość e-mail wskazały konkretną wtyczkę, wystarczy zmienić nazwę tylko jej folderu. W katalogu wp-content/plugins należy odszukać folder tej wtyczki i dopisać do jego nazwy końcówkę, na przykład -wylaczona. Strona powinna wrócić od razu po odświeżeniu.

Gdy wadliwa wtyczka nie jest znana, wyłącza się wszystkie wtyczki jednocześnie. Dokumentacja WordPressa opisuje ten sposób wprost: katalog plugins dostaje nową nazwę, a po zalogowaniu do kokpitu wtyczki włącza się pojedynczo.

1. Otwarcie na serwerze katalogu wp-content i zmiana nazwy folderu plugins na plugins_old.
2. Otwarcie strony w oknie prywatnym. Jeżeli się wyświetla, przyczyną jest jedna z wtyczek.
3. Zalogowanie się do kokpitu i wejście w „Wtyczki” > „Zainstalowane wtyczki”. WordPress odnotuje brak plików i oznaczy wszystkie wtyczki jako wyłączone.
4. Przywrócenie na serwerze pierwotnej nazwy folderu, czyli plugins. Wtyczki wracają na listę, ale pozostają wyłączone.
5. Włączanie wtyczek po jednej przyciskiem „Włącz” i odświeżanie strony po każdej z nich.
6. Zatrzymanie się w chwili, gdy biały ekran wróci. Ostatnio włączona wtyczka jest przyczyną, a jej folder trzeba ponownie wyłączyć zmianą nazwy.

Krok trzeci jest istotny. Jeżeli nazwa folderu zostanie przywrócona bez wcześniejszego wejścia na listę wtyczek, WordPress może uruchomić je wszystkie na nowo, razem z wadliwą. Kolejność ma tu znaczenie.

Zmiana nazwy katalogu nie usuwa ustawień wtyczek, bo te są zapisane w bazie danych. Nie należy natomiast usuwać folderu wtyczki na próbę. Niektóre dodatki przy usuwaniu czyszczą swoje dane, a przy sklepie lub formularzach oznaczałoby to realną stratę.

Co zrobić z wtyczką, która wywołuje błąd?

Po ustaleniu wadliwej wtyczki są trzy drogi. Pierwsza to aktualizacja: jeżeli autor wydał poprawkę, problem znika po jej wgraniu. Druga to powrót do poprzedniej wersji wtyczki z kopii zapasowej, do czasu wydania poprawki. Trzecia to zastąpienie dodatku innym, jeśli nie jest już rozwijany.

Jak przełączyć motyw na domyślny?

Jeżeli po wyłączeniu wszystkich wtyczek biały ekran nie znika, następny w kolejności jest motyw. Sprawdza się go przez chwilowe włączenie jednego z motywów domyślnych WordPressa, czyli tych z rodziny „Twenty”. Motyw domyślny zmienia wygląd strony, ale nie usuwa treści, wpisów ani produktów.

Przy działającym kokpicie wystarczy wejść w „Wygląd” > „Motywy” i kliknąć „Włącz” przy motywie domyślnym. Gdy kokpit nie działa, dokumentacja WordPressa zaleca wejście przez FTP do katalogu wp-content/themes i zmianę nazwy folderu aktywnego motywu.

1. Otwarcie na serwerze katalogu wp-content/themes i sprawdzenie, czy znajduje się w nim folder któregoś motywu domyślnego. Jeżeli go nie ma, trzeba go tam wgrać z paczki pobranej z katalogu motywów WordPressa.
2. Zmiana nazwy folderu aktywnego motywu przez dopisanie końcówki, na przykład -test. Przy motywie potomnym zaczyna się od folderu motywu potomnego.
3. Zalogowanie się do kokpitu i wejście w „Wygląd” > „Motywy”.
4. Kliknięcie „Włącz” przy motywie domyślnym, jeżeli WordPress nie przełączył się na niego sam.
5. Otwarcie strony w oknie prywatnym. Jeżeli treść się wyświetla, choć w innym wyglądzie, przyczyna leży w motywie.

Jeśli winny okazał się motyw, trzeba ustalić, co w nim zmieniono. Po ręcznej edycji functions.php najszybciej jest przywrócić ten jeden plik z kopii. Po aktualizacji motywu pomaga wgranie poprzedniej wersji albo poprawki od producenta. Folderowi przywraca się pierwotną nazwę dopiero wtedy, gdy poprawione pliki są już na serwerze.

Jak zwiększyć limit pamięci i zmienić wersję PHP?

Te dwie przyczyny mają wspólną cechę: nie leżą w plikach witryny, tylko w ustawieniach serwera. Część da się zmienić z poziomu wp-config.php, resztę w panelu hostingu.

Limit pamięci PHP

O tej przyczynie świadczy wpis „Allowed memory size of … bytes exhausted” w dzienniku. Dokumentacja WordPressa podaje, że WordPress sam próbuje ustawić limit na 40 MB dla pojedynczej witryny i 64 MB dla sieci witryn, a wyższą wartość można wskazać stałą WP_MEMORY_LIMIT. Wiersz wygląda tak:

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

Dokumentacja jako przykłady podaje wartości 64M i 96M, a dla rozbudowanych stron firmowych i sklepów w praktyce stosuje się wyższe, takie jak w przykładzie powyżej. Wiersz musi się znaleźć w wp-config.php przed wierszem wczytującym plik wp-settings.php, czyli najbezpieczniej tuż obok stałych debugowania. Dla samego kokpitu istnieje osobna stała WP_MAX_MEMORY_LIMIT, ustawiana w ten sam sposób.

Ta stała nie przebije ograniczenia nałożonego przez hosting. Dokumentacja zaznacza, że niektórzy dostawcy nie pozwalają podnosić limitu z poziomu WordPressa i wtedy trzeba zwrócić się do nich. W wielu panelach limit ustawia się samodzielnie w ustawieniach PHP, w polu o nazwie memory_limit.

Aktualną wartość widać w kokpicie w „Narzędzia” > „Stan witryny”, na karcie „Informacja”, w sekcji „Serwer”, w wierszu „Limit pamięci PHP”. Jeżeli po podniesieniu limitu błąd wraca, przyczyną nie jest zbyt niski limit, tylko dodatek, który zużywa pamięć bez końca. Dalsze podnoszenie wartości niczego wtedy nie da i trzeba wrócić do sprawdzania wtyczek.

Wersja PHP w panelu hostingu

Podejrzenie pada na wersję PHP, gdy awaria zbiegła się ze zmianą wersji u dostawcy hostingu albo gdy dziennik pokazuje błędy składni w plikach, których nikt nie edytował. Bieżącą wersję podaje ten sam ekran „Stan witryny”, w wierszu „Wersja PHP”. Jeżeli kokpit nie działa, wersję widać w panelu hostingu.

Wersję PHP zmienia się w panelu hostingu, a nie w WordPressie. Każdy dostawca nazywa to miejsce nieco inaczej, zwykle jest to pozycja z ustawieniami PHP przypisana do domeny, z listą wyboru wersji. Jeżeli nie da się jej znaleźć, najkrótszą drogą jest pytanie do pomocy technicznej hostingu.

Rozsądne postępowanie wygląda tak: przy awarii po przejściu na nowszą wersję wraca się do poprzedniej, przywraca działanie strony, a potem aktualizuje wtyczki i motyw i ponawia próbę. Pozostawanie na stałe przy wersji PHP, która nie jest już wspierana, jest rozwiązaniem tymczasowym, bo taka wersja nie otrzymuje poprawek bezpieczeństwa. Wymagania poszczególnych wtyczek widać w ich opisach, w wierszu o wymaganej wersji PHP.

Dziennik błędów serwera

Gdy plik debug.log nie powstaje, informacji trzeba szukać w dzienniku samego serwera. Większość paneli hostingowych udostępnia go w dziale poświęconym logom albo statystykom, często pod nazwą „error log”. Bywa też zapisywany jako plik error_log w katalogu witryny.

Dziennik serwera pokazuje błędy, do których WordPress nie ma dostępu: nieprawidłową regułę w pliku .htaccess, brak uprawnień do plików, przekroczony czas wykonywania skryptu albo wyczerpane zasoby konta. Wpisy czyta się tak samo jak w debug.log: najnowsze na końcu, a w nich ścieżka do pliku i rodzaj błędu.

Jeżeli strona zamiast białego ekranu pokazuje błąd serwera, dokumentacja WordPressa wskazuje na plik .htaccess jako najczęstszą przyczynę. Jego nazwę zmienia się wtedy na .htaccess_old, a po odzyskaniu dostępu do kokpitu wchodzi się w „Ustawienia” > „Bezpośrednie odnośniki” i klika „Zapisz zmiany”. WordPress utworzy nowy, poprawny plik.

Co zrobić, gdy uszkodzony jest plik, i kiedy przywrócić kopię zapasową?

Uszkodzone pliki samego WordPressa podejrzewa się wtedy, gdy wyłączenie wtyczek i zmiana motywu niczego nie dały, a dziennik wskazuje na katalogi wp-includes lub wp-admin. Najczęściej jest to skutek aktualizacji przerwanej w połowie.

Pierwsza rzecz do sprawdzenia to plik .maintenance w głównym katalogu witryny. WordPress tworzy go na czas aktualizacji i sam usuwa po jej zakończeniu. Jeżeli aktualizacja została przerwana, plik zostaje, a strona pokazuje komunikat o pracach konserwacyjnych. Dokumentacja zaleca w takiej sytuacji jego usunięcie.

Drugi sposób to ponowne wgranie plików systemowych. Przy działającym kokpicie robi się to w „Kokpit” > „Aktualizacje”, przyciskiem ponownej instalacji bieżącej wersji. Bez kokpitu dokumentacja zaleca wgranie przez FTP katalogów wp-admin i wp-includes ze świeżej paczki WordPressa w tej samej wersji. Nie wolno przy tym nadpisywać katalogu wp-content ani pliku wp-config.php, bo to w nich znajdują się motywy, wtyczki, przesłane pliki i dane połączenia z bazą.

Przywracanie kopii zapasowej

Kopia zapasowa jest wyjściem wtedy, gdy przyczyny nie udało się ustalić w rozsądnym czasie, gdy strona sprzedaje i każda godzina przestoju oznacza stratę, albo gdy uszkodzeń jest więcej niż jedno. Trzeba jednak wiedzieć, co się traci: wszystko, co powstało między wykonaniem kopii a awarią.

W sklepie internetowym są to zamówienia, płatności i konta klientów. Na stronie firmowej są to zgłoszenia z formularzy, komentarze i nowe wpisy. Dlatego przy sklepie pełne przywracanie bazy danych jest krokiem ryzykownym. Bezpieczniej jest przywrócić same pliki, czyli katalog wp-content, i pozostawić bazę nietkniętą, bo biały ekran rzadko ma źródło w bazie.

1. Wykonanie kopii obecnego, uszkodzonego stanu: plików i bazy danych. Przyda się, gdyby przywrócona wersja okazała się niepełna.
2. Otwarcie w panelu hostingu działu z kopiami zapasowymi albo ekranu wtyczki do kopii, jeżeli kokpit działa w trybie awaryjnym.
3. Wybranie najnowszej kopii sprzed awarii. Data kopii powinna poprzedzać zmianę, po której pojawił się błąd.
4. Przywrócenie w pierwszej kolejności samych plików i sprawdzenie strony w oknie prywatnym.
5. Przywrócenie bazy danych tylko wtedy, gdy same pliki nie pomogły, i ze świadomością utraty nowszych danych.
6. Zapisanie, która aktualizacja lub zmiana poprzedzała awarię, żeby nie powtórzyć jej na działającej stronie bez testu.

Kopia przywraca stronę, ale nie usuwa przyczyny. Jeżeli błąd wywołała automatyczna aktualizacja wtyczki, po przywróceniu kopii ta sama aktualizacja może się wykonać ponownie. Automatyczne aktualizacje podejrzanego dodatku należy więc wyłączyć na liście wtyczek do czasu wyjaśnienia sprawy.

Jak posprzątać po naprawie i sprawdzić, że strona działa?

Przywrócona strona główna nie oznacza jeszcze końca pracy. Tryb debugowania pozostawiony na stałe obciąża serwer zapisem do pliku, który rośnie bez ograniczeń, a sam plik debug.log bywa dostępny z zewnątrz pod przewidywalnym adresem. Zawiera ścieżki serwera i nazwy wtyczek, czyli informacje przydatne przy próbie włamania.

1. Otwarcie wp-config.php i przywrócenie wiersza define( 'WP_DEBUG', false );. Pozostałe trzy dopisane wiersze należy usunąć albo zmienić w WP_DEBUG_LOG wartość true na false.
2. Pobranie pliku wp-content/debug.log na dysk, jeżeli może się przydać do zgłoszenia, a następnie usunięcie go z serwera.
3. Usunięcie folderów pomocniczych utworzonych podczas naprawy, takich jak plugins_old, oraz plików z końcówką _old, jeżeli nie są już potrzebne.
4. Wyczyszczenie pamięci podręcznej: we wtyczce do pamięci podręcznej, w panelu hostingu i w usłudze CDN, jeżeli strona z niej korzysta.
5. Sprawdzenie w oknie prywatnym strony głównej, podstrony oferty, wpisu na blogu, formularza kontaktowego oraz, w sklepie, koszyka i zamówienia próbnego.
6. Wejście w „Narzędzia” > „Stan witryny” i przejrzenie listy problemów krytycznych.

Naprawa zadziałała, jeżeli strona otwiera się dla osoby niezalogowanej, kokpit działa bez trybu awaryjnego, a w dzienniku serwera nie przybywa nowych błędów krytycznych. Dobrze jest wrócić do dziennika po dobie i upewnić się, że błąd nie pojawia się przy czynnościach wykonywanych w tle, takich jak zaplanowane kopie czy wysyłka poczty.

Jeżeli strona była niedostępna dłużej niż kilka godzin, radzę sprawdzić także jej widoczność w wyszukiwarce. Krótka przerwa zwykle nie zostawia śladu, ale po dłuższej robot Google mógł trafić na błędy. Jak to zweryfikować, opisuję w tekście o tym, jak sprawdzić, czy strona jest zaindeksowana w Google.

Po awarii często wychodzi na jaw, że witryna od dawna pracowała na granicy możliwości serwera. Jeżeli przyczyną był limit pamięci albo przeciążona wtyczka, kolejnym krokiem powinno być ustalenie, co spowalnia WordPressa, bo te same elementy odpowiadają zwykle za wolne ładowanie i za wyczerpywanie pamięci.

Jak zapobiegać białemu ekranowi w przyszłości?

Większość białych ekranów pojawia się po aktualizacji wykonanej bezpośrednio na działającej stronie. Skuteczna ochrona polega więc na dwóch nawykach: aktualizacje sprawdza się najpierw na kopii testowej, a przed każdą zmianą wykonuje się kopię zapasową.

Kopia testowa to osobna instalacja z tymi samymi plikami i tą samą bazą, dostępna pod innym adresem i zamknięta przed wyszukiwarkami. Wielu dostawców hostingu udostępnia ją w panelu jako środowisko testowe. Dokumentacja WordPressa zaleca to samo przy każdej pracy z debugowaniem: przed zmianami w witrynie trzeba mieć środowisko testowe albo aktualną kopię.

Na kopii testowej wykonuje się aktualizacje wtyczek, motywu, WordPressa oraz zmianę wersji PHP, a potem przegląda najważniejsze podstrony i formularze. Dopiero gdy wszystko działa, te same aktualizacje przenosi się na właściwą stronę. Przy większych zmianach, takich jak zmiana motywu lub serwera, obowiązują te same zasady co przy migracji strony bez utraty pozycji w Google.

Kopie zapasowe powinny powstawać automatycznie i być przechowywane poza serwerem, na którym działa strona. Kopia leżąca na tym samym koncie przepada razem z nim. Raz na jakiś czas trzeba też kopię próbnie przywrócić na środowisku testowym, bo kopia, której nikt nigdy nie odtworzył, jest tylko założeniem.

Pozostałe zasady są proste. Wtyczek powinno być tyle, ile jest naprawdę potrzebnych, i wszystkie powinny pochodzić ze sprawdzonych źródeł. Dodatki od dawna nieaktualizowane należy zastąpić innymi, zanim przestaną działać z nową wersją PHP. Kodu nie wkleja się do plików motywu na działającej stronie, a adres administracyjny w ustawieniach powinien należeć do osoby, która faktycznie czyta tę pocztę.

Najczęstsze pytania

Czy biały ekran oznacza utratę treści strony?

W typowym przypadku nie. Wpisy, podstrony, produkty i ustawienia są zapisane w bazie danych, a przesłane zdjęcia w katalogu wp-content/uploads. Biały ekran oznacza, że kod wtyczki, motywu lub WordPressa przerwał pracę, a nie że dane zniknęły. Po usunięciu przyczyny treść wraca w niezmienionej postaci.

Dlaczego strona działa, a biały ekran widać tylko w kokpicie?

Kokpit wczytuje inne części wtyczek niż strona widoczna dla odwiedzających i zużywa więcej pamięci. Błąd w części administracyjnej wtyczki albo zbyt niski limit pamięci daje więc awarię tylko po zalogowaniu. Postępowanie jest takie samo: dziennik błędów, a następnie wyłączanie wtyczek przez zmianę nazwy folderu.

Nie dotarła wiadomość z linkiem do trybu odzyskiwania. Co wtedy?

Wiadomość trafia na administracyjny adres e-mail witryny, więc najpierw trzeba sprawdzić folder ze spamem na tej skrzynce. Jeżeli serwer w ogóle nie wysyła poczty albo adres jest nieaktualny, tryb odzyskiwania nie będzie dostępny tą drogą. Pozostaje wtedy naprawa przez pliki: dziennik błędów w wp-config.php i zmiana nazwy folderu wtyczki lub motywu.

Czy zmiana nazwy folderu plugins usuwa ustawienia wtyczek?

Nie. Zmiana nazwy jedynie uniemożliwia WordPressowi wczytanie plików. Ustawienia wtyczek są przechowywane w bazie danych i pozostają w niej, dopóki wtyczka nie zostanie usunięta z poziomu kokpitu. Po przywróceniu nazwy folderu i ponownym włączeniu wtyczki działają z dotychczasową konfiguracją.

Czy można zostawić włączony WP_DEBUG na stałe?

Na działającej stronie firmowej nie jest to wskazane. Plik debug.log stale rośnie, zajmuje miejsce i może być odczytany z zewnątrz, jeżeli serwer go nie chroni. Tryb debugowania włącza się na czas szukania przyczyny, a po naprawie wyłącza i usuwa plik dziennika z serwera.

Czy biały ekran może być skutkiem włamania?

Może, choć jest to rzadsza przyczyna niż zwykły konflikt po aktualizacji. Niepokoić powinny pliki o nieznanych nazwach w katalogach WordPressa, zmiany w plikach, których nikt nie edytował, oraz nowe konta administratorów. W takiej sytuacji samo przywrócenie działania nie wystarcza: trzeba zmienić hasła do kokpitu, bazy i serwera oraz wgrać czyste pliki WordPressa, wtyczek i motywu.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

To zupełnie zrozumiałe. Opisane czynności wymagają spokoju i kilku wolnych godzin, a w firmie zwykle brakuje jednego i drugiego. Chętnie zrobię to od początku do końca: znajdę przyczynę białego ekranu, przywrócę stronę i zabezpieczę ją przed powtórką.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i w kilku zdaniach opisać sprawę. Odpowiadam osobiście i od razu mówię, co da się zrobić.