Biały ekran śmierci WordPress: przewodnik po odzyskiwaniu

WordPress, podobnie jak MacOS, a nawet teraz Windows, ma niesławny „biały ekran śmierci” lub w skrócie „WSOD”. WSOD pojawia się, gdy coś pójdzie nie tak. Masz do czynienia z pustym lub w większości pustym białym ekranem z nieznanych przyczyn. Co teraz?

Czym jest biały ekran śmierci WordPress (WSOD)?

Jest mało prawdopodobne, że napotkasz „biały ekran śmierci” (WSOD) na stronie WordPress w normalnych warunkach. Jest to po prostu pusty biały ekran, który pojawia się zamiast publicznego interfejsu front-end lub back-end witryny WordPress. Oznacza to, że WordPress uległ awarii i nie ładuje się poprawnie.

Czemu? Co poszło nie tak?

Odkąd WordPress 5.2 został wydany w maju 2019 r., WordPress ma tryb odzyskiwania, który chroni Cię przed WSOD. Bez trybu odzyskiwania problemy ze zgodnością generowałyby wiele WSOD i frustrowali użytkowników WordPress. Jeśli Twój serwer korzysta z wersji PHP lub MySQL, która nie jest obsługiwana przez instalowaną wtyczkę, motyw lub rozszerzenie, zamiast psuć witrynę, uruchomisz tryb odzyskiwania. Obecnie błąd PHP Out-of-Memory (OOM) jest prawdopodobnie najczęstszym pozostałym scenariuszem, który omija ochronę WSOD, pozostawiając całkowicie pusty ekran.

Skontaktowałem się z głównym współpracownikiem WordPress, Mariusem Jensenem, aby dowiedzieć się, co jeszcze może powodować prawdziwy WSOD w dzisiejszych czasach. Marius jest autorem wtyczki Site Health (obecnie Health Check and Troubleshooting), której koncepcja i funkcje ostatecznie trafiły do ​​rdzenia WordPress. (W ten sposób uzyskaliśmy tryb odzyskiwania i inne zabezpieczenia.) Marius potwierdził, że jedynym sposobem na awarię WordPressa z całkowicie pustym ekranem jest przerwanie przepływu wykonywania PHP, aby moduł obsługi błędów krytycznych nie mógł działać tak, jak powinien. Zerwanie połączenia między PHP a serwerem HTTP pozwoli to osiągnąć. Nie otrzymasz żadnych informacji zwrotnych dotyczących rozwiązywania problemów na ekranie. Byłoby to frustrujące, ale jeśli po prostu pracujesz w WordPressie, instalując i konfigurując wtyczki, jest to mało prawdopodobne.

Czy biały ekran śmierci oznacza, że ​​WordPress został zhakowany?

Nie, WSOD nie oznacza, że ​​złapali cię złoczyńcy. Jednak w rzadkich przypadkach może to być efekt uboczny naruszenia bezpieczeństwa. Jeśli uważasz, że hakerzy włamali się do Twojej witryny, przejdź do przewodnika Kathy Zant, Jak wyczyścić zhakowaną witrynę WordPress.

Błąd kodowania PHP, konflikt między dwiema lub więcej wtyczkami lub problem w środowisku serwera to najbardziej prawdopodobne przyczyny WSOD. Na szczęście nie są to katastrofy! Twoja witryna i jej zawartość nie zostały utracone. Jeśli chcesz, możesz samodzielnie naprawić WSOD.

W tym artykule przejdziemy do listy możliwych diagnoz i lekarstw na WSOD. Dowiesz się, jak przywrócić swoją witrynę WordPress do życia. Dowiesz się również, jak działa WordPress na głębszym poziomie.

Zobacz podgląd

Biały ekran śmierci WordPress: czy ja to zrobiłem?

Tak. Biały ekran śmierci jest prawdopodobnie wynikiem czegoś TY zrobiłeś na swojej stronie WordPress.

Przyczynę WSOD zwykle można znaleźć we wtyczce WordPress, którą właśnie zainstalowałeś i aktywowałeś. Lub może to być wynikiem ostatniej aktualizacji. Nowo dodana lub zaktualizowana wtyczka może powodować konflikt z inną wtyczką. W tym scenariuszu jedna wtyczka próbuje zrobić to samo co inna lub działa w sprzecznych celach.

Jeśli wtyczka, motyw lub nieprawidłowe fragmenty kodu PHP powodują błąd krytyczny, możesz otrzymać komunikat WSOD. Mogą zawierać błąd składni, błąd lub kod, który nie jest zgodny z używaną wersją PHP. Jeśli Ty lub Twój host właśnie zaktualizowaliście swoją wersję PHP — to dobrze! — niekompatybilne wtyczki zaczną generować błędy i mogą spowodować awarię Twojej witryny za pomocą WSOD. Jeśli używasz WordPress 5.2 lub nowszego, tak jak powinieneś, problemy z kompatybilnością aktywują tryb odzyskiwania, który jest o wiele bardziej pomocny niż prawdziwy WSOD.

