Tropienie błędów – 7 technik, które ułatwią życie programiście WordPressa

Programista WordPressa naprawia błędy

Pierwsze dni w pracy w korporacji. Zostaję zatrudniona jako programista i już w drugim tygodniu przydzielona do projektu w produkcji oprogramowania. W ręku trzymam wydruk z MS-Projecta – mój harmonogram prac:

  • x dni na konsultacje projektowe
  • y dni na kodowanie
  • z – na testy deweloperskie
  • i całe 2 tygodnie na naprawę błędów

Wpatruję się w ostatnią pozycję tabelki i myślę „Muszą mnie mieć za niezłego cieniasa, skoro z góry założyli, że w moim sofcie będą błędy. I będzie ich tak dużo, że potrzeba aż 2 tygodni, żeby je naprawić…”

I choć potem okazało się, że czas na naprawdę błędów planowany jest dla każdego, nawet najbardziej doświadczonego programisty, od tamtej pory minęło 10 lat i dziś nawet nie pracuję już w korporacji – jestem programistą WordPressa „na swoim” – to pewne fakty pozostały niezmienne. Jak choćby ten, że zmaganie się z błędami w oprogramowaniu jest wpisane w zawód dewelopera.

Narzędzia i techniki debugujące – dlaczego warto się z nimi zapoznać

Lokata w wiedzę obejmującą techniki wykrywania błędów to inwestycja, która bardzo szybko przynosi zyski. Dlatego jak najszybciej warto:

  • wyrobić sobie pewne nawyki, które pozwolą lepiej kontrolować prace programistyczne na bieżąco
  • poznać różne sposoby wychwytywania błędów
  • zaopatrzyć się w odpowiednie narzędzia debugujące

Dzięki temu minimalizujemy ryzyko spędzenia więcej czasu na poszukiwaniu przyczyn błędów niż samym kodowaniu.

Techniki śledzenia błędów podczas pracy nad witryną WordPressową

Niżej prezentuję kilka wybranych technik, które wykorzystuję w swojej pracy, realizując zlecenia WordPressowe dla klientów. Zaczynam od prezentacji sposobów najprostszych, których znajomość przyda się nie tylko podczas pracy nad kodem WordPressa. Kończę na bardziej zaawansowanych, mając nadzieję, że każdy znajdzie tu coś dla siebie.

1. Pasek Web Developer – zacznijmy od podstaw

Pasek Web Developer to dodatek (tak zwany add-on) do przeglądarki Firefox oraz Chrome stworzony dla programistów witryn www. Po ściągnięciu ze strony http://chrispederick.com/work/web-developer i zainstalowaniu pojawi się nowy pasek w przeglądarce:

Pasek Web Developer
Wachlarz możliwości tego narzędzia jest spory, a przy tym łatwy do samodzielnego rozpoznania – chodzimy po menu, klikamy poszczególne pozycje i od razu wiemy, co do czego służy.

Co osobiście najbardziej lubię w Pasku Web Developera

Edycja kodu CSS za pomocą paska Web Developer
Nieinwazyjna edycja kodu CSS. Kliknij, aby powiększyć

Nieinwazyjna możliwość edycji kodu CSS na żywym organizmie

Wchodzimy na dowolną witrynę w internecie, z menu wybieramy „Brak błędów w arkuszu CSS -> Edycja CSS” i w okienku po lewej stronie możemy dowolnie zmieniać reguły CSS, jednocześnie widząc, jak wykonywana zmiana wpływa na wygląd strony. Na rysunku obok pokazana jest próba zmiany koloru tekstu na czerwony.

Jest to technika nieinwazyjna – pozwala szybko sprawdzić, jak wpływa modyfikacja kodu na daną stronę bez konieczności logowania się do witryny. Prawie jak w symulatorze lotów, nieprawdaż? Jak coś napsujemy, to tylko wirtualnie, czyli zmiany będą widoczne jedynie w naszej przeglądarce.

Infromacje o formularzach w pasku Web Developer
Infromacje o formularzach, przykład

Wyświetlanie informacji o formularzach

