Czytanie i zrozumienie dzienników błędów WordPress, część 2

Ostatnim razem przeszliśmy przez następujące czynności:

1. konfigurowanie stałych debugowania,
2. zlokalizowanie pliku dziennika błędów,
3. zrozumienie, jak czytać plik dziennika,
4. zrozumienie śladów stosu
5. zrozumienie, jak czytać stos

Choć jest to miłe, nadal ważne jest, aby zrozumieć, jak zapisywać dane do dziennika błędów z aspektu programistycznego. To jest do powiedzenia; to jedno, jeśli twoja praca rzuca błędy, ostrzeżenia lub powiadomienia.

To inna sprawa, jeśli chcesz zrozumieć, jak ręcznie zapisywać informacje do pliku do badań i debugowania.

W tym poście będziemy kontynuować dokładnie to, aby lepiej zrozumieć dzienniki błędów WordPress.

Zrozumienie dzienników błędów WordPress, część 2

Po co w ogóle pisać do dziennika błędów? Chodzi mi o to, czy jest to nawet część procesu debugowania?

Z poprzedniego posta :

Ale co z przypadkiem, gdy chcemy coś zrzucić, aby uzyskać wgląd w to, co widzi WordPress lub PHP? To też jest przydatne.

Kiedy programiści myślą o debugowaniu, wielu z nich myśli o użyciu rzeczywistego debuggera (czyli kawałka oprogramowania), ustawianiu punktów przerwania i przechodzeniu przez kod, aby obserwować wartości zmiennych podczas wykonywania programu.

Dojdziemy do tego punktu, ale zanim to zrobimy, przyjrzyjmy się, jak sami możemy zapisywać w dzienniku błędów, aby uzyskać wgląd w to, jak działa nasza praca.

W końcu to jedno, jeśli nasza praca polega na rzucaniu ostrzeżeń, błędów i powiadomień. To kolejna, jeśli są informacje, które chcemy zobaczyć. I tu wchodzi w grę zapisywanie do dziennika błędów.

Zrozumienie funkcji PHP

Aby zapisywać w dzienniku błędów, ważne jest zrozumienie dwóch funkcji PHP:

1. dziennik_błędów
2. print_r

Jeśli chodzi o funkcję error_log, zwróć uwagę, że jej celem jest:

Wyślij wiadomość o błędzie do zdefiniowanych procedur obsługi błędów

W większości przypadków jest to ustawienie zapisu do pliku dziennika za nas za pomocą domyślnej konfiguracji WordPress i PHP. Ale jest w tym coś więcej, ponieważ często będziemy chcieli wypisać wartości zmiennych, tablic, obiektów i tak dalej.

W tym celu musisz mieć możliwość używania print_r w połączeniu z error_log. print_r wykonuje następujące czynności:

Wyświetla czytelne dla człowieka informacje o zmiennej

A jeśli przeczytasz podręcznik, zauważysz, że wymaga dwóch argumentów, z których drugi powinien być ustawiony na true, jeśli chcesz, aby wynik funkcji został wydrukowany do pliku dziennika.

W szczególności, jak stwierdza podręcznik:

Jeśli chcesz przechwycić dane wyjściowe print_r(), użyj returnparametru. Gdy ten parametr jest ustawiony na TRUE, print_r() zwróci informacje zamiast je wydrukować.

Ogólna idea zapisania wartości tablicy, powiedzmy $exampleArray, wyglądałaby mniej więcej tak :

<?php

error_log(print_r($exampleArray, true));

Ale co w kontekście WordPressa?

Zapisywanie wartości do dziennika błędów w WordPress

Powyższe przedstawia funkcje wbudowane w PHP, których potrzebujemy, ale jak to wygląda w kontekście rozwoju WordPressa.

Aby to zrobić, załóżmy, że zaimplementowaliśmy wersję wzorca rejestru. W naszej implementacji wzorca mamy również metodę o nazwie start, którą możemy wywołać po dodaniu wszystkich naszych obiektów do rejestru.

Może wyglądać mniej więcej tak:

<?php

/**
 * Starts all of the objects stored is the registry by calling
 * the `start` method that's available on each of the objects.
 */
public function start()
{
    foreach ($this->storage as $obj) {
        $obj->start();
    }
}

Teraz, jeśli chodzi o wdrożenie, jest to proste. Ale co, jeśli chcemy zobaczyć, jakie obiekty są wywoływane w każdej iteracji pętli.

Ideą tego jest to, że jesteśmy w stanie iterować przez przechowywane obiekty i wywołać metodę na każdym z nich. Opiera się to na założeniu, że każdy z obiektów ma dostępną dla każdego z nich metodę (którą można wymusić za pomocą interfejsu ).

Po pierwsze, rodzi się pytanie: dlaczego możemy chcieć to zrobić? Ze względu na charakter systemu zarządzania zdarzeniami WordPress, być może chcemy się upewnić, że każdy obiekt, który ma zostać uruchomiony, zostanie uruchomiony.

Po drugie, jak możemy zobaczyć, jakie obiekty są przywoływane? Tutaj wchodzi w grę zapisywanie do dziennika błędów. Korzystając z metod, które opisaliśmy powyżej, jednym ze sposobów na to byłoby wykonanie następujących czynności :

<?php

/**
 * Starts all of the objects stored is the registry by calling
 * the `start` method that's available on each of the objects.
 */
public function start()
{
    foreach ($this->storage as $obj) {
        error_log(print_r($obj, true));
        $obj->start();
    }
}

Spowoduje to następujące dane wyjściowe:

Tutaj możesz zobaczyć przedmiot; jest to przestrzeń nazw, to wartości właściwości (w tym, czy właściwości są prywatne, chronione, publiczne itd.).

Stamtąd możesz wykonać trochę debugowania, jeśli dane wyjściowe są takie, jakich się nie spodziewałeś, lub może możesz użyć tego do sprawdzenia, czy Twój kod robi to, czego oczekiwałeś.

To tylko jeden przykład. Możesz jednak zrzucić wartości zmiennej $storage, zanim jeszcze przejdziesz przez pętlę. Ten wybór zależy od Ciebie i tego, co chcesz osiągnąć.

Korzystanie z zainstalowanych wtyczek

W tym momencie omówiliśmy podstawowe aspekty debugowania kodu za pomocą dzienników błędów.

Teraz jednak musimy zwrócić uwagę na wtyczki, które zostały omówione kilka postów temu. Potem w końcu będziemy pracować nad Xdebug.

Ale następnie przyjrzymy się dostępnym narzędziom z samego WordPressa.