Zazwyczaj winowajcą jest to, co właśnie zostało zmienione za pomocą wtyczki, motywu lub niestandardowego kodu.

Ponieważ WSOD jest często odpowiedzią na zmiany wprowadzone ostatnio (lub bardzo niedawno), które wpływają na funkcjonalność Twojej witryny. Przejrzyj wszystkie ostatnie zmiany. Skoncentruj się na zmianach, które wydają się najprawdopodobniej powodować problem. Jeśli właśnie zainstalowałeś nową wtyczkę lub zmodyfikowałeś kod motywu, są to pierwsze miejsca, w których należy sprawdzić, co mogło pójść nie tak.

Kiedy WordPress jest tylko w większości martwy

Wszystkie WSOD nie są równe, a niektóre nie są nawet prawdziwymi WSOD.

Zamiast całkowicie białego ekranu może pojawić się komunikat o błędzie. Może to być komunikat o błędzie serwera dotyczący błędu HTTP 500 lub utraty połączenia z bazą danych. Może to być krytyczny komunikat o błędzie z WordPress. Lub Twoja witryna może ładować się normalnie dla odwiedzających, ale kiedy próbujesz się zalogować, pojawia się biały ekran śmierci. W innych przypadkach może być odwrotnie: możesz zalogować się do pulpitu nawigacyjnego WordPress, ale publiczny interfejs Twojej witryny daje wszystkim pusty ekran.

Jeśli twoje doświadczenie z WSOD pasuje do któregoś z tych opisów, to dobra wiadomość! Twoja witryna jest tylko w większości martwa. Reanimacja nie będzie trudna.

Jeśli znajdziesz się przed całkowicie pustym białym ekranem podczas odwiedzania witryny WordPress lub próby zalogowania się, to jest prawdziwy WSOD. Będziesz musiał kopać trochę głębiej, aby ustalić, co to powoduje.

Tryb odzyskiwania WordPress i biały ekran śmierci

Na szczęście dla każdego, kto miał do czynienia z WSOD, tryb odzyskiwania został wprowadzony w WordPress 5.2, aby się go pozbyć. Tryb odzyskiwania przechwytuje wiele błędów krytycznych i pomaga je naprawić. Jeśli nie używasz najnowszej głównej wersji rdzenia WordPress, zacznij od tego. Bądź na bieżąco!

Dzięki trybowi odzyskiwania WordPress rzadko zdarza się zobaczyć całkowicie pusty biały ekran, gdy coś pójdzie nie tak. Od wersji WordPress 6.1 częściej zobaczysz białe okno na szarym ekranie z następującym komunikatem:

Starsze wersje WordPressa będą wyświetlać podobne komunikaty, takie jak „Witryna ma problemy techniczne”.

Jeśli przejdziesz do adresu URL zaplecza /wp-admin , pojawi się również powiadomienie z prośbą o sprawdzenie konta e-mail administratora w celu uzyskania dalszych informacji:

W innych przypadkach możesz zobaczyć biały ekran z pogrubionym tekstem opisującym „Wewnętrzny błąd serwera” z pewnym wyjaśnieniem i wskazówkami dotyczącymi naprawy witryny.

Witamy w Recovery

To jest tryb odzyskiwania. WordPress próbuje pomóc Ci stanąć na nogi.

Pierwszą rzeczą do zrobienia jest sprawdzenie adresu e-mail powiązanego z kontem administratora WordPress. WordPress próbuje zidentyfikować krytyczne błędy PHP w całym wykonywanym kodzie.

Jeśli to możliwe, WordPress „wstrzyma” wtyczkę lub inny kod, który działa nieprawidłowo. WordPress uniemożliwi wykonanie złego kodu. Następnie przekaże szczegóły administratorom pocztą elektroniczną.

W e-mailu dotyczącym trybu odzyskiwania znajdziesz instrukcje i tymczasowy link do logowania do WordPress w trybie odzyskiwania. (Ten link jest ważny przez 24 godziny. Po tym czasie, jeśli w witrynie nadal występuje błąd krytyczny, zostanie wysłany nowy).

WSKAZÓWKA PRO: Jeśli nie otrzymasz e-maila z trybem odzyskiwania, mimo to możesz zalogować się do WordPress w trybie odzyskiwania, dodając następujący adres do adresu URL swojej witryny podstawowej, gdy jesteś zalogowany jako administrator: /wp-login.php?action=entered_recovery_mode .