Formularze->Wyświetl informacje o formularzu. Opcja ta przydaje się podczas pracy z formularzami. W zgrabnej tabeli mamy przedstawione infromacje dotyczące wszystkich pól formularza w uporządkowanej formie. Na rysunku obok pokazano tabelę wyświetloną za pomocą Paska Web Developer obejmującą standardowy formularz logowania się do panelu WordPressa.

Prowadnice i linijka - Pasek Web Developer
Prowadnice i linijka, przykład

Możliwość dokonywania pomiarów w pikselach

Wprawdzie ta opcja niewiele ma wspólnego z tematem szukania błędów, ale w pracy web developera bywa bardzo przydatna. Można bardzo szybko zmierzyć, ile pikseli zajmuje dany obszar. Włączamy opcję Różne->Wyświetl linijkę i rysujemy myszą po obszarze.

Włączenie prowadnic bywa również przydatne, szczególnie kiedy chcemy ustawić odległości elementu np. od górnej lub lewej krawędzi. W momencie kiedy ciągniemy prowadnicą po ekranie uaktualniana jest informacja o jej położeniu. Na rysunku obok pokazano dwie prowadnice pionowe i jedną poziomą, ich kolor ustawiono na czerwony.

2. Firebug – kod HTML, CSS i javascript pod lupą

Firebuga webdeweloperom chyba nie trzeba przedstawiać. Gdy zdarza mi się pracować nad stroną na komputerze, gdzie nie ma zainstalowanego Firebuga, czuję się jak saper, któremu powierzono zadanie wykrycia miny pozbawiając detektora. Na szczęście Chrome ma analogiczną funkcjonalność wbudowaną w przeglądarkę.

Firebug w akcji
Firebug w akcji, przykład

Klikamy prawym klawiszem myszy na dowolny element na stronie, z menu kontekstowego wybieramy „Zbadaj element za pomocą Firebug” i od razu widzimy, jaki fragment kodu HTML kryje się pod klikniętym elementem, jakie style zostały do niego zastosowane, jaka jest ich hierarchia. I co bardzo ważne – uwaga, uwaga – możemy zostać od razu przeniesieni do danego pliku CSS, a nawet linii kodu!

Firebug jest niezastąpiony podczas pracy z kodem javascript. Pozwala na debugowanie wskazanego skryptu dowolnej witryny, instrukcja po instrukcji, z podglądem zmiennych i możliwością wstawiania break pointów.

3. body_class – powiedz mi, kto za tym stoi

„Ta strona wymaga kilku zmian…” pisze klient i wysyła link do konkretnej podstrony witryny WordPressowej. Jeśli zdarzyła Ci się taka sytuacja, motyw widzisz pierwszy raz w życiu i nie bardzo wiesz, który z kilku lub kilkunastu plików php skórki odpowiada za generowanie tej konkretnej strony, to jest pewien sposób, który pomoże szybko ruszyć z miejsca. Jeśli programista napisał motyw zgodnie ze standardami, to użył w nim funkcji body class. Dzięki temu w podglądzie źródła strony zobaczymy bogaty zestaw klas znacznika body, który będzie zmieniać się w zależności od oglądanej podstrony.

<body class="single single-post postid-85 single-format-standard">

W powyższym przykładzie widzimy klasę single, więc nasze kroki możemy skierować od razu do pliku single.php.

<body class="page page-id-14 page-template-default logged-in admin-bar debug-bar-maximized">

W tym przykładzie widzimy klasę pagę oraz page-template-default, co pozwala nam sądzić, że za wygenerowanie strony odpowiada plik page.php (domyślna templatka dla stron).

Co zrobić, jeśli programista motywu WordPressa nie wykorzystał klasy body_class? Możemy skorzystać z pluginu Debug Bar, który dostarczy nam podobną informację. Plugin opisany w punkcie 6 niżej.

Więcej ciekawych zastosowań funkcji body_class znajdziemy w artykule Klasa css dla tagu body.

4. var_dump – chcę wiedzieć wszystko o tej zmiennej

var_dump w WordPressie
Rezultat var_dump, przykład

