Blog

Debug, che passione! La rimozione di errori e warning da un sito è una delle attività  più importanti per assicurarsi che il servizio funzioni nel migliore dei modi, andrebbe effettuata periodicamente e gli errori anche non bloccanti non dovrebbero mai essere sottovalutati.

Vedere gli errori prodotti da un sito in fase di manutenzione, in seguito all’aggiornamento di un plugin o in fase di debug è a volte complicato, purtroppo, dal fatto che la modalità  debug è disabilitata sui siti in produzione, quasi sempre di default: per aggirare il problema, è quindi necessario agire di conseguenza, come indicato di seguito.

Se agite su un sito in cui è comparsa la famigerata schermata bianca, oppure un errore indefinito o non facilmente identificabile, bisogna agire di conseguenza – e considerare un po’ di possibilità  che potrebbero averlo causato. In generale un errore di un sito può essere di tre tipi diversi:

1. errore a livello javascript, che si può identificare e correggere mediante modalità  sviluppatore del browser;
2. errore a livello server, che si identifica dai log del sito e ci si lavora quasi sempre via SSH;
3. errore a livello codice o plugin, sul quale possiamo lavorare via FTP oppure, ancora, via SSH ed in certi casi direttamente dal backend.

Cosa sono gli errori di un sito

Errore è un termine del tutto generico, che può fare riferimento, come abbiamo visto, a tre diversi gradi di problematiche, per nulla gravi, relativamente gravi e problematici per il sito. Non solo: gli errori su un sito possono anche essere determinati a livelli differenti (come abbiamo visto questo vale in due modi: livello di gravità  dell’errore e livello di “localizzazione” dell’errore), ad esempio lato javascript (per cui abbiamo errori del sito lato client, visibili mediante la console.log del nostro browser), oppure possono essere determinati da bug nel codice PHP del sito, all’interno di theme, plugin e personalizzazioni di ogni genere (errori lato server, in questo caso).

Chiarito questo, ovviamente dovremo intervenire per correggere il bug all’interno della sezione segnalata, di cui normalmente il debugger di PHP ci potrà  fornire le “coordinate esatte” per risolvere:

• nome del file che presenta il problema;
• numero di riga in cui il problema compare.

A dirla tutta, il fatto che un errore venga segnalato ad una certa riga non è detto che sia quello il punto esatto in cui intervenire; esiste una sorta di “catena” di errori, infatti, che vengono segnalati di fila dal debugger, che potete trovare nel file log degli errori del sito e che, alla prova dei fatti, possono essere anche determinati da dipendenze software del progetto (ad esempio un errore nella chiamata ad una libreria esterna, un problema nella import, un file mancante o corrotto e così via).

Come si risolvono gli errori di un sito

Sebbene sia una pratica che si impara con lo studio e l’esperienza, in genere bisogna sempre:

1. identificare l’errore;
2. verificare se ci sia un codice di errore specifico o una notifica specifica;
3. provare a capire se è un warning (trascurabile) o un errore bloccante;
4. identificare dove mettere le mani (SSH, FTP, backend del sito);
5. provare ad isolare l’errore (ad esempio disabilitando il plugin problematico oppure sostituendo il theme che lo sta causando).

Questi criteri sono del tutto generali, e si applicano in modo flessibile ai diversi casi possibili nella pratica.

Fare debug in WordPress

Andremo ora a vedere nel dettaglio come si attiva la modalità  di debug integrata di WordPress, come si usa e a cosa servono i vari parametri settabili, sia da codice che via plugin. Prima di arrivarci, pero’, è necessario introdurre l’argomento da un punto di vista più generale, per capire al meglio un po’ di cose importanti.

Livelli di errore: notice, warning ed error

In informatica il debug è la fase di tracciamento, verifica, riscrittura del codice, settaggio delle impostazioni in funzione della risoluzione degli errori di un software, ed in questo i siti web non fanno eccezione. La fase di debug di un sito andrebbe affidata, nella maggiorparte dei casi, a personale tecnico qualificato, al fine di evitare di provocare più problemi di quanti non se ne possano risolvere da soli. Premesso questo, anzitutto, bisogna distinguere tra tre livelli di errore, che sono di diversa “gradazione” in termini di gravità  e sono i seguenti:

1. livello notice o info, che rappresenta una semplice notifica informativa, che il più delle volte non è nemmeno un errore;
2. livello warning, che rappresenta un errore di entità  minore, che non impedisce alla pagina web di funzionare e non è, in sostanza, bloccante o ostativo;
3. livello error, l’errore vero e proprio in sostanza, ovvero un problema determinato da un bug di natura importante, che può generare un codice HTTP di errore oppure, in ogni caso, un problema ostativo o bloccante la pagina web.

Modalità  debug: mostrare gli errori di WordPress in modo esplicito

WordPress fornisce una modalità  di debug integrata, molto potente ed utile per risolvere, da sola, il 90% dei problemi che vi potranno capitare sul vostro sito web. WordPress è scritto interamente in PHP con supporto a database (generalmente) MySQL, e ad oggi supporta le versioni più recenti del linguaggio, per una questione di compatibilità .

Per risolvere e visualizzare gli errori di un sito WordPress, di solito, la prassi vuole che si vada all’interno del wp-config.php e si abilita il tracciamento degli errori per vedere, per l’appunto, che problema c’è. La costante da utilizzare è la seguente, ovvero:

define( 'WP_DEBUG', true );

WP_DEBUG che serve appunto ad abilitare la modalità  debug lato server. Questa modalità  mostra qualsiasi errore che si verifichi sia lato backend (ovvero amministrativo o interno) che frontend (quello che si vede nel sito pubblico), e ciò può avvenire con modalità  differenti:

1. una scritta spuria con un messaggio di warning, non bloccante;
2. una scritta con un messaggio di errore (error), bloccante;
3. un messaggio di sistema di WordPress in un’apposita finestra;
4. un errore lato server (500, ad esempio)

Bisogna chiarire fin da subito che WP_DEBUG traccia gli errori lato server, quindi commessi in linguaggio PHP, mostrando la natura dell’errore con una notifica scritta in inglese. Traccia non vuol dire pero’ che salvi quegli errori: se volessimo abilitare un log, ovvero un file “registro” dei vari errori, dovremmo abilitare la costante WP_DEBUG_LOG, sempre a true e sempre nel file wp-config.php del sito:

define( ‘WP_DEBUG_LOG’, true );

Gli errori verranno automaticamente salvati nel file:

wp-content/debug.log

che poi potrete consultare comodamente scaricandolo da browser o da FTP come file di testo. Ovviamente è opportuno non lasciare per sempre attiva la modalità  WP_DEBUG_LOG, perchè il file potrebbe crescere considerevolmente ed occupare spazio su disco dell’hosting.

Possiamo anche combinare tra loro i comandi, ad esempio:

define( ‘WP_DEBUG’, true );

define( ‘WP_DEBUG_LOG’, false );

serve a vedere gli errori senza loggare, mentre

define( ‘WP_DEBUG’, false );

define( ‘WP_DEBUG_LOG’, true );

al contrario, logga gli errori senza mostrarli in pubblico, e ancora:

define( ‘WP_DEBUG’, false );

define( ‘WP_DEBUG_LOG’, false );

è la modalità  di produzione di default, che non mostra nulla degli errori del sito. Con le ultime versioni di WordPress, poi, la gestione degli errori è cambiata, e per disabilitare la gestione di sistema può essere utile impostare temporaneamente la seguente costante (WP_DISABLE_FATAL_ERROR_HANDLER):

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

Come mostrare tutti gli errori di un sito lato Javascript in modo esplicito

Per fare lo stesso per gli errori lato JS, potete invece inserire la riga (sempre nel file wp-config.php):

define( 'SCRIPT_DEBUG', true );

Abilitate, salvate il file e provate ad aggiornare la pagina per vedere chiaramente, si spera, di chi errore si tratta. Se ottenete un errore lato server tipo un errore 500, invece, è una notifica generica, che richiederà  quasi sempre un’analisi dei file di log del sito, e che vedremo tra un attimo come effettuare.

Plugin per il debug in WordPress

