Analizzare un problema
In generale, bisogna sempre prima isolare un problema. L'ambiente non è controllato come un ambiente di laboratorio: possono coesistere più problemi contemporaneamente che rendono l'analisi più complessa. Quindi dobbiamo eseguire test ad ogni modifica che facciamo per vedere se il comportamento cambia. Ogni rilevazione di comportamento variato è un'informazione che ci avvicina a scoprire il problema, perchè possiamo intrecciare comportamenti e condizioni fino a risolvere il rompicapo.
Ma se non abbiamo alcun lead, alcuna informazione: una pagina bianca senza messaggi di errore, bisogna andare a tentativi. E andare a tentativi è time-consuming. Oltre che frustrante. Quindi dobbiamo trovare un modo per far "parlare" questo "paziente": farci dire dove gli fa male.
In altre parole, dobbiamo trovare e leggere i messaggi di errore che al 99% il sistema sta generando in file che di solito non leggiamo.
Come leggere i messaggi che descrivono i problemi
Per fortuna WordPress è basato su PHP. Tutto il sistema gira su un software chiamato Apache, che, attraverso il modulo PHP, interpreta e fa girare il codice di WordPress. Questi elementi, combinati insieme, sono in grado di mostrare messaggi di errore, quando presenti.
Di solito in WordPress la visualizzazione di questi messaggi è limitata, altrimenti nel sito web si vedrebbero tutti i messaggi di errore generati dai plugin e dai temi installati. Per curiosità, per vedere questi messaggi, basta abilitarne la visualizzazione scrivendo questa riga in functions.php
error_reporting(E_ALL);
Analizzare problemi in WordPress: la pratica più diffusa
Quando qualcosa non funziona in WordPress, una pratica molto diffusa è quella di disabilitare un plugin alla volta finchè non è chiaro il plugin che crea il problema. Ma questa tecnica, sarà capitato di appurarlo, non è sempre efficace, perchè a volte il problema non è legato ad un plugin in particolare, ma alla congiunzione di più plugin o temi.
Analizzare problemi in WordPress: la pratica consigliata da WordPress
WordPress offre un modo efficace per individuare un problema e capire esattamente cosa non va. Basta sostituire la riga che contiene define( 'WP_DEBUG', false ) nel file wp-config.php, con le seguenti righe:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
Definiamo, per l'appunto, che il WP_DEBUG è attivo (true) e lasciamo che gli eventuali messaggi di errore, finiscano nel file /wp-content/debug.log. Da questo file sarà quindi possibile leggere il vero messaggio di errore, quale plugin lo provoca e procedere di conseguenza. Questa tecnica ha comunque delle limitazioni in quanto non tutte le tipologie di messaggi andranno in quel file.
Per approfondire: https://wordpress.org/documentation/article/debugging-in-wordpress/
Una tecnica più avanzata per leggere i messaggi di errore
I più diffusi servizi di hosting, quando notano che uno script PHP (e quindi anche lo stesso WordPress) genera un messaggio di errore, creano un file nel quale vanno a scrivere tutto il messaggio. Il problema è che spesso questo file è creato esattamente nella cartella dove gira lo script PHP interessato. Quindi noi dovremo aprire periodicamente ogni cartella di WordPress e controllare se è stato creato un file di errore, che di solito si chiama php_errorlog o soltanto error_log (esistono altre variabili non prevedibili).
Una soluzione che ho individuato a questa scomodità, è stata quella di realizzare un plugin che va a cercare tutti gli eventuali file di log presenti nelle cartelle wp-admin, wp-includes, wp-contents e mostrarli in una comoda interfaccia nel /wp-admin. Da questo plugin è anche possibile abilitare la modalità debug senza modificare manualmente wp-config.php (come mostrato in alto).
Analizzato il problema, cosa fare?
A volte si tratta effettivamente di disabilitare o aggiornare un plugin, o cambiare un'impostazione nel pannello di un tema. Di solito questo è il momento in cui il problema è risolto.
Ma quando questo non risolve, è necessario conoscere in maniera approfondita la struttura di WordPress e le sue logiche. Entriamo quindi nell'ambito di intervento di un programmatore WordPress che ha acquisito la necessaria conoscenza del Codex e può quindi intervenire a livello di codice PHP, o di database.
E' sicuramente una rara condizione, perchè solitamente si risolve con le tecniche descritte sopra, ma nel caso in cui ti trovassi proprio qui, puoi contattarmi e cercheremo insieme di capire il problema per trovare una strategia risolutiva.