Oto Twoja szansa na dalsze zbadanie sprawy. Jeśli tryb odzyskiwania zidentyfikował określoną wtyczkę jako przyczynę WSOD, dezaktywuj ją. Spowoduje to przywrócenie Twojej witryny dla wszystkich. Następnie możesz zbadać wszelkie znane problemy z tą wtyczką. Sprawdź, czy jest dostępna aktualizacja. Dotrzyj do osób odpowiedzialnych za jego utrzymanie.

Nie każdy biały ekran śmierci jest taki sam w WordPress

W kilku wyjątkowych przypadkach coś poszło nie tak w innym miejscu WordPress lub w środowisku serwera. Proces aktualizacji lub instalacji mógł się zawiesić, przez co witryna utknęła w trybie konserwacji. Ty, Twój dostawca usług hostingowych lub zainstalowana wtyczka mogliście zmodyfikować pliki php.ini lub .htaccess , co przyniosło nieoczekiwane rezultaty. Twoje obecne środowisko może nie obsługiwać wymagań nowo zainstalowanej wtyczki.

Tryb odzyskiwania WordPress nie jest w stanie poradzić sobie z takimi sytuacjami, ale generuje widoczne komunikaty o błędach na białym ekranie. Interfejs użytkownika witryny może być niedostępny, ale ekran logowania administratora i interfejs zaplecza mogą działać normalnie.

To nie są prawdziwe sytuacje WSOD, ale są równie irytujące. Zwykle powoduje je jeden z następujących warunków:

1. Utknąłeś w trybie konserwacji

Podczas aktualizacji rdzenia, wtyczek lub motywów WordPress, WordPress przechodzi w „Tryb konserwacji”. Przeglądanie dowolnej części witryny spowoduje wyświetlenie szarego ekranu z białym oknem wiadomości, które mówi:

Czasami nie można tego wyjaśnić w ciągu minuty, ale zarządzany jakością hosting WordPress zauważy to i naprawi to za pomocą zautomatyzowanego procesu. Jeśli odczekałeś kilka minut bez zmian, możesz wyjść z trybu konserwacji, usuwając plik .maintenance w folderze głównym sieci/aplikacji, w którym jest zainstalowany WordPress. (Aby to zobaczyć, może być konieczne włączenie przeglądania „niewidocznych” plików z kropką w nazwie pliku).

Jeśli nie ma pliku .maintenance , witryna zostanie załadowana zgodnie z oczekiwaniami.

2. Osiągnięto limit przesyłanych plików lub rozmiarów postów

Twoja witryna może przekroczyć limit czasu i wyświetlić biały ekran podczas procesu przesyłania, publikowania lub przesyłania formularza, ponieważ wysyłasz zbyt dużo danych.

Rozwiązanie: Zwiększ limit zawartości posta w wp-config.php :

 ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000);

Rozwiązanie: Zwiększ limit wysyłanych plików i rozmiarów postów w php.ini :

 upload_max_filesize = 256M
post_max_size = 256M

Pomocne może być również wydłużenie czasu (w sekundach) przed upływem limitu czasu przesyłania postów lub formularzy. Możliwe jest również zwiększenie czasu, jaki PHP ma na wykonywanie skryptów i analizowanie danych wejściowych. Dodatkowo możemy zwiększyć liczbę zmiennych dozwolonych w przesyłaniu formularza. Na koniec możemy określić limit czasu, po którym PHP potraktuje przesłane dane jako śmieci:

 maksymalny_czas_wykonania = 300
max_input_time = 300
max_zmienne_wejściowe = 1000
sesja.gc_maxlifetime = 1000

Lub w .htaccess , httpd.conf lub virtualhost :

 php_value upload_max_filesize 256M
php_value post_max_size 256M
php_value max_execution_time 300
php_value max_input_time 300
php_value max_input_vars 1000
php_value sesja.gc_maxlifetime 1000

Lub w niestandardowym fragmencie kodu dla WordPress lub pliku motywu functions.php :

 @ini_set( 'upload_max_filesize', '256M' );
@ini_set( 'post_max_size', '256M' );
@ini_set( 'max_execution_time', '300' );
@ini_set('max_input_time', '300' );
@ini_set('max_input_vars', '1000' );
@ini_set('sesja.gc_maxlifetime', '1000' );

Wartości pamięci i czasu w tych parametrach są tylko zaleceniami. Aby upewnić się, że działają i sprawdzić ich aktualne wartości, użyj narzędzia Site Health w interfejsie administratora WordPress.

