Gdy piszę ten tekst mamy niedzielny, prawie zimowy poranek, a więc dzień dla mnie zazwyczaj wolny od pracy. Ale w mojej branży często jest tak, że niezależnie od planów różne rzeczy mogą się zdarzyć… Tym razem dostałem e-mail z prośbą o pilną pomoc ze sklepem działającym na WooCommerce (wtyczka do WordPressa). Niby wszystko działa prawidłowo, ale w pewnym momencie na stronie nie widać nic, poza tzw. „białym ekranem śmierci”. Skoro mamy do czynienia ze sklepem, to reakcja powinna być szybka. Ale by móc usunąć błąd najpierw trzeba wiedzieć, co go powoduje.

Debugowanie WordPressa

W momencie gdy coś nie działa na stronie prawidłowo zazwyczaj zaleca się wyłączenie wszystkich wtyczek, i ew. przełączenie motywu na domyślny. I o ile ma to jakiś sens, to nie jestem zwolennikiem takiego rozwiązania, przynajmniej, jeśli nie jest to potrzebne. Nie dość, że na pewien czas „upośledzamy” naszą stronę, która cały czas jest publicznie dostępna, to jeszcze tworzymy w pewnym sensie sztuczne środowisko, w którym błąd może nie występować – w tym momencie czeka nas żmudne włączanie kolejnych wtyczek, kolejnych modułów w poszukiwaniu błędu. Jest to oczywiście jakieś rozwiązanie, ale… Jeśli już na nie się zdecydujemy, to warto pomyśleć o pracy na kopii strony, w przygotowanym do tego celu środowisku.

O ile jest to jakieś rozwiązanie, i samemu zdarza mi się je stosować (ale w trybie pracy na kopii, w środowisku testowym), to zdecydowanie lepiej zacząć poszukiwania od przejrzenia logów – czy to logów webserwera (np. Nginx, Apache2), czy PHP. Często to wystarczy by trafić na miejsce, które generuje problem.

Jednak z doświadczenia wiem, że zdarzają się sytuacje, gdy logi webserwera i PHP nie pokazują nic złego, a mimo to strona nie działa. Tu z pomocą przychodzi tryb debugowania w wykorzystywanym CMSie – w moim przypadku najczęściej będzie to WordPress.

By aktywować zapis m.in. błędów w WordPressie wystarczy w pliku wp-config.php dodać kilka linijek:

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

// Bez pokazywania "w przeglądarce"
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

define( 'SCRIPT_DEBUG', false );
Pamiętajcie, by wszelkie dodatkowe elementy w pliku wp-config.php zapisywać przed linijką:

/* To wszystko, zakończ edycję w tym miejscu! Miłego blogowania! */

Lub w wersji angielskiej:

/* That's all, stop editing! Happy blogging. */ 

Po tej zmianie wszystkie błędy związane z działaniem WordPressa będą zapisywane w pliku:

wp-content/debug.log

Ze względów bezpieczeństwa jak najszybciej – po zdiagnozowaniu problemu – wyłącznie debugowanie. Można też rozważyć zablokowanie dostępu do pliku np. tylko dla Waszego adresu IP…

Zgłoś błąd na stronie

Potrzebujesz profesjonalnej pomocy? Skontaktuj się z nami!

WebInsider poleca księgowość wFirma
WebInsider korzysta z VPSa w HitMe.pl
WebInsider poleca VPSy DigitalOcean
WebInsider poleca serwis Vindicat
Napisz komentarz
wipl_napisz-komentarz_01Jeśli informacje zawarte na tej stronie okazały się pomocne, możesz nam podziękować zostawiając poniżej swój komentarz.

W tej formie możesz również zadać dodatkowe pytania dotyczące wpisu, na które - w miarę możliwości - spróbujemy Ci odpowiedzieć.
Linki partnerskie
Niektóre z linków na tej stronie to tzw. "linki partnerskie", co oznacza, że jeśli klikniesz na link i dokonasz wymaganej akcji (np. zakup/rejestracja) możemy otrzymać za to prowizję. Pamiętaj, że polecamy tylko te produkty i usługi, z których sami korzystamy, i uważamy, że są tego na prawdę warte... :-)
Znaki towarowe i nazwy marek
W niektórych wpisach (oraz innych miejscach na stronie) mogą być przedstawione/użyte znaki towarowe i/lub nazwy marek, które stanowią własność intelektualną tych podmiotów, a zostały użyte wyłącznie w celach informacyjnych.

Potrzebujesz profesjonalnej pomocy? Skontaktuj się z nami!