Wordpress fornisce dei semplici ma fondamentali snippet per la gestione degli errori. Grazie a queste poche righe di codice potremo tenere sotto controllo tutto quello che succede sul nostro server, senza necessariamente mandare in output agli occhi dell'utente gli errori.
Una semplice modifica al file di configurazione wp-config.php ci consente di disporre dei log di tutti gli errori e i warning generati dal nostro Wordpress. Questa opportunità, unita al fatto di poter decidere se visualizzare o meno gli errori in output, cosa da evitare sui siti di produzione, faciliterà il nostro lavoro e il monitoraggio del blog.
Apriamo il file wp-config.php e cerchiamo la riga
define('WP_DEBUG', false);
Sostituiamola con queste istruzioni:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);
@ini_set('display_errors',1);
define('SCRIPT_DEBUG', true);
La prima istruzione abilita il debug. La seconda ci consente di salvare gli errori su un file, precisamente debug.log dentro la cartella "wp-content" (creiamolo pure e settiamo i giusti permessi di scrittura). Le due righe successive si occupano di mostrare a video l'output degli errori, cosa da evitare su siti in produzione ma molto comoda in fase di sviluppo, cosi dovremo evitare di aprire ogni volta il file di log.
Infine l'ultima istruzione attiva il debug sugli script.
Proviamo ora a generare un errore (la versione base di wordpress non ne contiene), andando ad esempio a scrivere sul file index.php del template un'istruzione che cerca di contare gli elementi di una variabile mai settata prima:
<?php
echo count($variabile_di_prova);
?>
(scrivete questa istruzione in un punto qualsiasi del file index.php dopo l'apertura del div main-content). Lanciate da browser il sito e vedete che il waring è visibile sia sulla home page:
<b>Notice</b>: Undefined variable: artista in <b>/var/www/wordpress/wp-content/themes/twentyfourteen/index.php</b> on line <b>23</b><br />
sia nel file debug.log. Ovviamente impostando il debug_display a false e la variabile display_errors a 0, soppriamo gli errori sul browser ma li teniamo nel log.
Non finisce qui: wordpress consente di registrare anche le query, anche se l'output è delegato al nostro codice. Aggiungiamo nel file di configurazione visto prima questa istruzione
define('SAVEQUERIES', true);
e mettiamo, ad esempio alla fine del file index.php del nostro template, dopo get_footer();, questo codice
echo '<div style="background:gold;clear:both;"><pre>';
print_r($wpdb->queries);
echo '</pre></div>';
Ok dopo get_footer() in teoria non andrebbe inviato nulla al browser, ma in questa fase di illustrazione va bene cosi. Lanciando l'home del nostro template possiamo vedere a fine pagina un prezioso array contenente, per ciascuna query, tre informazioni:
- l'istruzione sql
- il tempo di esecuzione
- la funzione che ha richiamato la query, comprensiva di tutte le chiamate dalle funzioni precedenti fino ad arrivare a require('wp-blog-header.php') che ha inizializzato il blog
Un debug davvero completo.
Esiste poi un debug estremo, che possiamo ottenere aggiungendo al file functions.php del nostro template questa istruzione:
add_action( 'all', create_function( '', 'echo "analisi in corso...\n".var_dump( current_filter() );' ));
ma come potete vedere lanciando una qualsiasi pagina del nostro blog, si tratta di un debug talmente approfondito che trova utilità solo in casi estremi. Interessante notare quante funzioni vengono chiamate da una pagina: dopo aver visto questo debug in azione, difficilmente potremo dire che "wordpress è soltanto un blog" :)