var_dump to funkcja języka php, a jednocześnie prawdziwy przyjaciel programisty WordPressa. Jako parametr podajemy zmienną (dopuszczalne właściwie dowolne wyrażenie), w rezultacie zostaje wyświetlony jej typ oraz aktualne wartości.

Funkcję tę możemy wywołać w dowolnym momencie, najczęściej po to, aby podejrzeć aktualny stan zmiennej. Ja jednak często korzystam z tej funkcji w celu sprawdzenia struktury zmiennych typu array w WordPressie. W ten sposób szybko przekonuję się, jaki jest pełny zestaw informacji do wykorzystania.

Przykładowo (zobacz obrazek obok) wykonując var_dump dla WordPressowej zmiennej $post zobaczymy cały wachlarz informacji dotyczącej wpisu. Czego konkretnie możemy dowiedzieć się z rezultatu jak pokazany na rysunku obok? Na przykład to, że pisząc $post->post_status dostaniemy się do statusu wpisu, a poprzez $post->post_title odwołamy się do jego tytułu itd.

Uwaga: rezultat funkcji var_dump lepiej jest analizować z poziomu podglądu źródła strony – wówczas prezentowany wynik przedstawiony jest w kolejnych liniach z odpowiednim poziomem wcięć (jak pokazano na rysunku wyżej).

5. WP_DEBUG – ostrzeżenie prawdę Ci powie

Stała WP_DEBUG, aktywowana w wp-config.php, powoduje włączenie WordPressa w trybie debugowania. Domyślnie ta stała jest wyłączona, o czym możemy się przekonać znajdując linię define(‚WP_DEBUG’, false); w wp-configu.

Zmiana tej wartości na „true” powoduje wyświetlania wszystkich błędów i ostrzeżeń (typu notice oraz warning). Wówczas wśród komunikatów znajdą się i takie, które nie zatrzymują działania strony, ale niosą dodatkowe informacje, że coś jest nie tak.

Kiedy warto włączyć zmienną WP_DEBUG:

  • wystąpił błąd i mamy „efekt białej strony” w WordPressie
  • php rzuca informacją o błędzie, która jest dla nas zbyt ogólna
  • chcemy się dowiedzieć, które spośród użytych funkcji php są już przestarzałe (niezalecane)
  • pracujemy na testowej wersji witryny i chcemy mieć kod php pod kontrolą na bieżąco

Przykład
Załóżmy, że WordPress zwraca błąd podczas załadunku zdjęć na stronę:

„Nie udało się wysłać pliku „nazwa-pliku.jpg” na serwer z powodu wystąpienia błędu
Wysłany plik nie mógł zostać przeniesiony do …/wp-content/uploads.”

Po włączeniu zmiennej WP_DEBUG zobaczymy ostrzeżenia, które pomogą nam uzyskać bardziej szczegółową infromację o błędach:

Warning: touch() [function.touch]: Unable to create file …/wp-content/uploads/nazwa-pliku.tmp because Permission denied in…

i dzięki temu wiemy, że problem dotyczy uprawnień.

Więcej informacji na temat innych WordPressowych stałych debugujących znajdziemy w kodeksie WordPressa.

6. Wtyczka Debug Bar – kulisy WordPressa bez tajemnic

Wtyczka Debug Bar dla WordPressa
Debug Bar, przykład

Jest kilka ciekawych wtyczek napisanych specjalnie dla programistów WordPressa w celu ułatwienia im śledzenia, co się w danym momencie z witryną WordPressową dzieje (na przykład ile zapytań do bazy jest wykonywanych). Na tym polu polecam plugin Debug Bar.

Za co osobiście lubię wtyczkę Debug Bar:

  • intuicyjna w użyciu – dla każdej oglądanej podstrony mamy możliwość przełączenia się w widok debug, a potem szybki powrót do oglądanej strony (zobacz przycisk Debug w prawym górnym rogu na rysunku obok).
  • ułatwia rozpoznanie działania motywu – widać, jaka templatka jest odpowiedzialna za wygenerowanie danej strony, jaki jest identyfikator wpisu
  • w jednym miejscu mamy dużo przydatnych informacji: wersja PHP, SQL, informacje o błędach i ostrzeżeniach

