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

Mentre continuiamo a guardare cosa significa essere uno sviluppatore WordPress indipendente, gli strumenti necessari e le varie strategie che possono migliorare il nostro set di competenze, ho parlato delle varie costanti, plug-in e strumenti per aiutarci.

Se ti sei appena imbattuto in questo post, ti consiglio di consultare la mia guida agli strumenti di debug nativi di WordPress e il resto dei post della serie finora.

Dopotutto, trovo importante che stiamo tutti lavorando sulla stessa base – o qualcosa di strettamente correlato – quando esaminiamo queste informazioni.

In definitiva, utilizzare uno strumento come Xdebug è indispensabile, ma dobbiamo lavorare fino a questo (per i curiosi, ho scritto una breve guida su questo poco più di un anno fa).

Per ora, però, iniziamo con le basi. Nel post precedente, ho lasciato con la seguente dichiarazione:

Nel prossimo post, inizieremo a esaminare ciò che è necessario per esaminare il registro degli errori generato da WordPress e come comprendere le informazioni che vediamo.

Ed è quello che voglio guardare oggi perché, se non altro, ti darà qualcosa di pratico su cui lavorare.

Comprensione dei log degli errori di WordPress, parte 1

Prima di entrare troppo in questo, voglio affrontare una domanda che è stata sollevata da un membro del sito.

Vale a dire, mi è stato chiesto:

Quando esamineremo i principi orientati agli oggetti?

Anche se ne ho parlato un po’ in una serie precedente, è qualcosa che sto lavorando per approfondire più avanti in questa serie.

Detto questo, tuttavia, iniziamo a guardare i registri degli errori.

Configurare le tue costanti

Se non hai configurato le costanti nel tuo file wp-config.php, ti consiglio di farlo ora in quanto ciò ti darà il massimo livello di granualità durante l’esame di eventuali problemi che potrebbero sorgere.

Se non hai raggiunto, assicurati di leggere questo post (e se lo hai fatto, assicurati che le seguenti costanti siano definite nel tuo file di configurazione):

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

Una volta che sono a posto, hai tutto ciò di cui hai bisogno non solo per vedere le informazioni sullo schermo, ma anche nel registro di debug che WordPress genererà.

Dov’è il registro?

A seconda della natura del tuo ambiente, questo può variare; tuttavia, nella maggior parte dei casi, troverai debug.log nella directory wp-content che si trova sopra le directory plugin, temi e caricamenti.

Come puoi vedere dall’anteprima dello screenshot sopra, il mio file di debug contiene molti contenuti. Daremo un’occhiata più in profondità nella prossima sezione e come capirlo. Nel frattempo, però, controlla se questo file esiste. In tal caso, sentiti libero di andare avanti e esaminare il contenuto del file. Potresti capire o meno molto di ciò che sta succedendo, ma il contenuto del file significa che qualcosa in un tema o plug-in sta attivando vari avvisi, avvisi ed errori PHP che WordPress sta rilevando e scaricando nel file di registro.

Che cosa significa anche il file di registro?

Questo non significa necessariamente che qualcosa sia rotto, ma indica che qualcosa non sta funzionando come dovrebbe, non viene catturato e gestito correttamente a livello di programmazione o sta semplicemente facendo qualcosa che non dovrebbe fare.

Non deve apparire così (ma può!).

Come sviluppatori, dovremmo sforzarci di assicurarci che il nostro codice non generi nulla che verrebbe scritto nel registro degli errori.

Una cosa è farlo in fase di sviluppo in quanto siamo in grado di ottenere informazioni dettagliate su ciò che stiamo facendo e sulle prestazioni di WordPress. È un’altra cosa, però, per qualcosa che pubblichiamo a livello di produzione per generare cose del genere.

Lettura del registro degli errori

