Kontynuując przyglądanie się, co to znaczy być niezależnym programistą WordPressa, potrzebnymi narzędziami i różnymi strategiami, które mogą poprawić nasz zestaw umiejętności, omawiałem różne stałe, wtyczki i narzędzia, które mogą nam pomóc.
Jeśli po prostu natkniesz się na ten post, polecam zapoznanie się z moim przewodnikiem po natywnych narzędziach do debugowania WordPressa, a także z resztą dotychczasowych postów z serii .
W końcu uważam, że ważne jest, abyśmy wszyscy pracowali na tym samym fundamencie – lub czymś blisko spokrewnionym – kiedy przeglądamy te informacje.
Ostatecznie użycie narzędzia takiego jak Xdebug jest nieodzowne, ale musimy do tego dopracować (dla ciekawskich napisałem na ten temat krótki przewodnik nieco ponad rok temu).
Na razie jednak zacznijmy od podstaw. W poprzednim poście wyszedłem z następującym oświadczeniem:
W następnym poście zaczniemy zastanawiać się, co jest konieczne, aby sprawdzić dziennik błędów generowany przez WordPress i jak zrozumieć wyświetlane informacje.
I to jest to, na co chcę dzisiaj spojrzeć, ponieważ, jeśli nic więcej, to da ci coś praktycznego, nad czym możesz pracować.
Zrozumienie dzienników błędów WordPress, część 1
Zanim zagłębię się w to zbyt daleko, chcę odpowiedzieć na jedno pytanie, które zostało zadane przez członka witryny.
Mianowicie zapytano mnie:
Kiedy przyjrzymy się zasadom obiektowym?
Chociaż omówiłem to trochę w poprzedniej serii, to jest coś, nad czym pracuję bardziej szczegółowo w dalszej części tej serii.
Mając to na uwadze, zacznijmy jednak przeglądać dzienniki błędów.
Konfiguracja stałych
Jeśli nie skonfigurowałeś stałych w swoim pliku wp-config.php, polecam zrobić to teraz, ponieważ zapewni to najwyższy poziom szczegółowości podczas badania wszelkich problemów, które mogą się pojawić.
Jeśli nie nadrobiłeś zaległości, koniecznie przeczytaj ten post (a jeśli tak, upewnij się, że w twoim pliku konfiguracyjnym są zdefiniowane następujące stałe ):
<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );
define( 'SCRIPT_DEBUG', true );
define( 'SAVEQUERIES', true );Po ich wprowadzeniu masz wszystko, czego potrzebujesz, aby nie tylko widzieć informacje na ekranie, ale także w dzienniku debugowania, który wygeneruje WordPress.
Gdzie jest dziennik?
W zależności od charakteru Twojego środowiska może się to różnić; jednak w większości przypadków debug.log znajdziesz w katalogu wp-content znajdującym się nad katalogami plugins, theme i uploads.
Jak widać na podglądzie powyższego zrzutu ekranu, mój plik debugowania zawiera dużo treści. Przyjrzymy się temu bardziej szczegółowo w następnej sekcji, a także jak to zrozumieć. W międzyczasie sprawdź, czy ten plik w ogóle istnieje. Jeśli tak, możesz śmiało przejrzeć zawartość pliku. Możesz lub nie rozumiesz wiele z tego, co się dzieje, ale zawartość pliku oznacza, że coś w motywie lub wtyczce wyzwala różne ostrzeżenia, powiadomienia i błędy PHP, które WordPress przechwytuje i zrzuca do pliku dziennika.
Co nawet oznacza plik dziennika?
Niekoniecznie oznacza to, że coś jest zepsute, ale oznacza, że coś nie działa tak, jak powinno, nie jest prawidłowo przechwytywane i obsługiwane na poziomie programistycznym lub po prostu robi coś, czego nie powinno.
Nie musi tak wyglądać (ale może!).
Jako programiści powinniśmy dążyć do tego, aby nasz kod nie generował niczego, co byłoby zapisane w dzienniku błędów.
Robienie tego w fazie rozwoju to jedno, ponieważ jesteśmy w stanie uzyskać wgląd w to, co robimy i jak działa WordPress. To jednak inna sprawa, że coś, co wydajemy na poziomie produkcyjnym, generuje takie rzeczy.
Odczytywanie dziennika błędów
Oczywiście, czytanie dziennika błędów to coś więcej niż tylko jego otwieranie. Dla wielu pierwsze wrażenie jest takie, że może to być mnóstwo żargonu. To też rozumiem. Ale kiedy zrozumiesz, co ci pokazuje, znacznie łatwiej to zrozumieć.
Spójrzmy więc na naprawdę prosty przykład. To też nie jest wymyślony przykład. Właściwie to pochodzi z wtyczki, nad którą pracowałem. Dziennik błędów zawiera następujące informacje :
[05-Jul-2018 19:43:53 UTC] PHP Fatal error: Uncaught Error: Class 'EasyEmailExportAdminEmailExportSubmenu' not found in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php:37
#8 /U in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 37
[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(./src/Admin/EmailExportSubmenu.php): failed to open stream: No such file or directory in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25
[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(): Failed opening './src/Admin/EmailExportSubmenu.php' for inclusion (include_path='.:/usr/local/Cellar/php/7.2.5/share/php/pear') in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25Zauważ, że w powyższym tekście znajdują się trzy linie. Najlepszym sposobem postępowania podczas czytania dzienników błędów jest rozpoczęcie od dołu i pójście w górę. Dzieje się tak, ponieważ rzeczy podczas wykonywania działają na stosie.
Krótka dygresja na stosach
Nie będę wchodził w definicję tego terminu w informatyce, ale kod jest wykonywany i działa w taki sposób, że funkcje występują i całkiem dosłownie, w pamięci komputera, układają się jedna na drugiej.
Tak więc najnowsza rzecz do uruchomienia zawsze będzie znajdować się na górze, gdzie korzeń miejsca, w którym się zaczyna, znajduje się na dole. Ponieważ piszemy kod we wcześniej istniejącej aplikacji, czyli WordPress; wtedy nasz kod prawdopodobnie zawsze będzie na górze.
Zrozumienie dzienników błędów WordPress: to nie ten rodzaj stosu
Pomysł polega na tym, że kod zacznie być wykonywany w WordPressie i będzie zmierzał do pracy, którą wykonujemy. Gdy pojawi się powiadomienie, ostrzeżenie lub błąd, zwykle będzie to coś w naszym kodzie (chociaż WordPress nie jest z tego wyjątek, generalnie tak jest).
Więc kiedy czytasz dziennik błędów, w istocie czytasz to, co nazywa się śladem stosu. Wikipedia, do której prowadzi link, ma dość dogłębną definicję na ten temat, ale być może najbardziej odpowiedni fragment tego postu jest następujący:
Programiści często używają śledzenia stosu podczas interaktywnych i pośmiertnych [debugowania] (https://en.wikipedia.org/wiki/Debugging). Użytkownicy końcowi mogą zobaczyć ślad stosu wyświetlany jako część komunikatu o błędzie, który użytkownik może następnie zgłosić programiście.
To zgadza się z tym, co opisałem powyżej, prawda? Ale dość mówienia o tym, czym jest ślad stosu (będzie on bardziej przejrzysty, gdy zagłębimy się w debugowanie), wróćmy do odczytywania pliku dziennika w jego obecnym stanie.
Powrót do czytania dziennika
W tym pliki
Najpierw spójrzmy na dolną linię w sednie powyżej. Zawiera:
[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(): Failed opening './src/Admin/EmailExportSubmenu.php' for inclusion (include_path='.:/usr/local/Cellar/php/7.2.5/share/php/pear') in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25To mówi mi, że w wierszu 25 mojego pliku, easy-email-export.php, nie udało się otworzyć pliku do włączenia. Oznacza to, że mam instrukcję include_once w kodzie, która odwołuje się do ./src/Admin/EmailExportSubmenu.php, której nie można znaleźć.
Więc najlepszym sposobem działania byłoby znalezienie linii 25 i ustalenie, dlaczego nie znajduje pliku. Być może to zrzuca pełną ścieżkę, dokąd to patrzy. Dojdziemy do tego za chwilę, mówiąc o zapisie do dziennika błędów.
Zrozumienie błędów
W następnym wierszu (to jest wiersz powyżej tego, który właśnie przeglądaliśmy) zawiera:
[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(./src/Admin/EmailExportSubmenu.php): failed to open stream: No such file or directory in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25Ta konkretna linia różni się tylko nieznacznie, ale daje dodatkowy wgląd i jest zawarta w klauzuli o treści „Brak takiego pliku lub katalogu". Jest to wnikliwe, ponieważ dosłownie mówi nam, że plik nie istnieje.
Przynajmniej nie istnieje tam, gdzie patrzy. Więc dwie możliwości to:
- nie stworzyliśmy pliku, którym jesteśmy referencjami,
- odwołujemy się do lokalizacji pliku w niewłaściwym miejscu
Dlatego pierwszą rzeczą, którą musimy sprawdzić, jest to, czy plik istnieje w lokalizacji, którą próbujemy uwzględnić. Jeśli tak się nie stanie, powinniśmy utworzyć plik.
Jeśli plik istnieje, wiemy, że wtyczka próbuje załadować go z niewłaściwej ścieżki. Być może będziemy musieli spojrzeć na nasz autoloader, naszą ścieżkę włączenia lub sposób pobierania plików. Ponieważ szanse są takie, że jeśli plik istnieje, to próbuje zostać załadowany z miejsca, w którym nie znajduje się.
Niewyłapany błąd
W ostatniej linii kodu zobaczysz coś takiego:
[05-Jul-2018 19:43:53 UTC] PHP Fatal error: Uncaught Error: Class 'EasyEmailExportAdminEmailExportSubmenu' not found in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php:37
#8 /U in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 37To dobry przykład, po pierwsze, ponieważ wyraźnie deklaruje, że jest to niewyłapany błąd. Oznacza to, że niezależnie od funkcjonalności, coś zgłasza błąd i nie jest wyłapywane.
- to może być wyjątek,
- może to być problem przy próbie wywołania funkcji, która nie istnieje,
- może to działać na zmiennej, która nie jest zdefiniowana,
- i tak dalej.
Ostatecznie istnieje mnóstwo problemów, które mogą być obecne. Dobrą wiadomością w tym przykładzie jest to, że jest praktycznie taki sam jak powyżej: nie znaleziono pliku.
Z wyjątkiem tego, że zamiast rzucać ostrzeżenie, PHP jawnie śledzi nas, że jest to błąd krytyczny i program nie może kontynuować wykonywania, dopóki ten wiersz kodu nie zostanie rozwiązany. Zanim odrzucimy to jako coś, co jest takie samo jak w poprzedniej sekcji (ponieważ, w pewnym sensie, tak jest), musimy uznać, że jest to wyraźnie określone jako błąd krytyczny, podczas gdy w poprzednim przykładzie było to traktowane jako błąd ostrzeżenie.
Są różne sposoby konceptualizacji tego, ale generalnie myślę o tym tak:
- Powiadomienie mówi mi, że coś jest nie tak w kodzie, ale nie jest to wystarczająco złe, aby uzasadnić zatrzymanie wykonania.
- Ostrzeżenie jest nieco poważniejsze, ponieważ oznacza, że coś może nie działać.
- Błąd od razu mówi „to nie działa i program nie może kontynuować”.
Teraz wiemy, że problem się kończy, że tak powiem, i wiemy, na czym polega problem. Mówiąc najprościej, plik, który jest wymagany do zakończenia działania programu, nie został znaleziony, a zatem program przestaje działać.
To z pewnością fatalny błąd.
Jakie jest rozwiązanie?
To, co przedstawiam jako rozwiązanie mojego problemu, nie będzie nakazem tego, co będzie dla ciebie skuteczne. Dla mnie była to kwestia wiersza w mojej konfiguracji Composera, tak aby autoloader Composera nie mógł zlokalizować pliku we właściwej lokalizacji (ale ma to więcej wspólnego z organizacją plików, przestrzenią nazw i tak dalej).
Dla ciebie może to być coś innego.
- może szuka pliku w złym katalogu,
- może plik ma inną nazwę niż to, co jest określone w kodzie,
- a może to coś innego.
W każdym razie chodzi o to, aby przejść przez plik dziennika od dołu do góry, aby zdiagnozować problem i prześledzić, co robi PHP, WordPress i twoja praca, a następnie zdiagnozować to stamtąd.
Zapisywanie do dziennika błędów
W następnym poście poświęcimy chwilę, aby zobaczyć, jak możemy pisać do dziennika błędów. Czasami czytanie pliku jest w porządku, a po prostu przechodzenie między tym, co widzimy, a rozwiązywaniem problemów, jest miłe.
Ale co z przypadkiem, gdy chcemy coś zrzucić, aby uzyskać wgląd w to, co widzi WordPress lub PHP? To też jest przydatne.
W następnej części tej serii poświęconej zrozumieniu dzienników błędów WordPressa zrobimy dokładnie to.
Co dalej?
Następnie przyjrzymy się, jak używać niektórych wtyczek opisanych wcześniej do testowania kodu, a także do profilowania naszego kodu, aby upewnić się, że zrobiliśmy wszystko, co w naszej mocy, aby zapewnić produkcję na odpowiednim poziomie.
Nie oznacza to, że proces debugowania został całkowicie zakończony, ale zdecydowanie jesteśmy o krok bliżej i jesteśmy w stanie pisać kod o takiej jakości, która nie skutkuje powstaniem pliku reprezentującego różne niuanse problemów byliśmy zbyt nieostrożni, aby naprawić (nie mówiąc już o zrozumieniu).