Uwaga: żeby wtyczka pokazywała komplet informacji, należy wcześniej włączyć zmienne WP_DEBUG oraz SAVEQUERIES w wp-configu.

7. Hook ‚all’- pokaż mi wszystkie akcje i hooki

Jest pewna sztuczka, która ucieszy zaawansowanych programistów WordPressa, szczególnie twórców motywów lub wtyczek. Następujący kod dodany do pliku functions.php

add_action( 'all', create_function( '', 'var_dump( current_filter() );' ) );

spowoduje wyświetlenie wszystkich akcji i hooków wykorzystanych podczas załadunku danej strony i to w odpowiednim kontekście, czyli tam, gdzie zostały odpalone. Początkowo możemy poczuć się przytłoczeni nadmiarem informacji, jednak wynik oglądany z poziomu podglądu źródła strony może stanowić naprawdę cenne źródło wiedzy o tym, co robi WordPress generując pojedynczą stronę.

Twoje sposoby na śledzenie błędów w WordPressie?

Idę o zakład, że znasz inne, nie prezentowane tu techniki radzenia sobie z błędami w WordPressie. Z ogromną ciekawością o nich poczytam. Zapraszam do wymiany wiedzy w tym zakresie w ramach komentarzy.

Inne wpisy o podobnej tematyce:

