Lettura e comprensione dei log degli errori di WordPress, parte 2

L’ultima volta, abbiamo esaminato quanto segue:

1. configurazione delle costanti di debug,
2. trovare un file di registro degli errori,
3. capire come leggere il file di registro,
4. comprensione delle tracce dello stack
5. capire come leggere lo stack

Per quanto sia bello, è comunque importante capire come scrivere i dati nel registro degli errori da un aspetto programmatico. Vale a dire; una cosa è se il tuo lavoro genera errori, avvisi o avvisi.

È un’altra cosa se vuoi capire come scrivere manualmente le informazioni nel file per la ricerca e il debug.

In questo post, continueremo a fare esattamente questo per approfondire la nostra comprensione dei log degli errori di WordPress.

Comprensione dei log degli errori di WordPress, parte 2

Qual è lo scopo di scrivere nel registro degli errori, comunque? Voglio dire, fa anche parte del processo di debug?

Dal post precedente :

Ma che dire del caso in cui vogliamo scaricare qualcosa per ottenere informazioni su ciò che WordPress o PHP stanno vedendo? Anche questo è utile.

Quando i programmatori pensano al debug, molti di loro pensano di usare un vero debugger (cioè un pezzo di software), impostare punti di interruzione e scorrere il codice per osservare il valore delle variabili durante l’esecuzione del programma.

Arriveremo a quel punto, ma prima di farlo, diamo un’occhiata a come possiamo scrivere noi stessi nel registro degli errori per darci un’idea delle prestazioni del nostro lavoro.

Dopotutto, una cosa è se il nostro lavoro lancia avvisi, errori e avvisi. È un altro se ci sono informazioni che vogliamo vedere. Ed è qui che entra in gioco la scrittura nel registro degli errori.

Comprendere le funzioni PHP

Per scrivere nel log degli errori, è importante comprendere due funzioni PHP:

1. registro_errori
2. stampa_r

Per quanto riguarda la funzione error_log, si noti che il suo scopo è:

Invia un messaggio di errore alle routine di gestione degli errori definite

Nella maggior parte dei casi, questo è configurato per scrivere nel file di registro per noi tramite la configurazione predefinita di WordPress e PHP. Ma c’è di più perché spesso vorremo restituire i valori di variabili, array, oggetti e così via.

A tal fine, è necessario essere in grado di utilizzare print_r insieme a error_log. print_r esegue le seguenti operazioni:

Stampa informazioni leggibili dall’uomo su una variabile

E se leggi il manuale, noterai che sono necessari due argomenti, il secondo dei quali dovrebbe essere impostato su true se vuoi che il risultato di una funzione venga stampato nel file di registro.

Nello specifico, come recita il manuale:

Se desideri acquisire l’output di print_r(), utilizza il returnparametro. Quando questo parametro è impostato su TRUE, print_r() restituirà le informazioni anziché stamparle.

Quindi l’idea generale di scrivere il valore di un array, diciamo $exampleArray, sarebbe simile a questa :

<?php

error_log(print_r($exampleArray, true));

Ma che dire nel contesto di WordPress?

Scrivere valori nel registro degli errori in WordPress

Quindi quanto sopra delinea le funzioni integrate in PHP di cui abbiamo bisogno, ma che aspetto ha nel contesto dello sviluppo di WordPress.

Per fare ciò, supponiamo di aver implementato una versione del Registry Pattern. Nella nostra implementazione del pattern, abbiamo anche un metodo chiamato start che possiamo chiamare una volta che tutti i nostri oggetti sono stati aggiunti al registro.

Potrebbe assomigliare a questo:

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

Ora, per quanto riguarda l’implementazione, questo è semplice. Ma cosa succede se vogliamo vedere quali oggetti vengono invocati tramite ogni iterazione del ciclo.

L’idea alla base di questo è che siamo in grado di scorrere gli oggetti archiviati e di chiamare un metodo su ciascuno di essi. Ciò si basa sull’idea che ciascuno degli oggetti ha un metodo disponibile su ciascuno di essi (che può essere imposto da un’interfaccia ).

In primo luogo, questo solleva una domanda: perché potremmo volerlo fare? A causa della natura del sistema di gestione degli eventi di WordPress, forse vogliamo assicurarci che ogni oggetto che ci aspettiamo venga attivato si attivi.

In secondo luogo, come possiamo vedere quali oggetti vengono invocati? È qui che entra in gioco la scrittura nel registro degli errori. Usando i metodi che abbiamo delineato sopra, un modo per farlo sarebbe quello di fare quanto segue :

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

Ciò risulterà nel seguente output:

Qui puoi vedere l’oggetto; è lo spazio dei nomi, i suoi valori di proprietà (incluso se le proprietà sono private, protette, pubbliche e così via).

Da lì, puoi quindi eseguire un po ‘di debug se l’output è quello che non ti aspettavi o forse puoi usarlo per verificare che il tuo codice stia facendo ciò che ti aspetteresti.

Questo è solo un esempio, però. Puoi, tuttavia, scaricare i valori della variabile $storage prima ancora di scorrere il ciclo. Quella scelta dipende davvero da te e da ciò che stai cercando di ottenere.

Utilizzo dei plugin installati

A questo punto, abbiamo trattato gli aspetti fondamentali del codice di debug tramite l’uso dei log degli errori.

Ora, però, dobbiamo rivolgere la nostra attenzione ai plugin di cui abbiamo discusso alcuni post fa. Dopodiché, alla fine lavoreremo fino a Xdebug.

Ma successivamente, esamineremo gli strumenti a nostra disposizione all’interno di WordPress stesso.