WordPress: W witrynie wystąpił błąd krytyczny. Jak sobie z tym radzić ?

Jeżeli zauważyłeś/aś na swojej stronie internetowej opartej o system WordPress tzw: „white screen of death” lub napis „W witrynie wystąpił błąd krytyczny…”, nie panikuj. Z takim błędem każdy użytkownik WordPressa spotkał się nie jeden raz. Na szczęście w większości przypadków można ten problem szybko rozwiązać.

Spis treści:

• White Screen of Death w WordPress
• Jak sprawdzić co spowodowało błąd ?
• Czym jest WP_DEBUG ?
• Przywracanie poprzedniej wersji wtyczki/motywu
• Jak uniknąć takich błędów w przyszłośći ?
• Środowisko stagingowe
• Podsumowanie

„White Screen of Death”

Zarówno błędy wyrzucane przez interpreter PHP jak i te z bazy danych objawiają się jako pusty biały ekran bez żadnych informacji – jest to nazywane białym ekranem śmierci (WordPress White Screen of Death ) (WSOD) i jest to oczywiste nawiązanie do niebieskich ekranów z Windowsa 🙂

Jest kilka przyczyn, które powodują powstawanie WSOD:

• Błąd spowodowany prez wtyczkę: Jeżeli masz dostęp do Panelu administracyjnego spróbuj wyłączyć wszystkie wtyczki a następnie włączać je jedna po drugiej. W przypadku braku dostępu niezbędne będzie zalogowanie się do swojej strony za pomocą protokołu FTP. Następnie zlokalizować folder wp-content/plugins i zmienić jego nazwę na plugins_old. Ta akcja wyłączy wszystkie pluginy.
  
  Wtyczki można wyłączyć również z poziomiu bazy danych. Trzeba zalogować się do swojej bazy danych w panelu phpMyAdmin a następnie w tabeli wp_options poszukać kolumny option_name i zmienić jej wartość na a:0:{}
  
  
• Błąd spowodowany przez Motyw: Dosyć często zdarza się sytuacja gdzie aktywowanie nowego motywu powoduje błąd krytyczny. Wówczas należy zalogować się do Panelu Administratora i włączyć jeden z domyślnych motywów
  
  TIP: zawsze miej w panelu administracyjnym przynajmniej jeden z motywów startowych przygotowanych przez zespół WordPressa czyli taki, który jest domyslnie zainstalowany wraz z systemem CMS. WordPress posiada wbudowany mechanizm sprawdzania stanu wityny i zakłada on, że przynajmniej jeden motyw domyślny powinien być w panelu ponieważ przy wystąpieniu błędów system jest w stanie w sposób automatyczny włączyć motyw domyślny

Jak sprawdzić, co spowodowało błąd ?

WordPress posiada funkcję, która w momencie wykrycia błędu ustawia cały system w tryb odzyskiwania oraz wysyła maila do administratora witryny z konkretną informacją co spowodowało błąd. Wraz z tą informacją uzyskasz również link do dostepu do panelu administracyjnego w trybie odzyskiwania dzięki czemu będziesz mógl szybko i sprawnie rozwiązać problem z systemem

Co w przypadku gdy mail do administratora nie dochodzi ?

Tutaj przydatne będzie skorzystanie z wbudowanego mechanizmu WordPressa jakim jest WP_DEBUG

Czym jest WP_DEBUG w WordPressie ?

To tak naprawdę zmienna w PHP, którą możemy ustawić na wartości true lub false, przy ustawieniu wartości true uzyskamy dostęp do precyzyjnych informacji odnośnie tego co powoduje błąd krytyczny. Zostaną one wyświetlone na stronie głównej.

Gdzie właczyć WP_DEBUGa ?

Należy zalogować się do swojego serwera za pomoca połączenia FTP (np programem FileZilla lub Total Commander) a następnie w głównym katalogu naszej strony odszukać plik wp-config.php

Nastepnie należy odszukać lini kodu gdzie zdefiniowana jest zmienna WP_DEBUG i ustawić jej wartośc na true. Po zmianie tej wartości wystarczy wejśc na swoją stronę, odświeżyć ją i powinnismy widzieć na ekranie informację odnośnie błędów na stronie.

UWAGA: tryb debugowania powinien być wyłączony na wersjach produkcyjnych stron www.

Ja osobiście ustawiam w pliku wp-config następujące opcje:

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

Dzięki czemu błędy nie są wypisywane na ekranie. Jest tworzony nowy plik o nazwie debug.log i wówczas wystarczy wejść pod adres: nazwamojejdomeny.pl/wp-content/debug.log – w tym pliku będa wyrzucane wszelkie błedy

Chcesz dowiedzieć się więcej o debugowaniu ? zapraszam do oficjalnej dokumentacji

