Realizzazione Siti e Portali Web – Wordpress CODING – Mobile APP – Consulenze SEO – Web design – Ecommerce     Login / Register

Il debug di WordPress

A chi non è mai capitato che dopo l’installazione di un plugin o un aggiornamento ad una versione successiva di WordPress il sito smetta di funzionare? dalla “Pagina bianca della morte” al malfunzionamento di un bottone che non fa più quello che faceva prima, attraverso una vasta gamma di errori più o meno gravi,  piuttosto frequente la necessità di “debuggare” il codice alla ricerca dell’errore o del malfunzionamento.

In questo approfondimento cerchiamo di fornire tutti gli strumenti per il debug di un sito WordPress.

Indice dei paragrafi:


Usare al meglio il file wp-config.php per il debug di wordpress

Il primo step da mettere in atto per procedere all’individuazione degli errori è quello di attivare la modalità debug tramite la modifica della costante WP_DEBUG a true (il valore di default di un’installazione vergine è false )nel file wp-config.php. Il file wp-config.php è il file principale che contiene le configurazioni necessarie e definisce delle variabili ambientali valide in tutta l’installazione

abilitare debug nel file config.php di wordpress

In questo modo abbiamo attivato il debug che, come azione di default, stampa a video tutte le eccezioni ( errori, warning e notices )  che vengono generate dal server durante le esecuzioni di script php.
Il discorso sulla gestione degli errori del php è piuttosto ampio e intricato, coinvolge le direttive php.ini  che molto spesso, in hosting condivisi non sono gestibili dall’utente, il quale non ne può modificare i valori di default, quindi, nel 95% dei casi attivare il debug significa visualizzare a video tutte le eccezioni sollevate. Va detto che i “notices” non rappresentano criticità particolari, spesso sono riferiti a variabili non dichiarate ( undefined variable ) o funzioni deprecate, i “warning” hanno un livello di severità superiore interrompono i cicli for e foreach ma non sono errori “fatali” e consentono quindi la continuazione dell’esecuzione dello script anche se vanno indagati e risolti. Anche gli errori MySQL non sono di per se bloccanti ma evidentemente una query sbagliata determina ( nel migliore dei casi ) un malfunzionamento o un infinite loop. I “fatal error” ( ad esempio chiamare una funzione inesistente o duplicare il nome di una funzione, errori di sintassi, etc ) sono i primi che vanno individuati e sistemati per far tornare il sito in funzione.

Ok il display a video degli errori ci consente una prima sommaria strada per il debug ma se il sito (o almeno ciò che di esso continua a funzionare) è in produzione, anche gli utenti vedranno il debug, (anche Googleebot, passando sfortunatamente proprio in quel frattempo..) e ciò non è particolarmente bello. Ma soprattutto, il display a video degli errori è esso stesso causa di altri errori: probabili errori javascript nelle pagine che ne fanno uso e certamente errori nell’output di file di tipo JSON in chiamate ajax, che sono molto frequenti soprattutto in back-end.
Il display a video degli errori è quindi da utilizzare per un “quick recovery” ovvero l’individuazione immediata del file che genera l’errore e la sua correzione rapida laddove possibile o la disattivazione del plugin o del tema se di esso si tratta.
Se invece è necessario indagare più approfonditamente è possibile raffinare la modalità di debug:

Con queste direttive nel file config.php il debug è attivo ma non viene mostrato a video e viene invece tracciato in un file di log ‘DEBUG.LOG’ che viene creato automaticamente nella cartella wp-content per essere esaminato con più calma.

Problemi di sicurezza correlati ai file di log

Attenzione: la creazione di file di log che persistono sul server sono pericolosi per la sicurezza di un sito WP in quanto si tratta di risorse raggiungibili dall’esterno via http che forniscono molte informazioni ; per ovviare  a questo problema si possono bloccare il file con una direttiva di questo tipo nel file .htaccess: (da testare con attenzione)

Un’altra direttiva che si può settare nel file config.php riguarda le query al DB. Aggiungendo la riga:

tutte le query effettuate dal daemon MySql sul db durante l’esecuzione degli script della pagina vengono salvate in un array che è quindi disponibile per essere visualizzato o salvato in un file di log (nell’esempio troveremo il file SQL.LOG nella dir. wp-content)

Va tenuto conto di quanto queste istruzioni siano impattanti sulle performance al caricamento delle pagine, pertanto vanno usate solo in fase di sviluppo e mai in siti in produzione.

top