Wraz z trybem odzyskiwania WordPress 5.2 wprowadził narzędzie Site Health. Jest to bardzo pomocne przy diagnozowaniu problemów i uzyskiwaniu informacji technicznych o ustawieniach witryny i środowisku serwera. Znajdź go w menu administratora w sekcji Narzędzia > Kondycja witryny. Możesz także skorzystać z rozszerzonych funkcji wtyczki sprawdzania stanu i rozwiązywania problemów dla WordPress.

3. Brak pamięci w PHP

PHP to język skryptowy po stronie serwera, na którym oparty jest rdzeń WordPressa. WSOD pojawia się, jeśli nie ma wystarczającej ilości pamięci dla PHP do uruchomienia WordPressa i aktywnych wtyczek. Może to być wskazane w komunikacie o błędzie lub w dzienniku.

W zależności od planu hostingowego możesz zwiększyć limit pamięci PHP dla wszystkich aplikacji na swoim serwerze lub określonej instancji WordPress. Jeśli nie wiesz, co robić, poproś o pomoc zespół pomocy technicznej gospodarza.

wp-config.php

Zwykle dodanie następującego ustawienia do pliku wp-config.php w folderze WordPress spowoduje ustawienie limitu pamięci front-end dla WordPress na 256 MB w tym przykładzie:

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

128 do 256 MB powinno być więcej niż wystarczające. Możesz także być w stanie zdefiniować maksymalną lub wewnętrzną pamięć przydzieloną PHP (256 MB w następnym przykładzie), dodając również następujący wiersz do wp-config.php :

 zdefiniuj('WP_MAX_MEMORY_LIMIT', '256M');

Druga liczba to maksymalny limit pamięci określający całkowitą pamięć, jaką PHP ma do dyspozycji. Pierwsza liczba to pamięć dla WordPress działającego w ramach tego większego limitu PHP. Maksymalny limit pamięci PHP powinien być równy lub wyższy od limitu pamięci aplikacji WordPress.

php.ini

Innym sposobem na zdefiniowanie maksymalnego limitu pamięci PHP jest ustawienie w pliku php.ini znajdującym się w folderze WordPress:

 limit_pamięci = 256M

Upewnij się, że na początku wiersza nie ma średnika! Zwróć uwagę, że php.ini wpłynie tylko na wystąpienie WordPressa (lub dowolnej innej aplikacji PHP) działającej w folderze lub pod folderem, w którym znajduje się plik php.ini . Jeśli masz dostęp do swojego serwera lub głównego katalogu internetowego, plik php.ini znajdujący się tam plik php.ini będzie zarządzał ustawieniami środowiskowymi dla wszystkich aplikacji PHP, chyba że mają one własny plik php.ini , który określa inne warunki.

.htaccess

Trzecim sposobem na zdefiniowanie limitu pamięci PHP jest użycie pliku .htaccess w folderze WordPress, jeśli używasz Apache lub Litespeed jako serwera HTTP. Podobnie jak w powyższych przykładach, .htaccess musi mieć linię bez komentarza, taką jak ta, aby ustawić maksymalny limit PHP wynoszący 256 MB:

 php_value memory_limit 256M

Błędy w składni ustawień aplikacji i serwera w plikach wp-config.php , php.ini i .htaccess mogą również powodować WSOD. Może być konieczne ręczne poprawienie lub zastąpienie ich oryginalnymi wartościami domyślnymi, jeśli psują Twoją witrynę. Jeśli używasz serwera WWW Apache lub Litespeed, plik .htaccess , który reguluje sposób ich działania, może zostać zmieniony przez wiele wtyczek WordPress. Błędy wprowadzone w którymkolwiek z tych plików mogą wywołać WSOD i spowodować awarię witryny.

4. Twój serwer HTTP ulega awarii

HTTP (lub jego zaszyfrowana, bezpieczna forma HTTPS) to protokół przesyłania hipertekstu, który sprawia, że ​​serwer WWW jest serwerem WWW. W ten sposób serwery udostępniają strony internetowe (dokumenty HTTP) klientom (takim jak przeglądarki) na żądanie.

Powszechnie używanymi serwerami HTTP dla witryn WordPress są Apache, Litespeed i NGINX. Ich ekrany błędów wyglądają nieco inaczej i mogą różnić się sposobem wyświetlania ich przez przeglądarki, ale wszystkie zgłaszają te same kody błędów HTTP.

Błąd HTTP 500, znany również jako wewnętrzny błąd serwera, wskazuje na nieoczekiwany problem z serwerem HTTP, który uniemożliwia mu realizację żądań HTTP. Inne kody błędów serwera 5xx, zwłaszcza 502 (zła brama), 503 (usługa niedostępna) i 504 (przekroczenie limitu czasu bramy), wskazują, że serwer jest przeciążony lub niedostępny. Wewnętrzny błąd 500 dotyczy wszystkich awarii serwera, które uniemożliwiają mu zwrócenie żądanej strony/dokumentu.

