Läsa och förstå WordPress-felloggar, del 2

Förra gången gick vi igenom följande:

1. konfigurera felsökningskonstanter,
2. hitta en felloggfil,
3. förstå hur man läser loggfilen,
4. förstå stackspår
5. förstå hur man läser stacken

Hur trevligt det än är, det är fortfarande viktigt att förstå hur man skriver data till fellogg ur en programmatisk aspekt. Det vill säga; det är en sak om ditt arbete ger fel, varningar eller meddelanden.

Det är en annan sak om du vill förstå hur man skriver information till filen för forskning och felsökning manuellt.

I det här inlägget kommer vi att fortsätta att göra exakt det för att förbättra vår förståelse för WordPress-felloggar.

Förstå WordPress-felloggar, del 2

Vad är poängen med att skriva till felloggen? Jag menar, är det ens en del av felsökningsprocessen?

Från förra inlägget :

Men hur är det med fallet när vi vill dumpa något för att få insikt om vad WordPress eller PHP ser? Det är också användbart.

När programmerare tänker på felsökning, tänker många av dem på att använda en verklig debugger (det vill säga en mjukvara), ställa in brytpunkter och gå igenom koden för att se värdet på variabler när programmet körs.

Vi kommer att komma till den punkten men innan vi gör det, låt oss ta en titt på hur vi själva kan skriva till felloggen för att ge oss insikt om hur vårt arbete fungerar.

När allt kommer omkring är det en sak om vårt arbete är att kasta varningar, fel och meddelanden. Det är en annan om det finns information som vi vill se. Och det är där att skriva till felloggen kommer in i bilden.

Förstå PHP-funktioner

För att skriva till felloggen är det viktigt att förstå två PHP-funktioner:

1. felloggen
2. print_r

När det gäller funktionen error_log, notera att dess syfte är att:

Skicka ett felmeddelande till de definierade felhanteringsrutinerna

I de flesta fall är detta konfigurerat för att skriva till loggfilen för oss via standardkonfigurationen för WordPress och PHP. Men det finns mer än så eftersom vi ofta kommer att vilja mata ut värden för variabler, arrayer, objekt och så vidare.

För detta ändamål måste du kunna använda print_r tillsammans med error_log. print_r gör följande:

Skriver ut läsbar information om en variabel

Och om du läser manualen kommer du att märka att det krävs två argument, varav det andra ska vara satt till sant om du vill att resultatet av en funktion ska skrivas ut till loggfilen.

Specifikt, som manualen säger:

Om du vill fånga utdata från print_r(), använd returnparametern. När denna parameter är inställd på TRUEkommer print_r() att returnera informationen istället för att skriva ut den.

Så den allmänna idén att skriva värdet på en array, säg $exampleArray, skulle se ut ungefär så här :

<?php

error_log(print_r($exampleArray, true));

Men hur är det med WordPress?

Skriva värden till felloggen i WordPress

Så ovanstående skisserar de funktioner som är inbyggda i PHP som vi behöver, men hur ser detta ut i samband med WordPress-utveckling.

För att göra detta, låt oss säga att vi har implementerat en version av Registry Pattern. I vår implementering av mönstret har vi också en metod som heter start som vi kan anropa när alla våra objekt har lagts till i registret.

Det kan se ut ungefär så här:

<?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();
    }
}

Nu när det gäller implementeringen är detta okomplicerat. Men tänk om vi vill se vilka objekt som anropas via varje iteration av loopen.

Tanken bakom detta är att vi kan iterera genom de lagrade objekten och anropa en metod för vart och ett av dem. Detta bygger på idén att vart och ett av objekten har en metod tillgänglig på vart och ett av dem (som kan genomdrivas av ett gränssnitt ).

För det första väcker detta en fråga: Varför kan vi vilja göra det? På grund av naturen hos WordPress evenemangshanteringssystem vill vi kanske se till att varje objekt som vi förväntar oss att skjuta avfyrar.

För det andra, hur kan vi se vilka objekt som anropas? Det är här att skriva till felloggen kommer in i bilden. Med hjälp av metoderna som vi har beskrivit ovan skulle ett sätt att göra det vara att göra följande :

<?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();
    }
}

Detta kommer att resultera i följande utdata:

Här kan du se objektet; det är namnutrymme, det är egenskapsvärden (inklusive om fastigheterna är privata, skyddade, offentliga och så vidare).

Därifrån kan du sedan göra lite felsökning om utdata är vad du inte förväntade dig eller kanske du kan använda detta för att verifiera att din kod gör vad du förväntar dig.

Detta är dock bara ett exempel. Du kan dock dumpa värdena för $storage- variabeln innan du ens itererar genom loopen. Det valet är verkligen upp till dig och vad du vill uppnå.

Använda de installerade plugins

Vid det här laget har vi täckt de grundläggande aspekterna av felsökning av kod genom att använda felloggar.

Nu måste vi dock vända vår uppmärksamhet mot plugins som diskuterades för några inlägg sedan. Efter det kommer vi så småningom att arbeta oss upp till Xdebug.

Men härnäst ska vi titta på de verktyg som är tillgängliga för oss från själva WordPress.