Il debug del Javascript in wordpress

In realtà il debug di blocchi javascript prescinde dal fatto che stiamo parlando di wordpress oppure no, l’unica strada percorribile è quella dell’utilizzo delle console dei browser per individuare gli errori.
In genere il sintomo di presenza di errori javascript nelle pagine si evidenzia con malfunzionamenti degli input dei form ( bottoni, campi autocomplete etc ) e nelle funzioni di drag&drop o simili che riguardano oggetti del DOM, mentre la pagina nel complesso appare completa perchè non ci sono errori PHP che interrompono l’esecuzione.
L’unica agevolazione che WP ci mette a disposizione è l’utilizzo della direttiva:

nel file wp-config.php, in questo modo vengono caricate le versioni non-minified e non concatenate degli script e dei css per rendere più agevole l’individuazione degli errori, essa riguarda solo i file del core.
Dopo aver provato ad aprire la pagina con un browser diverso per verificare che si tratti di un errore di script e non del browser, ci viene in aiuto uno strumento nativo di Google Chrome (ma anche tutti gli altri hanno analoghe funzionalità): il “developer tools” o “strumenti per gli sviluppatori”, accessibile dal menù principale di Chrome->altri strumenti o con la scorciatoia CTRL+SHIFT+I

debug javascript dalla console di Chromeanche in questo caso gli errori JS sono di tipo warning ( giallo ) e error ( rosso ), nell’esempio abbiamo due risorse not found che di per se non rappresentano un problema ma vanno comunque risolte, in altri casi si evidenzieranno altri tipi di errore.
top

Il debug ‘passo-passo’ del php con Visual Studio 2015

Sebbene non molto in uso nelle community degli sviluppatori PHP Visual Studio 2015 rappresenta uno strumento formidabile e praticamente indispensabile per la realizzazione e il debug di applicazioni complesse. Tutti sanno che VS nasce nell’ambito dei progetti Microsoft ed è lo strumento principe per la realizzazioni di applicazioni .NET ma  grazie ad un’estensione a pagamento (PHP Tools for Visual Studio ) sviluppato da DevSense è possibile utilizzare Visual studio 2015 per il debug del PHP PHP debugger per visual studio 2015

Naturalmente non è possibile condensare in poche righe l’argomento ma proviamo comunque a dare alcune dritte di base.
I presupposti di base sono un ambiente WAMP installato in locale, VS 2015 con l’estensione PHP Tools for Visual Studio e l’estensione Xdebug helper di Chrome (https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc). L’abilitazione del debug va gestita nel file php.ini dell’installazione WAMP (individuabile in un percorso simile a c:\wamp\bin\apache\apache2.4.18\bin\php.ini)


Dopo avere creato il progetto locale sarà possibile avviare il debug del vostro progetto php ( in cui esiste l’installazione Wordprss su cui state lavorando) come per qualsiasi altro tipo di progetto gestito da Visual studio. Importante avere i servizi wamp attivi ( luce verde nell’icona di sistema.

A questo punto si aprirà una finestra del browser selezionato per il debug sulla homepage della vostra applicazione. Il settaggio dei virtual host del server apache si trova nel file: \bin\apache\apache2.4.18\conf\extra\httpd-vhosts.conf della cartella di installazione WAMP e avrà una sintassi simile a questa:

Per completare le operazioni preliminari al debug occorre attivare Xdebug helper con l’icona in alto a dx in chromee finalmente utilizzare il passo-passo impostando dei punti di interruzione nel codice cliccando nella colonna più a sinistra della view di VS 2015 relativa al file che si vuole debuggare; durante la lettura dello script, giunta in quel punto l’esecuzione si interrompe consentendoci di procedere step by step alle righe di codice successive mediante il tasto F10 abilitare breakpoint debug PHP VS 2015In questo modo è possibile conoscere in ogni momento il valore che assumono le variabili, verificare il corretto passaggio dalle funzioni, individuare ridondanze, etc… e l’utilizzo di VS 2015 con il debug passo-passo è molto spesso l’unico modo per individuare errori di logica nella programmazione ed eseguire un debug approfondito del PHP e di Wordpress  specialmente in applicazioni complesse.
top

Plugin utili per il debug di wordpress

Concludiamo con una lista di plugin utili per il debug di WordPress che alla radice utilizzano molti dei metodi descritti in questa guida per l’output degli errori e delle query:

 

Related posts

Leave a Comment

Lascia un commento

Your email address will not be published.




Top