Twoja przeglądarka może udostępniać własne, niepowtarzalne ekrany błędów HTTP i może wyświetlać własne specjalne kody błędów. Google Chrome (i inne przeglądarki oparte na Chromium) wyświetla i objaśnia wszystkie własne kody błędów wewnętrznie, jeśli przeglądasz chrome://network-errors/ na pasku adresu podczas korzystania z Chrome.

Problemy po stronie serwera

Powszechnie używane oprogramowanie serwera HTTP dla witryn WordPress obejmuje Apache, Litespeed i NGINX. Wielu hostów WordPress używa ich z buforowaniem, aby zmaksymalizować wydajność.

Jeśli twarde odświeżenie przeglądarki lub wyczyszczenie plików cookie i pamięci podręcznej przeglądarki nie wyeliminuje ekranu błędu 500, być może wykryto złe pliki pamięci podręcznej po stronie serwera. Buforowanie po stronie serwera może powodować wiele zamieszania, gdy nie działa dobrze, dlatego też powinieneś spróbować je wyczyścić. Twój panel kontrolny hostingu lub interfejs administratora WordPress mogą mieć opcje czyszczenia pamięci podręcznej.

Typowe przyczyny błędu HTTP 500 mogą obejmować następujące warunki po stronie serwera:

1. Limit pamięci PHP został przekroczony.
2. Inne błędy PHP, gdy PHP nie jest ustawione na wyświetlanie błędów.
3. Niewystarczające uprawnienia dostępu do plików i folderów serwera.
4. Błędy składniowe w pliku konfiguracyjnym .htaccess.

Omówiliśmy już limity pamięci PHP i sposoby ich zwiększenia. W następnej sekcji poniżej zagłębimy się w debugowanie PHP.

Nieprawidłowe uprawnienia nie powinny mieć miejsca na nowoczesnym, zarządzanym hostingu WordPress, ale są powszechne w przypadku tradycyjnego hostingu współdzielonego. Pliki powinny być ustawione na 664 lub 644, foldery powinny być ustawione na 775 lub 755, a wp-config.php powinien być ustawiony na 660, 600 lub 644. Dowiedz się więcej o zmianie uprawnień do plików na WordPress.org.

Jeśli dokonałeś zmian w pliku .htaccess lub używasz wtyczki (często lub buforującej), która go zmienia, może być konieczne przejrzenie pliku pod kątem błędów, przywrócenie go lub ponowne utworzenie nowego, działającego pliku .htaccess. Dowiedz się więcej o .htaccess na WordPress.org.

Problemy po stronie klienta

Błędy HTTP 500 mogą być również spowodowane po stronie klienta (w Twojej przeglądarce) przez inne warunki:

5. Nieprawidłowe ustawienia przeglądarki.
6. Uszkodzona pamięć podręczna.
7. Uszkodzone pliki JavaScript, które działają w Twojej przeglądarce.
8. Problemy z łącznością internetową.

Spróbuj załadować witrynę w innej przeglądarce, aby wyeliminować problem z bieżącą przeglądarką. Jeśli masz problem z przeglądarką, spróbuj zresetować ją do ustawień domyślnych. Wyłącz wszelkie zainstalowane rozszerzenia lub wtyczki przeglądarki, aby sprawdzić, czy źle współdziałają z Twoją witryną.

Jeśli Twój problem jest związany z nieprawidłowymi plikami pamięci podręcznej, niebuforowany obszar administracyjny WordPress może nadal być dla Ciebie dostępny. Jeśli nadal możesz zalogować się do interfejsu administratora WordPress, możesz użyć tam przełączników do czyszczenia pamięci podręcznej lub wypróbować dodatkowe kroki rozwiązywania problemów omówione poniżej.

Możliwe jest również, że błąd HTTP 500 może być spowodowany problemem z bazą danych, problemem z wtyczką lub motywem w witrynie WordPress lub problemem z samym WordPressem.

Aby rozwiązać problem z błędem HTTP 500, włącz rejestrowanie błędów dla swojego serwera HTTP i PHP. Następnie sprawdź, jakie błędy pojawiają się w obu. Możesz także sprawdzić i potencjalnie zwiększyć limit pamięci PHP, dezaktywować wtyczki i przełączyć się na domyślny motyw, aby sprawdzić, czy któraś z tych czynności przywróci Twoją witrynę.

Omówimy te kroki bardziej szczegółowo poniżej. Jeśli zastosowanie się do nich nie usunie błędu 500, skontaktuj się z zespołem pomocy swojego usługodawcy hostingowego, aby uzyskać dalszą pomoc.

Kiedy WordPress jest naprawdę martwy