26 myśli do „Tropienie błędów – 7 technik, które ułatwią życie programiście WordPressa”

    1. Poważnie są tu takie, o których nie słyszałeś? Ale zdradzę Ci w sekrecie, że ja niektóre z nich poznałam dopiero pisząc ten artykuł. Wiesz jak to jest, szukasz jakiś szczegółów, a przy okazji natykasz się na inne rzeczy powiązane.

  1. Kawał dobrego wpisu – dzięki! Najbardziej przyda się chyba „Pasek Web Developer” :).
    Mam też pytanie co do Debug Mode. Często zdarza mi się tam zobaczyć informację o błędzie, która wskazuje na plik functions.php. To wskazuje, że inne skryty wywołujące tą funkcje mają z tym problem – można jakoś dojść które?

    1. Może umówmy się, że jak się natkniesz na tego rodzaju błąd, to opisz tutaj ten konkretny przypadek z większą liczbą szczegółów. No chyba że już teraz to możesz zrobić? Dzięki za miłe słówko.

  2. (Niestety) mogę. Mam 2 notki, które wyglądają następująco:

    Notice: Korzystanie z automatic_feed_links uznawane jest za przestarzałe od wersji 3.0! Zamiast tego użyj add_theme_support( ‚automatic-feed-links’ ). in /home/wpartpl/domains/wpart.pl/public_html/wp-includes/functions.php on line 3467

    Notice: Funkcja wp_enqueue_script została wywołana nieprawidłowo. Skrypty i style nie powinny być rejestrowane ani dodawane do kolejek do czasu włączenia jednej z następujących funkcji obsługujących rozszerzenia (ang. „hook”): „wp_enqueue_scripts”, „admin_enqueue_scripts” lub „init”. Proszę przeczytać „Odpluskwianie WordPressa”, aby dowiedzieć się więcej. (Ten komunikat został dodany w wersji 3.3.) in /home/wpartpl/domains/wpart.pl/public_html/wp-includes/functions.php on line 3587

    Niestety nie mam pojęcia, która wtyczka może generować coś takiego. Może to szablon? Nadmieniam też, że czasem lubi mi wywalić 404 w różnych momentach i miejscach – odświeżenie strony pomaga od razu.

    1. Zauważ, że chodzi tu o plik functions.php nie ten z aktywnego motywu, tylko z wp-includes. Może to Cię zmyliło?

      1. No tak, ale w tym pliku raczej nie ma błędu. A jeśli nawet, to już go zmieniałem ręcznie z paczki ściągniętej z wordpress.org w takiej wersji jaką mam u siebie. Kluczem tutaj jest dojście co wywołuje automatic_feed_links i wp_enqueue_script ponieważ te logi zupełnie nie pomagają

        1. No faktycznie to jest zmyłka, bo linia błędu jest jedynie linią, która generuje komunikat o tym, że funkcja jest przestarzała, a my chcemy znaleźć winowajcę, który używa tej przestarzałej funkcji.

          Wiem, że to nie będzie odpowiedź na Twoje pytanie, ale ja bym w tym konkretnym przypadku zrobiła search po plikach pluginów w poszukiwaniu ciągu przestarzałego, czyli np. automatic_feed_links. No i ważny jest też kontekst rzucania tym błędem.

          1. Tak zrobię. Jeśli chodzi o kontekst, to nie ma znaczenia. Czy to wpisy, czy strony, czy strona główna albo panel admina – to samo.

          2. Przede wszystkim upewnij się, że te wywołania nie pochodzą z Twojego motywu. Mogłeś ich użyć wcześniej, kiedy WordPress jeszcze je dopuszczał.

  3. Siódemki nie znałem… zazwyczaj dumpuje globalne $wp_filter. Ale zacne i fajne, bo może dumpy w funkcji ograniczyć do specyficznych miejsc. Podoba mi się, zapinam do pliku debug.php 😀

  4. Dobre zestawienie – miałem wrażenie typu „skąd ja to znam…”. Ostatnio przekonałem się, że po poznaniu podstawowych technik deweloperskich WordPressa, warto przerzucić się na pisanie całkowicie własnych szablonów. Wiesz wtedy wszystko o swoim szablonie i możesz wszystko zrobić po swojemu.
    A swoją drogą – gratuluję porzucenia korporacji!

    1. Dzięki za komentarz. Dodałam sobie Twój blog do swojego czytnika RSS (chociaż miałam problem ze znalezieniem odnośnika do feeda – odczytałam z podglądu źródł strony).

    1. Dzięki za miłe słówko. Wojtku, piszesz, że artykuł mógłby być ciut dłuższy. A o czym konkretnie jeszcze chciałabyś poczytać?

      1. Chociażby o cache’owaniu – ostatnio mam z tym problem. Nigdzie np. nie mogę znaleźć wtyczki, która cachuje posty tylko z wybranych kategorii…

        1. Dzięki za rzucenie ciekawego tematu, chociaż myślałam, że czujesz niedosyt w temacie tego konkretnego artykułu. Ja specem od cache’owanie nie jestem, a nie lubię pisać o czymś, w czym nie czuję się biegle. Na tym blogu używam pluginu WP Super Cache i mi wystarcza. Natomiast ciekawa jestem w jakim celu chcesz cache’ować tylko wybrane kategorie? Nie wiem też, jaki jest Twój poziom zaawansowania w WP. Marcin Pietrzak na ostatnim WordCampie pokazywał klasy cache’ujące z core’owej części WP. Jeśli również kodujesz, to możesz zawsze spróbować sam pobawić się tymi funkcjami. Wówczas panujesz nad wszystkim od A do Z.

  5. Tego szukałem – – bardzo dziękuje za informację. Szczególnie te z wyświetlaniem błędów. Przy umieszczaniu zdjęć na serwer pojawiał się problem — nie wiedziałem jak go pokonać, teraz to już nawet naprawione 🙂

  6. „Pasek Web Developer” na Twoim screenie jest w wersji PL. Najnowsza wersja nie ma wersji PL? Pobrałam, ale wyświetla wszystko po angielsku, nie widzę opcji zmiany języka 🙁

    1. Ewa, czasami może tak być, że tłumaczenie pojawia się z opóźnieniem. Ja używam wersji anglojezycznej bo wówczas szybciej mi się utrwalają nazwy angielskie i wtedy łątwiej mi się szuka rzeczy w Googlu – wiem, jakich nazw używać w oryginale.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Wyrażam zgodę na przetwarzanie przez Webfaces Agnieszka Bury, ul. Rymarska 42/3, 53-206 Wrocław NIP: 9111769381, REGON: 021997379, moich danych osobowych w celu dodania komentarza na blogu webfaces.pl. (Sorry, takie są wymogi RODO, więcej informacji w Polityce prywatności).