Per abilitare al volo la modalità  debug senza dover editare alcun file, è comodo prendere in considerazione il plugin gratuito:

WP Debugging

che fa esattamente quello che abbiamo visto in modo automatico. Si scarica, si abilita sul sito in WordPress e poi basta andare dal backend su Strumenti e poi su WP Debugging, per trovare una schermata in cui poter impostare le varie opzioni come preferiamo. Le opzioni sono disponibili per WP_DEBUG, WP_DEBUG_DISPLAY e WP_DISABLE_FATAL_ERROR_HANDLER che è la notifica che “copre” spesso gli errori mostrando un errore generico, nelle ultime versioni di WordPress.

Come mostrare tutti gli errori di un sito PHP in modo esplicito

Se l’abilitazione delle costanti e del plugin viste in precedenza non funziona o non cambia nulla, potete anche abilitare gli errori PHP forzando, ad esempio all’interno del file index.php, la visualizzazione degli errori esplicita, questa volta lato linguaggio PHP:

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

è una piccola forzatura che fa una cosa molto importante, ovvero mostrare gli errori bloccanti e non bloccanti, ed imporre a PHP di scrivere gli errori nel file di log del sito.

Vedere solo gli errori gravi PHP

display_errors = on ;da mettere nel file PHP.ini

in alternativa potete sfruttare la direttiva PHP seguente

error_reporting(0);

Abilitare gli errori via htaccess

php_flag display_startup_errors on
php_flag display_errors on

Vedere solo le notifiche ed i warning

error_reporting(E_WARNING | E_NOTICE);

Che cos’è l’error log

error_log è un file di testo che, nel caso di WordPress, è presente all’interno della cartella wp-content, e che viene creato automaticamente abilitato la modalità  debug che abbiamo visto sopra.

Dove si trova il file php.ini

In alcuni casi il debug può essere particolarmente complesso per varie ragioni: ad esempio si deve poter mettere mano al file PHP.ini per cambiare impostazioni o abilitare un modulo PHP specifico. In questi casi, suggerisco, se si può accedere da cPanel o Plesk al sito andate a cercare le opzioni che sono presenti all’interno dello stesso: i moduli, ad esempio, si potranno abilitare da un’apposita sezione semplicemente selezionandoli e salvando le impostazioni.

Se invece avete accesso ad un sito con SSH, potete cercare il file php.ini usato dalla versione di PHP corrente cosà¬:

php -v

per vedere la versione di PHP usata (ad esempio la 7.4).

php --ini

per sapere dove si trova il PHP.ini che sta usando PHP; attenzione che, in alcune configurazioni di Apache o Nginx, il php.ini usato da PHP non è detto coincida con quello usato dal server, che è quello che ci interessa. Per essere sicuri, entrate nella root del sito, create il file info.php e incollate questo codice:

<?php phpinfo();?>

salvate e adesso aprite il file info.php da browser: dovreste vedere una tabella di informazioni varie tra cui, nello specifico, alla riga Loaded configuration file troverete il path che vi interessa.

Esempio:

Sui principali server troverete il file che vi interessa in queste posizioni:

• /etc/php/7.X/apache2/php.ini (su VPS basate su Ubuntu e Debian)
• /etc/php.ini (RedHat, CentOS)

Per abilitare e vedere gli errori PHP, dovrete inserire la seguente direttiva nel file PHP.ini:

display_errors = On

e poi salvare il file e riavviare il server per vedere le modifiche.

Dove si trovano i log di errore del server Apache/Nginx

I log di errore del server sono molto utili da spulciare, e ci sono due modi per vederli: il primo è quello di consultare la sezione apposta del vostro cPanel o Plesk, il secondo è quello di editarli e visionarli con il comando pico da SSH su questi path classici:

Apache: /var/log/apache2/error.log
Nginx: /var/log/nginx/error.log

Questi log sono normalmente disabilitati o nascosti all’utente, o ancora possono vederli solo i super-admin (sugli hosting condivisi, per intenderci, non riuscirete a vederli, ma il vostro hosting potrebbe in teoria farlo). Gli errori a livello di server esprimono la condizione generale lato server per cui l’errore è stato generato, e possono essere utili da visionare in caso di errori particolarmente ostici o complessi.