Jeśli otrzymujesz całkowicie biały ekran na każdej przedniej i tylnej stronie swojej witryny WordPress bez widocznych informacji zwrotnych o błędach, to jest to pełne doświadczenie WSOD. Możesz uzyskać komunikaty o błędach i informacje diagnostyczne, jeśli wiesz, jak uzyskać dostęp do dzienników błędów PHP i dzienników serwera HTTP. Włączenie debugowania PHP dla WordPress to kolejna opcja. Twój host może mieć narzędzia ułatwiające debugowanie. Ale jeśli tak nie jest, możesz po prostu przejść do tej listy lekarstw na powszechny WSOD, aż znajdziesz rozwiązanie.

Główna lista kontrolna do rozwiązywania problemów i naprawy białego ekranu śmierci WordPressa

Aby naprawić biały ekran śmierci WordPress, wykonanie następujących kroków doprowadzi cię do rozwiązania. Są one uporządkowane według najczęstszych przyczyn WSOD, jakich doświadczyłem, ale możesz wypróbować je w dowolnej kolejności.

Najbardziej sensowne jest nadanie priorytetu rozwiązaniom, które wydają się najbardziej odpowiednie w danej sytuacji.

Krok rejestrowania błędów i debugowania (nr 2) jest najbardziej techniczny, ale jest dokładny i zawsze powie ci, co powoduje zamknięcie WordPressa.

Podałem linki do kilku darmowych wtyczek, które mogą być przydatnymi narzędziami diagnostycznymi i naprawczymi. Może się również okazać, że iThemes Security jest szczególnie pomocny ze względu na funkcję skanowania i naprawy bazy danych, a także wykrywanie zmian w plikach. Ma nawet narzędzia serwerowe do głębszego wglądu w ustawienia i możliwości serwera.

W ostateczności dobra, niedawna kopia zapasowa przywróci Twoją witrynę online do ostatniego znanego dobrego stanu. Backup Buddy to najlepsza wtyczka do tej roli.

Wyczyść pamięć podręczną przeglądarki i pliki cookie

Strony Twojej witryny zapisane w pamięci podręcznej w przeglądarce i na serwerze mogą pokazywać coś innego niż to, co dzieje się w rzeczywistości. Upewnijmy się, że widzisz to, co WordPress pokazuje zupełnie nowym odwiedzającym Twoją witrynę.

Najpierw wyczyść pamięć podręczną przeglądarki i usuń pliki cookie. Spowoduje to zakończenie sesji użytkownika, jeśli jesteś zalogowany do WordPress lub innej witryny, więc patrzysz na nią jak każdy inny gość.

Następnie użyj panelu hostingowego i administratora WordPress (jeśli jest dostępny), aby wyczyścić pamięć podręczną po stronie serwera tworzoną przez hosta i wtyczki pamięci podręcznej WordPress. Spróbuj wyłączyć całe buforowanie witryny i serwera. Wykonaj twarde odświeżenie w przeglądarce. Jeśli to rozwiąże problem, problem może polegać na tym, że masz aktywowane ustawienia pamięci podręcznej, które nie działają w twoim systemie. Poprzez proces eliminacji możesz określić, które z nich działają, a które nie.

2. Poszukaj błędów PHP

Kod PHP w rdzeniu WordPress, motywach lub wtyczkach może generować błąd krytyczny, który sprawi, że WordPress zrezygnuje z ducha za pomocą białego ekranu śmierci.

Aby uzyskać więcej informacji o krytycznych błędach PHP i ich przyczynach, możesz włączyć raportowanie błędów PHP i wysłać je na ekran, do pliku dziennika lub do obu. Błędy krytyczne prawdopodobnie wskażą źródło WSOD.

Jako aplikacja internetowa oparta na PHP, WordPress ma własny system raportowania diagnostycznego do debugowania, który pomaga korzystać z funkcji rejestrowania błędów PHP. Aby go włączyć i kontrolować, upewnij się, że w pliku wp-config.php znajduje się wiersz, który mówi:

 zdefiniuj („WP_DEBUG”, prawda);

Może być konieczne dodanie go lub zmiana wartości z false na true. To mówi WordPressowi, aby włączył debugowanie PHP.

Możesz także skorzystać ze skrótu, instalując i aktywując wtyczkę WP Debugging. Włączy debugowanie PHP dla WordPressa bez konieczności samodzielnego modyfikowania wp-config.php .

Dodatkowe parametry wp-config.php pokazane poniżej spowodują domyślnie wydrukowanie danych wyjściowych debugowania na ekranie jako HTML i pliku o nazwie „error_log”:

 zdefiniuj („WP_DEBUG_DISPLAY”, prawda);
zdefiniuj („WP_DEBUG_LOG”, prawda);