Mam włączony WP_DEBUG , co dalej ?

Prawdopodobnie po odczytaniu wiadomośći z pliku debug.log lub z ekranu strony masz już jasną informację gdzie dokładnie znajduje się błąd i to w jakiej linii kodu 🙂

Jeżeli okaże się, że to wtyczka po aktualizacji powoduje błąd to powinniśmy w pierwszej kolejności zgłosić to autorowi oraz wyczekiwać kolejnych aktualizacji. Do momentu uporania się z problemem przez autorów wtyczki należałoby cofnąć jej wersje do takiej, która nie powoduje błędów.

W przypadku gdy to motyw jest winny postępujemy praktycznie tak samo – zgłaszamy to do autorów i czekamy na reakcję. Do tego czasu aby nasza strona była live musimy cofnąć zmiany z wtyczki / motywu, który powoduje błąd . Jak to zrobić ?
Jak przywrócić poprzednią wersję wtyczki / motywu do wersji z przed wystąpienia błędu ?

Aby to zrobić wystarczy zainstalować plugin WP ROLLBACK z repozytorium wtyczek WordPressa, włączamy ją i na liście naszych pluginów będziemy mieli nową opcję przywrócenia poprzedniej wersji wtyczki

Czy da się uniknąć takich błędów w przyszłości ?

Jeżeli nie nauczysz się na błędach i będziesz traktować swoją produkcyjną stronę jak piaskownicę to mam do Ciebie złą wiadomość: Takie błędy bedą się zdarzały. Co zatem zrobić aby ich uniknąć? Odpowiedź jest prosta: środowisko stagingowe!

Czym jest środowisko stagingowe?

Na temat stagingu niebawem ukaże się osoby artykuł. Będe w nim pokazywał jak wygląda workflow pracy z klientem i w jaki sposób zarządza się takimi projektami w agencjach oraz firmach technologicznych typu software-house także bedzie troszkę od kuchni 🙂

Najprościej mówiąc: środowisko stagingowe to środowisko pośrednie, można je nazwać staging, beta , test , dev – nie ma to znaczenia. Ważne jest to aby mieć po prostu kopię swojej strony prawie 1:1 (prawie robi wielką różnicę jak w kultowej reklamie z 2005 roku ). Jedyna różnica to w sumie ustawienia indeksowania strony w wyszukiwarkach (wersja stagingowa jest dla nas i nie może byc indeksowana w google)

Workflow pracy jest dosyć prosty:

1.Aktualizujemy najpierw wersję stagingową naszej strony dzięki czemu nasza strona produkcyjna funkcjonuje w najlepsze i nic się z nią nie dzieje.

2. Jeżeli wszystko jest ok na wersji stagingowej to po prostu migrujemy zmiany z jednego środowiska na drugie.

Środowisko stagingowe daje jeszcze więcej benefitów, można na nim testować różne zmiany bez obawy, że akurat w ważnym dla naszego biznesu momencie coś się zepsuje i strona pokaże nam fige z makiem :). Najważniejsze jest jednak to, że unikamy wystapienia błedu krytycznego na naszej głównej stronie internetowej.

Podsumowanie

Na stronach internetowych opartych o system WordPress dosyć często doświadczymy róznych błędów. W związku z tym, że klasyczna strona oparta o WordPress to dosyć często projekt robiony przez mniej doświadczonych uzytkowników to trzeba mieć na uwadzę, że takie projekty, zwłaszcza z ogromną ilością wtyczek są dosyć problematyczne w utrzymaniu i potrafią sprawić problemy podczas aktualizacji.

Jeżeli twoja strona internetowa jest dla Ciebie ważnym kanałem do monetyzacji to nie możesz pozwolić sobie na przerwy w jej działaniu. Pomyśl o utworzeniu wersji stagingowej albo o usłudze stałej administracji twoją witryną.

Pamiętaj również o tym, że warto ogarniczać liczbę wtyczek, jeżeli chciałbyś dowiedzieć się dlaczego warto posprzątać w swoim panelu zajrzyj do dedykowanego wpisu czyli: Dlaczego nie powinieneś przesadzać z ilością wtyczek na WordPressie?

Wówczas w ramach jednego abonamentu będziesz miał pewność, że Twoja strona będzie w dobrych rękach i wszelkie aktualizacje będa najpierw testowane na maszynie lokalnej developera, następnie na wersji stagingowej i dopiero gdy okaże się, że można daną wtyczkę, motyw czy też cały system zaktualizować to wówczas odpowiednia osoba zrobi to w sposób w pełni bezpieczny dla Twojej witryny.

Stała administracja stronami internetowymi w ramach abonamentu to pewnie 1/10 całego etatu dlatego też warto rozważyć taką usługę.