top of page

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:

  1. x dni na konsultacje projektowe

  2. y dni na kodowanie

  3. z – na testy deweloperskie

  4. 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:

  1. wyrobić sobie pewne nawyki, które pozwolą lepiej kontrolować prace programistyczne na bieżąco

  2. poznać różne sposoby wychwytywania błędów

  3. 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

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:

  1. wystąpił błąd i mamy „efekt białej strony” w WordPressie

  2. php rzuca informacją o błędzie, która jest dla nas zbyt ogólna

  3. chcemy się dowiedzieć, które spośród użytych funkcji php są już przestarzałe (niezalecane)

  4. 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:

  1. 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).

  2. ułatwia rozpoznanie działania motywu – widać, jaka templatka jest odpowiedzialna za wygenerowanie danej strony, jaki jest identyfikator wpisu

  3. 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:

  1. WordPress jako CMS – najczęstsze błędy deweloperów

0 wyświetleń0 komentarzy

Ostatnie posty

Zobacz wszystkie