Come fare il Debug WordPress

Vuoi sapere come eseguire il Debug per un sito web WordPress ? In questa guida definitiva abbiamo raccolto alcuni suggerimenti per effettuare correttamente il Debug WordPress.
Ci sono molte informazioni errate diffuse sul web e sui social media su “Come eseguire debug di WordPress”.
Questo finisce per causare molta confusione tra proprietari di siti e sviluppatori.
Spesso causa aspettative errate su come le cose dovrebbero funzionare.
Questo a sua volta rende più difficile trovare la vera causa di molti problemi.

Bene, siamo qui per aiutarti. In questa guida definitiva vedremo come fare un debug corretto per WordPress.
Speriamo di sfatare alcuni falsi miti e darvi nuovi strumenti per diagnosticare problemi e debuggare WordPress … nel modo giusto.

Come fare il debug WordPress

Prima di iniziare, risolviamo alcuni equivoci comuni che si riscontrano sul debug dei problemi di WordPress.

… Quando si ottiene una “schermata bianca ” nelle pagine di WordPress, PHP sta effettivamente registrando molte informazioni che possono aiutare a risolvere il problema. Sui forum di supporto tecnico di WordPress.org, GitHub o WordPress StackExchange, vedrai persone menzionare l’errore schermo bianco abbastanza spesso, di solito con un tono di intensa frustrazione. Ti mostreremo come utilizzare la modalità di debug integrata di WordPress per recuperare tali informazioni e utilizzarle per aiutarti a risolvere rapidamente il problema.

… Quando si attiva un plugin e si verifica un errore, non è sempre il plugin attivato più di recente ,  la vera causa del problema.
Uno dei consigli più comuni è disattivare tutti i plugin, quindi riattivarli uno ad uno.
Se attivando un plugin si verifica l’errore, è a causa di un difetto in quest’ultimo che il problema si manifesta.
Purtroppo questo è un cattivo consiglio, ma solo perché è un consiglio incompleto.
Questa particolare tecnica è utile per limitare i problemi. Ma non per risolverli alla radice.

Infatti se si verifica un errore dopo l’attivazione di un plugin specifico, non significa necessariamente che c’è un difetto in quel plugin. Potrebbe esserci, ma è necessario un ulteriore debug per determinare il problema esatto, perché in molti di questi casi il plugin non ha nulla a che fare con il problema.
A volte i problemi “sotto il cofano” di PHP non vengono rilevati e le cose sembreranno funzionare fino a quando non si verificherà un trigger specifico. Se c’è un problema di configurazione del sito o un conflitto, anche un plugin o un tema perfettamente codificato può essere il fattore scatenante.
Ma il vero problema potrebbe essere qualcos’altro.

… Quando si verifica un rallentamento significativo dopo l’attivazione di un plugin in WordPress, non significa necessariamente che il plugin sia codificato in modo errato o che causi il problema. (Anche se potrebbe essere vero). I rallentamenti dei siti WordPress sono spesso causati da errori PHP non diagnosticati, problemi di configurazione, problemi di memoria, problemi di database, moduli mancanti, vecchie versioni mySQL e vecchie versioni di PHP.
Ne parleremo un po ‘più avanti.

… Anche i bravi programmatori commettono errori: è solo una parte dell’essere umani. Ecco perché è essenziale essere molto, molto metodici nel debugging. Per quello che vale, riconoscendo il fattore di errore umano e rendendolo conto è ciò che trasforma i bravi programmatori in codificatori eccezionali! Ti consigliamo di creare un processo diagnostico molto approfondito per te stesso (o per il tuo team), con passaggi chiaramente definiti e seguendo tutte le fasi del processo ogni volta con precisione.
Non ignorare l’errore umano – succede – quindi tienilo a mente nel tuo processo.

A volte un particolare passaggio può sembrare non necessario, e si potrebbe essere tentato di saltarlo. Nella nostra esperienza, questo causa problemi perché quel passo potrebbe averti mostrato qualcosa che non hai visto prima. Inoltre, se si esegue il processo diagnostico allo stesso modo ogni volta, fornisce un’analisi più scientifica e accurata che è possibile confrontare con altri test precedenti. All’inizio questo può sembrare noioso, ma quando inizi a risolvere i problemi più velocemente, ti renderai conto che in realtà alla fine risparmierai un sacco di tempo perché non perderai tempo a rincorrere il sentiero sbagliato.

Molte volte un utente verrà da noi con un problema di supporto tecnico che ha trascorso ore a provare, ma con il nostro processo ci sarebbero voluti meno di 15 minuti (forse 30 per un novizio di WordPress). La ragione per cui questo accade è che la maggior parte delle informazioni sul debug di WordPress che troverai su Internet, non fornisce molti passaggi scientifici. La maggior parte è molto vaga e molto superficiale e lascia molto spazio a congetture. Non vi è alcun processo standard che venga seguito e gli utenti frustrati trascorrono spesso il tempo a inseguire il percorso sbagliato.