Ovviamente, c’è di più nella lettura del registro degli errori piuttosto che nell’aprirlo. Per molti, l’impressione iniziale è che possa essere un mucchio di gergo. Lo capisco anche io. Ma quando capisci cosa ti sta mostrando, è molto più facile da capire.

Quindi diamo un’occhiata a un esempio davvero semplice. Neanche questo è un esempio forzato. In effetti, questo è uno che proviene da un plug-in su cui stavo lavorando. Il registro degli errori contiene le seguenti informazioni :

[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 25

Si noti che, nel succo di cui sopra, ci sono tre righe. La migliore linea d’azione durante la lettura dei registri degli errori è iniziare dal basso e risalire. Questo perché le cose quando sono in esecuzione in esecuzione, operano su uno stack.

Una breve digressione sugli stack

Non entrerò nella definizione informatica del termine, ma il codice viene eseguito e funziona in modo tale che le funzioni si verificano e, letteralmente, nella memoria di un computer, si impilano l’una sull’altra.

Pertanto, la cosa più recente da eseguire sarà sempre in alto dove la radice di dove inizia è in basso. Dato che stiamo scrivendo codice su un’applicazione preesistente, questo è WordPress; allora è probabile che il nostro codice sia sempre in cima.

Comprendere i log degli errori di WordPress: non è questo tipo di stack

L’idea è che il codice inizierà l’esecuzione in WordPress e si farà strada fino al lavoro che stiamo facendo. Quando c’è un avviso, un avviso o un errore, di solito è qualcosa nel nostro codice (sebbene WordPress non sia esente, in genere è così).

Quindi, quando leggi il registro degli errori, stai, in sostanza, leggendo quella che viene chiamata traccia dello stack. Wikipedia, come collegata, ha una definizione piuttosto approfondita sull’argomento, ma forse la parte più rilevante per questo post è la seguente:

I programmatori usano comunemente la traccia dello stack durante il [debugging] interattivo e post mortem (https://en.wikipedia.org/wiki/Debugging). Gli utenti finali possono visualizzare una traccia dello stack visualizzata come parte di un messaggio di errore, che l’utente può quindi segnalare a un programmatore.

Questo si confonde con quello che ho delineato sopra, giusto? Ma basta parlare di cos’è una traccia dello stack (diventerà più chiaro man mano che approfondiamo il debug), torniamo a leggere il file di registro così com’è attualmente.

Torna a Lettura del registro

Compresi i file

Per prima cosa, diamo un’occhiata alla linea di fondo nel succo sopra. Contiene quanto segue:

[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 25

Questo mi sta dicendo che alla riga 25 del mio file, easy-email-export.php, non è riuscito ad aprire un file per l’inclusione. Ciò significa che ho un’istruzione include_once nel codice che fa riferimento a ./src/Admin/EmailExportSubmenu.php che non riesce a trovare.

Quindi la migliore linea d’azione sarebbe trovare la riga 25 e determinare perché non sta individuando il file. Forse questo sta scaricando l’intero percorso su dove sta guardando. Ci arriveremo momentaneamente quando parleremo di scrivere nel registro degli errori.

Dare un senso agli errori

Nella riga successiva (ovvero la riga sopra quella che abbiamo appena visto) contiene quanto segue:

[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

Questa particolare riga differisce solo leggermente ma fornisce ulteriori informazioni ed è contenuta nella clausola che recita "Nessun file o directory del genere". Questo è perspicace perché ci sta letteralmente dicendo che il file non esiste.

Almeno, non esiste dove sta guardando. Quindi le due possibilità sono:

1. non abbiamo creato il file a cui siamo riferimenti,
2. stiamo facendo riferimento alla posizione del file nel posto sbagliato

Pertanto, la prima cosa che dovremmo controllare è se il file esiste nella posizione che stiamo cercando di includere. In caso contrario, dovremmo creare il file.

Se il file esiste, allora sappiamo che il plugin sta cercando di caricarlo dal percorso sbagliato. Quindi potrebbe essere necessario esaminare il nostro caricatore automatico, il nostro percorso di inclusione o comunque i file vengono recuperati. Perché, le probabilità sono che se il file esiste, allora sta cercando di essere caricato da un posto in cui non risiede.

Un errore non rilevato

Nell’ultima riga del codice, vedrai qualcosa del genere:

[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

Questo è un buon esempio, in primo luogo, perché dichiara esplicitamente che si tratta di un errore non rilevato. Ciò significa che qualunque sia la funzionalità, qualcosa sta generando un errore e non viene rilevato.

• questa potrebbe essere un’eccezione,
• questo potrebbe essere un problema nel tentativo di chiamare una funzione che non esiste,
• questo potrebbe operare su una variabile che non è definita,
• e così via.

In definitiva, c’è una pletora di problemi che potrebbero essere presenti. La buona notizia, in questo esempio, è che è praticamente la stessa di quanto sopra: un file non è stato trovato.

Tranne che, invece di lanciare un avviso, PHP ci indica esplicitamente che si tratta di un errore fatale e il programma non può continuare l’esecuzione fino a quando questa riga di codice non viene risolta. Prima di liquidare questo come qualcosa che è lo stesso della sezione precedente (perché, per così dire, lo è), dobbiamo riconoscere che questo è esplicitamente dichiarato come un errore fatale mentre, nell’esempio precedente, è stato trattato come un avvertimento.

Ci sono diversi modi per concettualizzare questo, ma il modo in cui generalmente lo penso è questo:

• Un avviso mi dice che qualcosa non va nel codice, ma non è abbastanza grave da giustificare l’interruzione dell’esecuzione.
• Un avviso è leggermente più grave perché significa che qualcosa rischia di non funzionare.
• Un errore dice "questo non funziona e il programma non può procedere".

Ora sappiamo che il problema sta interrompendo lo spettacolo, per così dire, e sappiamo qual è il problema. In poche parole, un file necessario per il completamento dell’esecuzione del programma non viene trovato e quindi il programma smette di funzionare.

Questo è certamente un errore fatale.

Qual è la soluzione?

Ciò che fornisco come soluzione al mio problema non sarà prescrittivo su ciò che funzionerà per te. Per me, si trattava di una riga nella mia configurazione di Composer in modo tale che il caricatore automatico di Composer non potesse individuare il file nella posizione corretta (ma questo ha più a che fare con l’organizzazione dei file, lo spazio dei nomi e così via).

Per te, potrebbe essere qualcosa di diverso.

• forse sta cercando un file nella directory sbagliata,
• forse il file ha un nome diverso da quello specificato nel codice,
• o forse è qualcos’altro.

In ogni caso, il punto è che si tratta di procedere attraverso il file di registro dal basso verso l’alto per diagnosticare il problema e tracciare cosa stanno facendo PHP, WordPress e il tuo lavoro e quindi diagnosticarlo da lì.

Scrittura nel registro errori

Nel prossimo post, ci prenderemo un momento per vedere come possiamo scrivere nel registro degli errori. A volte, leggere il file va bene e semplicemente andare avanti e indietro tra ciò che stiamo vedendo e risolvere i problemi è bello.

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

Quindi, nella prossima parte di questa serie sulla comprensione dei log degli errori di WordPress, faremo esattamente questo.

Cosa c’è dopo?

Successivamente, esamineremo come utilizzare alcuni dei plug-in descritti in precedenza per testare il codice e anche per profilare il nostro codice per assicurarci di aver fatto tutto il possibile per assicurarci di produrre un livello di qualità.

Questo non significa che abbiamo completamente finito con il processo di debug, ma siamo sicuramente un passo più vicini e siamo posizionati per scrivere codice con un grado di qualità che non si traduce in un file che rappresenta vari problemi sfumati siamo stati troppo negligenti per sistemare (per non parlare di capire).