Pomocne może być również zmuszenie WordPressa do korzystania z niezoptymalizowanych wersji jego zależności CSS i JavaScript, jeśli istnieje prawdopodobieństwo, że powodują one problem:

 zdefiniuj („SCRIPT_DEBUG”, prawda);

Wtyczka Debug Bar jest przydatnym narzędziem dodatkowym i uzupełniającym. Pokaże ci debugowanie danych w ładnym interfejsie.

Aby tak się stało, w php.ini musi być linia, która nadaje stałej error_reporting wartość inną niż NONE , na przykład error_reporting = E_ALL . W tej linii nie powinno być średnika; co czyni go raczej komentarzem niż aktywnym ustawieniem. Zauważ, że otrzymasz każdy błąd PHP, ostrzeżenie i powiadomienie, jeśli użyjesz E_ALL . Użyj innej wartości, takiej jak E_ERROR , aby rejestrować tylko krytyczne błędy w czasie wykonywania, które powodują awarię WordPress.

3. Sprawdź konflikty motywów i wtyczek

Debugowanie pod kątem błędów PHP zgodnie z opisem w poprzednim kroku powinno wskazać czysty motyw lub plik wtyczki jako źródło WSOD. Możesz także zbliżyć się do niego, stosując mniej techniczne podejście do procesu eliminacji.

Rozwiązywanie problemów z motywami

Biały ekran śmierci jest często spowodowany konfliktami między motywami WordPress i/lub wtyczkami. Aby zidentyfikować źródła konfliktów, możesz spróbować dezaktywować wszystkie wtyczki i przełączyć się na aktualne, niezmodyfikowane domyślne pakiety motywów z rdzeniem WordPress, takie jak Twenty Twenty-Three.

Zacznij od motywu — najłatwiej go przetestować. Jeśli przełączenie aktywnego motywu na znany dobry, niezmodyfikowany motyw domyślny przywróci witrynę do trybu online, wiesz, że problem dotyczy motywu, którego używasz.

Spójrz na plik functions.php motywu, jeśli taki istnieje. Jeśli niedawno go zmieniłeś, jest to prawdopodobne źródło twojego nieszczęścia. Plik functions.php to miejsce, w którym dodawany jest niestandardowy kod funkcjonalny do użycia z motywem, gdy jest on aktywowany. Zły kod i błędy składniowe tutaj spowodują WSOD.

Rozwiązywanie problemów z wtyczkami

Możesz dezaktywować wtyczki bez dostępu do administratora WordPress za pomocą wiersza poleceń/SSH lub SFTP, po prostu tymczasowo przenosząc foldery wtyczek z folderu /wp-content/plugins/ . Moja praktyka polega na utworzeniu podfolderu wtyczek o nazwie „A”, aby pojawiał się jako pierwszy w posortowanym alfabetycznie katalogu /plugins . Następnie przenoszę wszystkie inne foldery wtyczek do „A”.

Gdy to zrobisz, ponownie załaduj witrynę. WordPress będzie zachowywał się tak, jakby wszystkie wtyczki zniknęły. Nadal są zainstalowane, ale dezaktywowane. Jeśli biały ekran śmierci zniknie, możesz spróbować ponownie aktywować wtyczki i motyw jeden po drugim, odświeżając stronę główną za każdym razem, aby zobaczyć, który z nich powoduje awarię witryny.

Meks Quick Plugin Disabler to przydatne narzędzie, które szybko wyłącza wszystkie aktywne wtyczki, a następnie ponownie je włącza z poziomu administratora WordPress na Twoje polecenie.

4. Napraw uszkodzone pliki podstawowe

Twój WSOD może być konsekwencją uszkodzonych podstawowych plików WordPress. Chociaż jest to mało prawdopodobne, łatwo jest szybko ponownie zainstalować najnowszą wersję WordPressa za pomocą jednego kliknięcia w obszarze Aktualizacje pulpitu nawigacyjnego WordPress. Nie zaszkodzi to żadnej z twoich wtyczek, motywów ani istniejącej zawartości, więc jest to dobry, łatwy sposób na potwierdzenie, że podstawowe pliki są w porządku.

Jeśli żaden z powyższych kroków nie pomoże, przyczyną WSOD może być problem ze środowiskiem serwera, który jest poza twoim zasięgiem. W takim przypadku może być konieczne skontaktowanie się z dostawcą usług hostingowych w celu uzyskania pomocy. W ostateczności możesz również przywrócić witrynę do stanu „ostatniego znanego dobrego”, przywracając kopię zapasową.

Jak zapobiegać WSOD — porady dla właścicieli i twórców witryn WordPress

WordPress działał dobrze — a potem nagle pojawił się biały ekran śmierci!