Dove si trovano i log di errore PHP

Anche qui, dipende dalla configurazione: per WP dovreste trovare tutto dentro: /wp-content/error_log

diversamente, i log di errore PHP saranno dentro al file: wp-content/debug.log

Debug lato javascript: modalità  sviluppatore

Per la risoluzione degli errori lato client, che spesso influenzano i segnali web essenziali, può essere utile effettuare il debug lato javascript mediante la console del proprio browser (modalità  sviluppatore). Attivare la console di un browser (disponibile sia per Chrome che per Firefox) permette di sviluppare e debuggare lato web in maniera molto più pratica, e senza essere costretti a visualizzare gli errori manualmente via Javascript (premendo contemporaneamente CTRL e J).

La funzione console.log

Quando si sviluppa codice in JS, in effetti, l’uso che possiamo fare della funzione:

console.log

permette di fare diverse cose, tra cui:

1. visualizzare l’andamento del codice in punti critici;
2. effettuare un debug rapido;
3. visualizzare eventuali warning o errori nel codice.

Modalità  sviluppatore: come si accede?

Premendo contemporaneamente CTRL e J, tenendo il browser aperto.

Modalità  sviluppatore: che cos’è?

Si tratta di una delle caratteristiche più importanti di Firebug (oggi si chiama Modalità  sviluppatore ed è presente su qualsiasi browser come Chrome o Firefox), presente per la verità  anche in altri componenti aggiuntivi, e che permette di tenere sotto controllo l’esecuzione di istruzioni a tempo di run.

Ad esempio, usando jQuery:

$( '#unBottone' ).click ( function () {
console.log ( 'hai cliccato unBottone!' );
// fai quello che devi...
} );

sarà  possibile loggare l’evento di click su #unBottone non appena quest’ultimo avvenga, in basso alla pagina in modo da tenere tutto sotto osservazione.

Di seguito un esempio tratto da un’app che sto migliorando in questi giorni (clicca per ingrandire):

àˆ inoltre possibile checkare se la console sia disponibile o meno, in modo da passare agevolmente dalla fase di produzione a quella finale di rilascio:

if ( window.console && window.console.log ) {
// [...]
}

Oltre al succitato tool, per fare debugging del codice si possono usare una delle seguenti alternative:

1. https://developer.chrome.com/devtools/index (per Chrome)
2. https://developer.apple.com/technologies/safari/developer-tools.html (per Safari)
3. http://msdn.microsoft.com/en-us/library/ie/gg589507(v=vs.85).aspx
4. http://msdn.microsoft.com/en-us/library/dd565628(v=vs.85).aspx (entrambi per IE)
5. http://www.opera.com/dragonfly/ (per Opera)
6. http://developer.apple.com/library/ios/ipad/#DOCUMENTATION/AppleApplications/Reference/SafariWebContent/DebuggingSafarioniPhoneContent/DebuggingSafarioniPhoneContent.html (per Apple mobile, iOS / iPhone)

Si possono inoltre sfruttare funzioni differenti che siano ben distinguibili a seconda dello stato, ad esempio:

console.log( var, "Log ordinario...");
console.info( var, "Informazioni: ...");
console.warn( var, "warning...");
console.debug( var, "Debug...");
console.error( var, "errore...");

Foto di copertina di Nemo (Pixabay)

👇 Contenuti da non perdere 👇

• Domini Internet 🌍
• Internet 💻
• Lavoro 🔧
• monitoraggio servizi online 📈
• Reti 💻
• Scrivere 🖋
• Sicurezza & Privacy 👁
• Spiegoni artificiali 🎓
• 💬 Il nostro canale Telegram: iscriviti
• 🔴 Come gestire il modello di business della tua idea sul web
• 🟠 Algoritmi di ricerca ed ordinamento: una panoramica generale in Python
• 🔴 Quanto si paga per effettuare un cambiamento del registrar di un dominio

Numero di visualizzazioni (dal 21 agosto 2024): 9

Pubblicità - Continua a leggere sotto :-)

Seguici su Telegram: @trovalost