Il giusto approccio per il debug WordPress

Durante il debug di un sito Web WordPress, è molto importante entrare nel processo con una mente aperta. Proprio come un Crime Scene Investigator (CSI) – lascia che le prove siano la base per le tue conclusioni, non il contrario.

Diamo un’occhiata a questo da un’altra prospettiva. Quando esegui il debug di un sito Web WordPress, devi pensare come un meccanico. Quando porti la tua auto per ottenere una riparazione, ogni buon meccanico farà un’ispezione e una diagnosi approfondita.

Sarebbe impossibile diagnosticare con precisione un problema meccanico senza guardare sotto il cofano.
Molte persone fanno l’equivalente di questo con i siti WordPress. Ee eseguono solo il test di attivazione / disattivazione del plugin (o altri test sul lato client), e non guardano sotto il cofano di PHP per vedere quali errori stanno accadendo sul lato-server (usando WP_DEBUG e altri strumenti approfonditi), quindi è come cercare di diagnosticare problemi meccanici in un veicolo senza mai aprire il cofano. Sarebbe ridicolo … eppure molte persone fanno esattamente questo con WordPress!

Tieni presente che abbiamo supportato l’assistenza tecnica su migliaia di siti Web WordPress. Molte volte gli sviluppatori web vengono da noi per supporto, con forti presupposti e sono fiduciosi di sapere già qual è il problema. Questo è un problema.

In oltre il 90% dei casi, queste ipotesi sono sbagliate e il vero problema era qualcosa di completamente diverso. Il motivo per cui abbiamo una percentuale così alta di casi risolti di supporto tecnico (quasi il 100%) è che seguiamo un processo e non entriamo con la nostra mente rivolta a un potenziale “colpevole”. Certo, potremmo avere un’idea in testa, o una teoria, ma non ci lasciamo prendere troppo dall’argomento, e manteniamo una mente aperta. Sviluppando un processo diagnostico efficace, lasciamo che ci guidi alla soluzione. Questa è stata la chiave del nostro successo.

Ora non possiamo rivelare tutti i nostri segreti, ma siamo felici di condividerne alcuni con te. Fidati di noi … renderà il debug molto più semplice, molto meno dispendioso in termini di tempo e molto più proficuo.

Lo Schermo bianco …è spesso Misunderstood

La “schermata bianca ” (ovvero l’errore “WSOD”) è causata da qualche tipo di errore, sia in PHP che a livello di server (Apache / IIS / etc), ma poiché il server è configurato per non visualizzare errori (corretto dal punto di vista della sicurezza), non si vede l’errore – si vede solo uno schermo bianco.

Due esempi comuni sono gli errori irreversibili di PHP (generalmente correlati agli errori di codice PHP) e gli errori 500 interni del server (in genere correlati alla configurazione). Il tuo server dovrebbe essere configurato per registrare questi errori in una posizione sicura (al di fuori della web root), in modo che tu possa visualizzarli e vedere cosa sta succedendo.

WP_DEBUG È IL TUO AMICO …

WP_DEBUG è una modalità di debug incorporata in WordPress ed è uno strumento molto utile in caso di problemi tecnici. Ti dirà dove ci sono errori di codice e può aiutarti se hai conflitti di plugin. Se ottieni uno schermo bianco, è la prima cosa che dovresti fare. Dovrai accedere ai file sul tuo sito tramite un client SFTP (ad esempio FileZilla) o il pannello di controllo (ad esempio cPanel) sul tuo sito web e utilizzare il file manager.

Per utilizzare WP_DEBUG, effettua le seguenti operazioni:

Prima di tutto, esegui il backup del tuo file wp-config.php nella directory di WordPress, quindi aprilo in un editor di testo come Blocco note o Blocco note ++. (Qualunque cosa tu faccia, NON UTILIZZARE il software MICROSOFT per aprire questo o qualsiasi software di tipo “Elaboratore di testi”. Farà un disastro del tuo file e dei tuoi dati.)

Cerca la linea di codice :

define('WP_DEBUG', false);

e sostituiscila con:

/* WP_DEBUG - Turns WordPress debugging on/off */
define( 'WP_DEBUG', TRUE );
if( defined( 'WP_DEBUG' ) && TRUE === WP_DEBUG ) {
    /* Log everything to '/wp-content/debug.log' */
    define( 'WP_DEBUG_LOG', TRUE );
    /* Prevent errors from displaying on-screen */
    define( 'WP_DEBUG_DISPLAY', FALSE );
}
/* If WP_DEBUG disabled, settings fall back to php.ini config */
Quando hai terminato il debug, modifica questa riga:

define( 'WP_DEBUG', TRUE );

con

define( 'WP_DEBUG', FALSE );
La maggior parte degli utenti conosce solo la prima riga:

define( 'WP_DEBUG', TRUE );

Sfortunatamente, questa linea da sola accenderebbe la visualizzazione visibile degli errori sul tuo sito web. (A meno che non siano stati disabilitati nel file php.ini.) La visualizzazione degli errori visibili non è auspicabile per un sito , per una serie di motivi, tra cui la sicurezza e la facilità d’uso.
Anche la visualizzazione degli errori visibili non è particolarmente utile in un sito di test, poiché potrebbero mancare alcuni errori.

L’aggiunta delle righe successive scrive l’errore in un file di registro invece di visualizzarlo e ora rallenta il tuo sito, quindi è un modo molto semplice per usare WP_DEBUG.

Con il codice completo che ti abbiamo mostrato, puoi utilizzarlo nuovamente in futuro quando devi eseguire il debug del tuo sito.

Dopo aver attivato WP_DEBUG, devi provare a ricreare l’errore che avevi. Se hai disattivato dei plug-in, attivali (almeno temporaneamente) e ricrea l’errore. Assicurati che tutto sia configurato esattamente com’era quando hai avuto l’errore la prima volta. Ricorda: non assumere nulla Le informazioni verranno registrate in questa posizione (in relazione alla web root del tuo sito, come definito nelle impostazioni di WordPress):

/wp-content/debug.log

Lascia attivato WP_DEBUG abbastanza a lungo da eseguire una varietà di funzioni di codice, in modo che gli errori possano essere registrati. Il debug.log non viene scritto per impostazione predefinita. Verrà scritto da WordPress solo se ci sono errori. Spesso sono sufficienti 15-20 minuti, ma se non viene visualizzato nulla nel registro dopo un determinato periodo di tempo, è consigliabile lasciarlo abilitato per alcune ore.

Dopo aver ottenuto alcuni errori registrati in un file debug.log, esaminare il file di registro, cercando i percorsi dei file, i nomi dei file e le righe in cui si sono verificati gli errori. Questi ti diranno spesso dove si è verificato il problema del codice.

Se sei uno sviluppatore di plugin per WordPress o uno sviluppatore di temi, dovresti assolutamente utilizzare questa tecnica per testare i tuoi plugin prima di rilasciare ogni nuova versione! Onestamente è sorprendente la frequenza con cui scopriamo che gli sviluppatori di plugin non l’hanno fatto, e quindi consentono di evitare facilmente errori catchable.

Migliorare la memoria di WordPress

L’impostazione predefinita di memoria PHP di WordPress è 40 MB. Tuttavia, la maggior parte dei siti può avere problemi con meno di 64 MB. Qualsiasi tipo di sito robusto può raggiungere i 40 MB in pochissimo tempo. PHP cerca di aumentare il limite di memoria, se necessario, ma non sempre funziona come previsto, a seconda della versione di PHP e delle impostazioni di configurazione. Tieni presente che nelle versioni PHP più recenti, PHP svolge un ruolo migliore nella gestione della memoria e ha meno perdite di memoria. (Se vuoi davvero migliorare le prestazioni, esegui l’aggiornamento a PHP 7: è due volte più veloce di PHP 5.6.)

Per potenziare la memoria di WordPress, puoi aggiungere alcune righe al tuo file wp-config.php che ti aiuterà (e anche se non risolve questo problema, il tuo sito dovrebbe essere notevolmente più veloce). Come al solito, esegui il backup offline prima di apportare eventuali modifiche. Metti questo prima della riga che dice “Questo è tutto, smetti di editare!”:

/* Custom Memory Limit */
define( 'WP_MEMORY_LIMIT', '96M' );
/* Custom Memory Limit in Admin */
define( 'WP_MAX_MEMORY_LIMIT', '128M' );

Questo dovrebbe essere un ambiente perfetto per la maggior parte dei siti. La maggior parte degli host web ha un limite massimo di memoria PHP di almeno 256 MB (per istanza di script), quindi dovresti essere ancora al di sotto di questo. (Puoi testare questo con il plug-in RS System Diagnostic. Vedere la sezione successiva.) Se è necessario, è possibile sostituire ’96M’ e ‘128M’ con impostazioni più alte, ma nella maggior parte dei casi non è necessario. Non possiamo garantire che aiuterà ogni sito, ma nella maggior parte dei casi fa una differenza e un notevole aumento delle prestazioni. (Se sei su una configurazione di hosting abbastanza solida come VPS / Server Dedicato, questo può entrare in gioco solo nei momenti di intenso utilizzo.) La spinta non sarà vista tanto quando la memorizzazione nella cache della pagina è abilitata, ma sarà evidente durante l’elaborazione e le operazioni del database.

