Che cos’è l’errore critico di WordPress
L’errore critico di WordPress compare quando il CMS incontra un problema che impedisce a PHP di completare correttamente l’esecuzione del codice necessario a generare una pagina.
Il messaggio visualizzato può essere simile a questo:
Si è verificato un errore critico sul tuo sito web.
In alcune versioni o configurazioni può essere presente anche l’invito a controllare la casella email dell’amministratore del sito.
Il messaggio, da solo, non indica quale componente abbia provocato il problema, serve soprattutto a evitare che sullo schermo vengano mostrati dettagli tecnici dell’errore PHP, come percorsi dei file, nomi delle funzioni o altre informazioni che non dovrebbero essere esposte pubblicamente.
Nella maggior parte dei casi il sito non è stato cancellato e il database non è necessariamente danneggiato, significa semplicemente che WordPress non riesce a completare una determinata operazione.
Perché WordPress mostra un errore critico?
WordPress è composto dal core del CMS, dal tema e dai plugin installati: tutti questi componenti contengono codice PHP che viene eseguito sul server.
Se durante questa esecuzione si verifica un errore PHP non recuperabile, WordPress può interrompere il caricamento e mostrare il messaggio di errore critico.
Le cause possibili sono diverse. Tra quelle indicate anche nella documentazione ufficiale di WordPress rientrano conflitti o problemi nei plugin, incompatibilità del tema, versioni PHP non compatibili, esaurimento della memoria disponibile e file del core danneggiati.
Un caso tipico si verifica dopo un aggiornamento. Si aggiorna WordPress, un plugin oppure il tema e una parte del codice non risulta più compatibile con il resto dell’installazione. Per questo gli aggiornamenti di WordPress dovrebbero essere eseguiti disponendo sempre di un backup recente.
Prima di modificare il sito: fare un backup
Prima di iniziare la ricerca dell’errore conviene creare una copia dei file e del database, quando l’hosting permette ancora di farlo.
Il backup è importante anche quando il sito è già in errore. Permette infatti di conservare lo stato corrente prima di rinominare directory, sostituire file o modificare la configurazione.
Non è consigliabile invece cancellare subito plugin, temi o directory del core senza aver prima identificato il problema. Un errore critico va trattato come qualsiasi guasto informatico: prima si raccolgono informazioni, poi si interviene.
Controllare l’email dell’amministratore
Quando WordPress intercetta determinati errori fatali può attivare la modalità di recupero e inviare un’email all’indirizzo dell’amministratore.
Se il messaggio arriva, al suo interno sono indicate informazioni utili all’individuazione del componente interessato dall’errore e un link di accesso al backup in modalità di recupero.
Se l’email non arriva, non significa che non esista un errore PHP. Il messaggio potrebbe non essere stato generato, potrebbe essere finito nello spam oppure potrebbero esserci problemi nella consegna della posta del sito.
In questo caso si procede direttamente con l’analisi dei log.
Controllare il log degli errori
Il metodo più affidabile per capire cosa abbia provocato l’errore critico consiste nel leggere il log degli errori PHP disponibile sul server.
Il log può contenere una riga simile alla seguente:
PHP Fatal error: Uncaught Error: Call to undefined function esempio() in /wp-content/plugins/plugin-esempio/file.php on line 125
Questo esempio è volutamente generico. La parte importante è il percorso del file. Se compare una directory all’interno di wp-content/plugins/, si può risalire al plugin coinvolto. Se compare wp-content/themes/, l’errore può provenire dal tema o di parti di esso.
Non bisogna però fermarsi automaticamente al nome del file perchè il componente indicato dal log può essere il punto in cui l’errore si manifesta senza esserne necessariamente l’unica causa. Un plugin, per esempio, può chiamare una funzione fornita da un secondo componente che nel frattempo è stato disattivato o aggiornato.
Attivare il debug di WordPress
Se il log del server non fornisce informazioni sufficienti, si può utilizzare il sistema di debug integrato nel CMS.
Su VHosting è già disponibile una guida dedicata a come attivare il debug su WordPress. La configurazione viene eseguita modificando il file wp-config.php.
Durante una diagnosi si possono utilizzare queste direttive:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG attiva la modalità di debug. WP_DEBUG_LOG permette di registrare i messaggi nel file wp-content/debug.log mentre con WP_DEBUG_DISPLAY impostato su false si evita invece di mostrare gli errori direttamente ai visitatori.
Dopo aver attivato il debug si ricarica la pagina che produce l’errore e si controlla il file debug.log.
Su un sito pubblico è preferibile non lasciare la modalità di debug attiva dopo aver terminato la diagnosi: questo anche per motivi di sicurezza.
Errore critico causato da un plugin
I plugin sono una delle prime aree da controllare perché aggiungono codice PHP all’esecuzione di WordPress e possono interagire tra loro, con il tema e con il core.
Se dal log emerge chiaramente il nome di un plugin, la prima prova consiste nel disattivarlo.
Quando la bacheca di WordPress è ancora raggiungibile, l’operazione può essere effettuata normalmente dalla sezione Plugin. Se invece anche /wp-admin/ restituisce l’errore critico, si può intervenire tramite il File Manager dell’hosting oppure tramite FTP/SFTP.
Si entra nella directory:
wp-content/plugins/
e si rinomina temporaneamente la cartella del plugin sospetto. Per esempio:
plugin-esempio plugin-esempio-disabled
WordPress non troverà più il plugin nel percorso previsto e non potrà caricarlo normalmente. A questo punto se il sito torna ad essere visibile e l’errore scompare, si ha una chiara indicazione sul componente coinvolto ma non necessariamente da rimuovere completamente, infatti, è bene verificare gli aggiornamenti disponibili e la compatibilità con la versione di WordPress e di PHP utilizzata.
Come individuare un plugin problematico quando non si conosce il responsabile
Se il log non permette di identificare immediatamente il componente, si può procedere per esclusione.
Con accesso al filesystem si può rinominare temporaneamente l’intera directory:
wp-content/plugins
per esempio in:
wp-content/plugins-disabled
Se il sito torna a funzionare, il problema è probabilmente collegato a uno dei plugin presenti. Si ripristina quindi il nome originale della directory e si procede disattivando e verificando i plugin singolarmente fino a isolare quello coinvolto.
Questo metodo è più utile del cancellare componenti a caso perché permette di restringere progressivamente il campo della diagnosi.
Errore critico causato dal tema
Un tema WordPress ol tre a contenere codice HTML e CSS, può includere codice PHP nel file function.php o in classi sviluppate ad hoc per aggiungere funzionalità al sito.
Un errore nel tema può quindi provocare lo stesso blocco prodotto da un plugin.
Se il log indica un file contenuto nella directory:
wp-content/themes/nome-tema/
si può verificare il comportamento del sito utilizzando temporaneamente un tema predefinito di WordPress già installato. Sconsigliato è rinominare una sola directory del tema in quanto parte integrante del pacchetto e non isolante.
Quando non è possibile accedere alla bacheca, la cartella del tema attivo può essere rinominata tramite File Manager o FTP, in questo modo l’installazione aggancerà il primo tema disponibile nella cartella theme motivo per cui WordPress stesso consiglia sempre di conservare, anche se disattivato, uno dei propri temi di default tra i vari Twenty.
Se dopo il cambio il sito riprende a funzionare, si può concentrare l’analisi sul tema, sulle sue personalizzazioni o su eventuali modifiche recenti al codice.
Controllare la versione di PHP
Anche la versione di PHP utilizzata dal server può avere un ruolo.
Plugin e temi meno recenti possono utilizzare funzioni o sintassi o librerie non compatibili con versioni PHP più nuove. Può accadere anche il contrario: un componente moderno può richiedere una versione PHP superiore a quella configurata sull’hosting.
Prima di cambiare versione PHP conviene quindi leggere il messaggio presente nel log e verificare i requisiti dichiarati dai componenti utilizzati.
Passare casualmente da una versione all’altra di PHP può far scomparire temporaneamente un errore senza chiarirne la causa. È preferibile identificare prima il componente incompatibile e poi scegliere una versione supportata dall’intera installazione.
Controllare il limite di memoria PHP
Un’altra causa possibile è l’esaurimento della memoria assegnata a PHP.
Nel log, una situazione di questo tipo viene generalmente riconosciuta dalla presenza di un messaggio relativo alla memoria consentita esaurita, spesso identificabile dall’espressione Allowed memory size exhausted.
In questo caso aumentare il limite può essere necessario, essere scambiato come la soluzione definitiva al problema.
È bene quindi identificare quale plugin consuma una quantità anomala di memoria a causa di un errore, aumentare il limite può soltanto spostare il problema, ancor di più quale processo stia utilizzando le risorse e perché.
File di WordPress mancanti o danneggiati
Un aggiornamento interrotto, un trasferimento FTP incompleto o una modifica accidentale possono lasciare alcuni file del core mancanti o danneggiati.
Il log può in questo caso mostrare errori relativi a file che WordPress tenta di includere ma non riesce a trovare.
Se è stato verificato che il problema riguarda realmente il core, i file di WordPress possono essere sostituiti con copie pulite della stessa versione o reinstallati seguendo una procedura controllata.
La directory wp-content e il file wp-config.php richiedono particolare attenzione perché contengono rispettivamente plugin, temi, upload e configurazione dell’installazione. Non vanno sovrascritti indiscriminatamente durante una reinstallazione manuale.
Cosa fare se l’errore compare dopo un aggiornamento
Quando l’errore critico compare immediatamente dopo un aggiornamento, la sequenza temporale offre un indizio importante.
Si controlla prima il log. Se viene indicato il plugin appena aggiornato, si verifica quel componente. Lo stesso principio vale per un tema o per il core.
Non conviene invece ripristinare immediatamente tutto il sito senza sapere cosa sia successo. Un rollback può essere necessario, ma prima è utile conservare il messaggio di errore e identificare il componente che ha causato il blocco. In questo modo si evita di riprodurre lo stesso problema al successivo aggiornamento.
Quando conviene ripristinare un backup
Il ripristino di un backup è utile quando serve riportare rapidamente online un sito e la ricerca della causa richiede più tempo.
Bisogna però considerare la data della copia. Ripristinando un backup precedente si possono perdere ordini, commenti, modifiche ai contenuti o altri dati registrati dopo la sua creazione.
Su siti dinamici, come un e-commerce, il ripristino completo del database richiede quindi più attenzione rispetto a un semplice sito vetrina.
Quando possibile, si può ripristinare il servizio e creare appena possibile un ambiente di staging dove riprodurre l’errore. Si ottiene così uno spazio separato nel quale aggiornare plugin, cambiare PHP e analizzare i log senza interrompere nuovamente il sito pubblico.
Come affrontare l’errore critico senza procedere a tentativi
Il metodo più efficace resta quello diagnostico. Si parte dal momento in cui è comparso il problema. Si controllano eventuali aggiornamenti o modifiche appena eseguite. Si legge il log PHP. Se necessario si attiva il debug di WordPress. Solo dopo si interviene sul componente indicato.
Disattivare tutti i plugin, cambiare tema, aumentare la memoria e modificare PHP contemporaneamente rende invece difficile capire quale operazione abbia realmente risolto il problema.
Una modifica alla volta permette di verificare causa ed effetto.
Dopo aver individuato il componente responsabile si può decidere se aggiornarlo, sostituirlo, correggerlo oppure contattarne lo sviluppatore. Infine si disattiva il debug e si controlla nuovamente il log per verificare che non continuino a essere generati errori fatali.
Dove si incontra questo errore nella pratica
L’errore critico di WordPress si incontra soprattutto dopo l’installazione o l’aggiornamento di plugin e temi, dopo un cambio della versione PHP oppure in seguito a modifiche manuali al codice. Può comparire sull’intero sito, soltanto nella bacheca oppure su una singola pagina che esegue una funzione problematica.
Dal pannello hosting si interviene normalmente attraverso File Manager, gestione PHP e log degli errori. Con FTP o SFTP si possono invece raggiungere direttamente le directory wp-content/plugins e wp-content/themes. WordPress fornisce infine il proprio debug.log per collegare il messaggio generico visualizzato nel browser all’errore PHP che lo ha realmente provocato.
È questo passaggio a fare la differenza: non limitarsi a far sparire la schermata di errore, ma prenderne nota, conoscerlo, così in caso di ricaduta i tempi successivi alla rimessa online del proprio sito diventano sempre più brevi. Certo, prevenire è sempre meglio che curare ma la conoscenza del perchè sia successo, lo è ancor di più.