Dzieje się tak prawdopodobnie dlatego, że zmieniłeś coś krytycznego dla funkcjonowania WordPressa.

Jeśli korzystasz z solidnie zarządzanego konta hostingowego WordPress z Liquid Web lub Nexcess, które jest odpowiednio skonfigurowane z wystarczającymi zasobami do tego, co z nim robisz, 99% sposobów na uszkodzenie WordPressa za pomocą WSOD można uniknąć.

Problem polega na tym, że właściciele witryn nie unikają tych praktyk!

Czego nie robić

1. Kodowanie kowbojskie. Dodawanie lub edytowanie kodu funkcjonalnego w działającej witrynie za pośrednictwem SFTP, wiersza poleceń lub edytorów kodu i wstawek skryptów w panelu administracyjnym WordPress. Jeden mały błąd spowoduje wyłączenie strony. Zmiana plików konfiguracyjnych, takich jak .htaccess i wp-config.php może również spowodować wyłączenie witryny. Zamiast tego pracuj nad lokalną witryną testową lub działającą na żywo (ale nie publiczną).
2. Instalowanie wątpliwych motywów, wtyczek i rozszerzeń. Instalowanie niskiej jakości lub nawet zerowego oprogramowania w działającej witrynie jest zaproszeniem do kłopotów. Po prostu dodanie zbyt wielu rzeczy naraz może utrudnić określenie, co ostatecznie jest przełomową zmianą. Podobnie jak w przypadku kodowania kowbojskiego, instalowanie nowych produktów kodujących w działającej witrynie jest ryzykowne. Najpierw dobrze przetestuj na prywatnej lokalnej lub tymczasowej stronie.
3. Skomplikowane buforowanie. Istnieje kilka rodzajów buforowania po stronie serwera, które może oferować twój host, które mogą nie działać dobrze ze wszystkimi wtyczkami do buforowania i optymalizacji wydajności. Wdrażając nowe metody lub ustawienia buforowania, przed wprowadzeniem zmian w działającej witrynie dokładnie przetestuj je w środowiskach lokalnych i przejściowych.
4. Aktualizowanie wszystkiego naraz. Możesz aktualizować wsadowo wiele motywów i wtyczek jednocześnie. Zwykle to działa, ale jeśli przekroczy limit czasu serwera, możesz utknąć w trybie konserwacji. Ponadto nowo zaktualizowany kod może wprowadzać nowe błędy, konflikty lub problemy ze zgodnością. Jeśli tak się stanie i Twoja witryna ulegnie awarii, trudniej będzie zidentyfikować źródło problemu. Może to być dowolna liczba elementów, jeśli jednocześnie zaktualizowałeś wiele motywów, wtyczek i rozszerzeń. Zaktualizowany kod można przetestować lokalnie i w witrynach testowych na żywo przed wdrożeniem go w głównej witrynie publicznej.

Wskazówki dotyczące życia bez WSOD

WSOD może się zdarzyć w dowolnej witrynie WordPress, ale nie powinien być powodem do niepokoju. Postępowanie zgodnie ze wskazówkami zawartymi w tym przewodniku może pomóc w zidentyfikowaniu problemu i szybkim rozwiązaniu go, zanim użytkownicy witryny go zauważą.

Problemy z witryną WordPress podkreślają znaczenie właściwej konserwacji i opieki. Lepiej niż reagowanie na WSOD, możesz nauczyć się pracować na WordPress w sposób, który nigdy nie narazi odwiedzających na komunikaty o błędach i puste ekrany.

Wprowadzaj zmiany ostrożnie i z rozmysłem. Zajmij się potencjalnymi WSOD w lokalnym środowisku testowym lub przejściowym. Są to standardowe narzędzia i funkcje dla większości zarządzanych obecnie hostów WordPress. Jeśli zastosujesz się do tych podstawowych, najlepszych praktyk, nie będziesz musiał martwić się o biały ekran śmierci WordPress.

Najlepsza wtyczka zabezpieczająca WordPress do zabezpieczania i ochrony WordPress

WordPress obsługuje obecnie ponad 40% wszystkich witryn internetowych, więc stał się łatwym celem dla hakerów o złośliwych zamiarach. Wtyczka iThemes Security Pro usuwa zgadywanie z zabezpieczeń WordPress, aby ułatwić zabezpieczanie i ochronę witryny WordPress. To tak, jakby zatrudnić pełnoetatowego eksperta ds. bezpieczeństwa, który stale monitoruje i chroni Twoją witrynę WordPress.

Pobierz iThemes Security Pro

Dana Knaussa

Dan Knauss jest generalistą ds. treści technicznych w StellarWP. Jest pisarzem, nauczycielem i freelancerem pracującym w open source od późnych lat 90., a z WordPressem od 2004 roku.