Ogni volta che lavoro su un progetto, ho spesso WordPress impostato in modalità di debug e mi piace scrivere messaggi nel registro degli errori che posso facilmente visualizzare, tracciare e seguire ogni volta che lavoro su un progetto.
Quando lo faccio, ci sono due modi (e dipende solo dal progetto):
- Userò una libreria come Monolog ,
- Userò la mia semplice funzione di registro.
In questo post tratterò quest’ultimo. Cioè, condividerò come scrivo messaggi nel registro di debug di WordPress e poi alcune delle cose a cui potresti dover prestare attenzione ogni volta che fai lo stesso.
Il registro di debug di WordPress
Innanzitutto, è importante notare che la funzione che ho intenzione di condividere è solitamente nel contesto di una classe base.
Diciamo che ho un AbstractSubscriber implementato da tutti i miei abbonati (come uno ScriptAssetSubscriber per la registrazione e l’accodamento del file JavaScript).
AbstractSubscriber includerà questa funzione in modo che possa essere chiamata da qualsiasi classe figlio. La funzione è abbastanza semplice:
<?php
/**
* Prints a message to the debug file that can easily be called by any subclass.
*
* @param mixed $message an object, array, string, number, or other data to write to the debug log
* @param bool $shouldNotDie whether or not the The function should exit after writing to the log
*
*/
protected function log($message, $shouldNotDie = true)
{
error_log(print_r($message, true));
if ($shouldNotDie) {
exit;
}
}Ma ci sono diverse cose su questa funzione che possono violare un principio o innescare errori negli strumenti di qualità del codice.
Argomenti booleani opzionali
Ogni volta che una funzione accetta un argomento booleano facoltativo, può indicare che una funzione ha più di una responsabilità (violando così il principio di responsabilità singola ).
Il motivo per cui ciò violerebbe detto principio è che fornisce a un modulo più di una ragione per cambiare.
Mi sento a mio agio nel consentire che questo venga scritto in questo modo perché lo uso per il debug, non per gli ambienti di produzione e perché ci sono momenti in cui potrei voler interrompere l’esecuzione e ci sono momenti in cui non lo faccio.
E certo, potrei scrivere due funzioni separate, ma se questa è l’unica funzione che lo fa, mi va bene.
Dichiarazioni di uscita vietate
Altri strumenti per la qualità del codice non amano l’ istruzione exit (e, allo stesso modo, non amano l’ istruzione die ). E comprensibilmente: in genere bloccano completamente il programma quando dovremmo lanciare un’eccezione, restituire un valore o in generale fare qualcosa per gestire la situazione con grazia.
Ancora una volta, però, poiché in questa funzione ci sono momenti in cui voglio interrompere l’esecuzione, sto bene affrontare le conseguenze di avere la riga di codice nella funzione.
In alternativa, potrei usare wp_die() e la maggior parte degli strumenti di qualità del codice probabilmente non lo catturerebbero, ma questo sta mascherando il problema principale. Semmai, forse è meglio semplicemente sopprimere l’avviso usando qualsiasi direttiva consentita dal tuo sniffer di scelta.
Indipendentemente da ciò, registra il messaggio
In definitiva, lo scopo della funzione sopra è quello di fornire un modo semplice per scrivere nel registro di debug di WordPress e, facoltativamente, interrompere l’esecuzione del programma quando lo si fa.
Chiaramente non è privo di problemi e sono disponibili librerie di qualità superiore, ma a volte non è necessario un martello per una puntina da disegno problematica.