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.
Spis treści w artykule
Debugowanie WordPressa
W momencie, gdy coś nie działa prawidłowo na stronie, 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.
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 );Po tej zmianie (teoretycznie, bo są wyjątki…) wszystkie błędy związane z działaniem WordPressa będą zapisywane w pliku:
wp-content/debug.logZe względów bezpieczeństwa, po skończonej analizie warto wyłączyć tryb debugowania, oraz skasować utworzony plik z logami. Można też rozważyć zablokowanie dostępu do pliku np. tylko dla Waszego adresu IP…
Pasjonat nowych technologii - od sprzętu po oprogramowanie, od serwerów po smartfony i rozwiązania IoT. Potencjalnie kiepski bloger, bo nie robi zdjęć "talerza" zanim zacznie jeść.
Dumny przyjaciel swoich psów :-)
- Wakacje składkowe ZUS a zawieszenie działalności gospodarczej, czyli uważaj, bo być może nie będziesz mógł skorzystać (w 2024) - 1970-01-01
- Przykładowy kalkulator wyceny usługi druku 3D, czyli nie tylko materiał się liczy - 1970-01-01
- Home Assistant 2024.10, czyli nowa karta „nagłówek” i niedziałający TTS w ramach usługi Google Cloud - 1970-01-01
Temat trochę za bardzo po łebkach potraktowany.
Zwykle jest odwrotnie, WP Debug pokazuje mniej niż logi serwera ….no i warto załączać logowanie jednak na niższym poziomie w php.ini czy .htaccess – konfig WordPressa może już być za późno.
Bugi też nie muszą być stricte errorami czy notice’ami ….równie dobrze mogą to być błędy logiczne – złe założenia, niewłaściwy warunek itd. itp. (kod działa prawidłowo i nie rzuca żadnym błędem, ale wynik jest inny od oczekiwanego, jest podejmowana niewłaściwa akcja, coś jest nadpisywane…).
W takim wypadku sam WP Debug czy logi nie pomogą, trzeba samodzielnie drążyć – i tutaj w grę wchodzi logowanie własnych zdarzeń, klasyczny print_r czy var_dump, testy jednostkowe itd.
Na koniec, popularna rada wyłącz i sprawdź jest kierowana głównie do osób niedoświadczonych.
-znacznie szybciej i łatwiej takiej osobie znaleźć winowajcę prosta drogą eliminacji, niż nauczyć ją wszystkiego od zera, by sobie mogła samodzielnie zdebugować i naprawić.
Aaaa, dodam jeszcze, że często samo wyłączenie i ponowne włączenie czegoś rozwiązuje problem – bywa niekiedy po aktualizacjach, że coś nie zatrybi i możesz szukać na siłę błędów, a wystarczy przeładować konfig i zaczyna działać.
Z reszta podobnie bywa z permalinkami, gdzie problem 404-ek najczęściej rozwiązuje ręczne sflushowanie regułek przez nadpisanie konfigu w Ustawienia >> Bezposrednie odnośniki.
Dzięki za obszerny komentarz, i oczywiście zgadzam się z Tobą. Stąd wpierw wspomniałem o „wyłącz i włącz”, oraz o logach serwera, gdzie sam zazwyczaj sam zaczynam szukać ewentualnej przyczyny. Ale nie każdy ma do nich dostęp (np. w przypadku hostingu współdzielonego różnie to bywa), a w przypadku np. VPSów często wiele stron zapisuje logi do jednego pliku (widziałem takie przypadki). Dlatego – zwłaszcza dla osób mniej doświadczonych – logi WordPressa mogą być najprostszą (relatywnie ;-)) metodą na zlokalizowanie problemu, i fakt, że „zwykle pokazują mniej niż logi serwera” w tym przypadku może być zaletą. Dodatkowo logi serwera (VPS) zazwyczaj mamy włączone, logi WordPressa trzeba ręcznie włączyć (i po poszukiwaniach wyłączyć), i o tym jest ten wpis. Sama analiza logów, poszukiwanie konkretnego fragmentu kodu PHP to już tematy na inny wpis, a być może nawet kilka…
W u mnie w ten poranek posypała się strona na WP. base64…
Czyli co, tydzień zaczyna się „dobrze”? Plus może taki, że ta „niespodzianka” wyczerpie limit na cały tydzień, i dalej już tylko same pozytywne wydarzenia… Jakbyś potrzebował jakiegoś wsparcia czy konsultacji, to pisz śmiało – zwłaszcza że adres e-mail znasz. :-)
A ja mam trochę inne oczekiwanie od debugowania – bardziej 'krok po kroku” niż „zobacz komunikat”.
Czy istnieje taka możliwość? (jak np.: w Dephi, Visual Studio itp.)
Możesz zerknąć na Xdebug, ew. PHP Development Tools (PDT) do Eclipse. Jeśli dobrze pamiętam, to np. PhpStorm też ma wbudowane rozwiązanie tego typu (narzędzie płatne). Są jeszcze różne dodatki do przeglądarek, ale one działają od strony przeglądarki, więc raczej nie ma co sobie zaprzątać nimi głowy. Bo równie dobrze można by zamiast nich użyć dowolnego programu do „testowania podatności” z wbudowanym proxy.
Dziękuję