Tieni presente che questo limite di memoria è per istanza di script, non RAM totale.

Configurare correttamente l’ambiente di test

Questo è un settore in cui abbiamo visto molti sviluppatori Web avere alcuni problemi. Impostano un server di test locale o un sito di sviluppo / staging e apportano solo modifiche minime (se esistenti) alle impostazioni predefinite.

È assolutamente essenziale che l’ambiente di test sia configurato per corrispondere alle impostazioni del sito live.

Consideralo per un momento: quando imposti un ambiente di test, localmente sul tuo computer o su un server di sviluppo / di staging, se le impostazioni di configurazione non imitano esattamente le impostazioni del sito live, in che modo ciò è vantaggioso per il processo di sviluppo?
Tuttavia, lo vediamo spesso.
Gli sviluppatori creano una sorta di ambiente di test e quindi non garantiscono che la configurazione sia identica. Ciò causerà solo problemi e sprecherà tempo nel tentativo di eseguire il debug di problemi che non sono necessari.

Questo problema è più comune quando l’ambiente di test è impostato su un computer locale. Per impostazione predefinita, queste configurazioni non sono in genere configurate per corrispondere ai siti live. In quasi tutti i casi, richiede qualche ritocco. XAMPP è un solido pacchetto per iniziare e funziona su Windows, Mac e Linux. Assicurati di controllare (e ricontrollare) tutti i file di configurazione appropriati per il tuo sito: httpd.conf, php.ini, .htaccess, web.config, host, ecc. Puoi utilizzare il rapporto di visualizzazione avanzata nel nostro plug-in di diagnostica del sistema RS per raccogliere istantaneamente le informazioni di configurazione sia dell’ambiente locale che del server live, quindi confrontarle per vedere ciò che non corrisponde.

Assicurati di configurare il file degli host locali in modo da poter accedere al sito tramite il suo effettivo dominio web in un browser, anziché l’indirizzo IP locale. Se non si è certi che è possibile ottenere la configurazione locale per abbinare il sito live, quindi una soluzione migliore è quella di impostare un sito di staging sullo stesso host web del sito live, in quanto ciò consentirà di lavorare con molto più preciso impostazioni di configurazione. Per questo motivo consigliamo di utilizzare un sito di staging (ovvero “server di sviluppo”) su ambienti di sviluppo locale.

In tale nota, assicurarsi che sia il sito live sia l’ambiente di testing utilizzino numeri di porta standard: la porta 443 per il traffico HTTPS (sicuro) e la porta 80 per il traffico HTTP (non protetto). WordPress è codificato per utilizzare solo le porte 80 e 443 e l’uso di qualsiasi altra cosa garantirà problemi. L’uso di porte non standard per un sito Web rientra nella stessa categoria di rolling-your-own-crypto: non farlo. Inoltre, è prassi comune utilizzare software anti-malware e firewall per limitare il traffico Web alle porte 80 e 443. L’uso di porte non standard potrebbe rendere il tuo sito inaccessibile.

Tieni presente che se utilizzi un ambiente di test con impostazioni di configurazione errate e hai problemi con il tuo sito WordPress, non è colpa di un plugin o sviluppatore di temi. Il codice base, i plugin e i temi di WordPress dipendono da un sito configurato correttamente, in base agli standard e alle best practice. Una volta che hai risolto la configurazione, le cose funzioneranno bene.

Plugin WordPress che possono aiutarti con il debug

Plugin Query Monitor – Questo è un eccellente plugin che ti aiuta a eseguire il debug del tuo sito fornendo informazioni dettagliate sulle query del database, quali plugin utilizzano quali funzioni, memoria utilizzata e altro. Questo può essere utile per determinare quali plugin possono rallentare il tuo sito.

Plugin RS System Diagnostic – Questo plugin, semplifica la raccolta di tutti i tipi di dati tecnici sul tuo sito in pochi secondi, senza doverli cercare. Queste informazioni possono essere scaricate come file di testo (.txt), inviate via e-mail direttamente dal plugin o visualizzate in remoto con un URL temporaneo univoco. Fornisce anche avvertimenti per problemi comuni. Se si risolvono i problemi segnalati dagli avvertimenti, possono essere d’aiuto nel processo di debug e aiutano a migliorare la protezione e le prestazioni.

In conclusione

In questo articolo abbiamo visto l’importanza di configurare correttamente il debug di WordPress. Configurare nel modo giusto il debug ti aiuterà nel caso riscontri dei problemi sul tuo sito WordPress.