Attivare il debug
Il debug è il processo con cui si individuano e correggono gli errori che impediscono a un programma di funzionare correttamente. Il termine ha un’origine curiosa: negli anni Quaranta, una delle prime macchine di calcolo smise di funzionare perché una falena si era infilata nei relè. Gli ingegneri la trovarono, la rimostrarono e annotarono sul registro operativo. Da allora “bug” indica qualsiasi errore nel codice, e “debug” è il processo per eliminarlo.
In pratica, fare debug significa osservare il comportamento del programma, confrontarlo con quello atteso e risalire alla causa dello scostamento. Non si lavora a caso — si isola il problema, si restringe il campo, si verifica il flusso di esecuzione finché il punto di rottura non diventa evidente. È un lavoro che richiede metodo più che intuizione.
Il debug su WordPress
In WordPress questo processo segue le stesse logiche, ma si applica a un ecosistema specifico: un core, una serie di plugin e un tema che interagiscono continuamente attraverso un sistema di hook e filtri. Quando qualcosa non funziona — una pagina che non si carica, una funzione che produce risultati sbagliati, un conflitto tra componenti — il primo passo è attivare la modalità debug nel file wp-config.php. Bastano due righe:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true );
Il file wp-config si trova nella root in cui si è installato wordpress , per accedere alla gestione file ci sono due possibilità:
- accedere tramite FTP utilizzando un client come Filezilla
- accedere dal pannello di gestione Hosting
Per semplicità in questa guida verrà trattato il caso in cui si voglia accedere alla Gestione File tramite il pannello Hosting Cpanel
Per prima cosa bisogna quindi accedere a Cpanel e trovare la voce File Manager
Dopo aver cliccato su File Manager si avrà accesso a tutti i file del servizio hosting , è necessario recarsi nella cartella ove è installato WordPress, ovvero public_html
N.B. In caso il piano hosting utilizzasse il pannello Plesk, la cartella principale sarebbe httpdocs
N.B. 2 In caso ci fossero più installazioni WordPress è necessario recarsi nella carte in cui risiede il sito su cui si vuole attivare il debug
A questo punto sarà visibile il file che si dovrà modificare wp-config.php
Per aprire il file bisogna cliccare col tasto destro sul nome del file e quindi su Edit
Si troverà la direttiva impostata su “false” che bisognerà modificare:
define( 'WP_DEBUG', false );
e bisognerà modificarla come segue
define( 'WP_DEBUG', true );
e salvare le modifiche cliccando su Save Changes
è possibile inoltre gestire il debug inserendo le seguenti direttive non presenti di default:
define( 'WP_DEBUG_LOG', true );
così verranno salvati i log del debug nel file debug.log .
La prima istruisce WordPress a non nascondere gli errori. La seconda li scrive in un file —wp-content/debug.log — invece di mostrarli a schermo, il che è preferibile in quasi tutti i contesti perché non espone informazioni sensibili agli utenti e permette di analizzare i problemi con calma.
A quel punto si legge il log. Un errore PHP riporta il tipo — Fatal error, Warning, Notice — la descrizione e la riga di codice coinvolta. Da lì si risale: quale plugin sta caricando quel file, quale funzione viene chiamata in quel punto, se il problema è isolato o si ripete in condizioni diverse.
Per chi vuole più visibilità durante l’analisi, Query Monitor è lo strumento più utile disponibile: mostra in tempo reale le query al database, i hook eseguiti, i file caricati, i conflitti tra componenti. Rende visibile quello che normalmente resta nascosto nel flusso di esecuzione di WordPress.
Dopo aver applicato una correzione, la verifica segue tre passaggi. Si riproduce esattamente la situazione che causava il problema — non una simile, quella esatta. Si controlla che il log sia pulito. Si testano le funzionalità adiacenti, perché una modifica a un hook può avere effetti su componenti apparentemente non correlati: è quello che in gergo si chiama regressione. Su progetti strutturati o nello sviluppo di plugin propri, PHPUnit integrato con WP-CLI permette di automatizzare questa verifica con test che girano ad ogni modifica.
Il principio che governa tutto il processo è uno solo: un bug si considera risolto quando se ne capisce la causa, non quando smette di comparire. Una correzione fatta senza aver compreso il problema tende a ripresentarsi — spesso in forma diversa, quasi sempre nel momento meno opportuno.
Invece impostando questa direttiva su false
define( 'WP_DEBUG_DISPLAY', false );
quando il debug è attivo, errori e warning non saranno mostrati navigando il sito anche se presenti ma saranno comunque salvati nel file debug.log, impostazione molto utile quando vengono visionati warning non invalidanti di cui comunque si vuole tenere traccia.
