Cosa fare se un aggiornamento di WordPress rompe il sito: guida alla diagnostica

Succede sempre nei momenti meno opportuni. Fai clic su quel maledetto tasto “Aggiorna”, ti allontani un secondo a prendere un caffè e, quando torni davanti allo schermo, il sito è svanito. Al suo posto c’è un’orribile pagina bianca, oppure quel messaggio sinistro che recita “Si è verificato un errore critico su questo sito”.

La tentazione istintiva è correre subito ai ripari, imbracciare il terminale e fare un downgrade al volo per tornare al passato.

Fermati un attimo. Respera.

Fare un downgrade alla cieca senza aver capito cosa si è rotto è come cambiare il motore dell’auto solo perché si è bucata una gomma. Prima di smontare mezza infrastruttura, bisogna fare i detective. Vediamo come scovare il colpevole in pochi minuti, passo dopo passo, senza perdere la testa.

1. Accendi le luci: attiva il WP_DEBUG

Di default, quando WordPress va in blocco, nasconde i dettagli tecnici per motivi di sicurezza. Invece di mostrare il codice rotto, ti mostra il muro d’omertà della schermata d’errore. Dobbiamo costringerlo a parlare.

Apri il file wp-config.php nella cartella principale del tuo sito (tramite SSH, WP-CLI o il File Manager del tuo hosting) e cerca questa riga:

PHP

define( 'WP_DEBUG', false );

Cambia quel false in true:

PHP

define( 'WP_DEBUG', true );

Se la riga non c’è, aggiungila poco prima del testo /* That's all, stop editing! Happy publishing. */.

Da questo momento, ricaricando la pagina del sito, non vedrai più un errore generico. Vedrai apparire una riga di codice che ti dice esattamente quale file e quale linea stanno facendo i capricci. Nove volte su dieci troverai scritto qualcosa del tipo /wp-content/plugins/nome-plugin-problematico/....

Ecco trovato il colpevole.

2. Crea la scatola nera: il log degli errori

Vedere gli errori a schermo è utile, ma a volte rischia di mostrare avvisi poco importanti anche ai visitatori di passaggio (se il sito è parzialmente visibile). La mossa più pulita è chiedere a WordPress di annotare tutto in un diario segreto.

Subito sotto la riga del WP_DEBUG, incolla queste istruzioni:

PHP

define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Cosa abbiamo fatto?

• WP_DEBUG_LOG dice a WordPress di salvare ogni errore all’interno di un file di testo.
• WP_DEBUG_DISPLAY evita di sparare gli errori in faccia agli utenti che navigano la pagina.

Ora fai un paio di refresh sulla pagina rotta. Poi vai nella cartella /wp-content/ e troverai un file fresco di stampa chiamato debug.log. Aprilo: le ultime righe in fondo ti racconteranno filo e per segno la dinamica dell’incidente.

3. Dai un’occhiata dietro le quinte: i log del server

A volte il problema è così grave che WordPress non riesce nemmeno ad avviarsi per scrivere il suo diario di bordo. Il sistema si blocca prima. In questo caso, devi salire di livello e interrogare direttamente il server web (Nginx o Apache).

Se usi un pannello di controllo sul server o ti colleghi via SSH, cerca la cartella dei log di sistema (di solito posizionata in /var/log/nginx/error.log oppure /var/log/apache2/error.log).

In alternativa, da terminale puoi leggere gli errori in tempo reale mentre provi ad caricare la pagina del sito:

Bash

tail -f /var/log/nginx/error.log

Se vedi errori tipo Fatal error: Allowed memory size of... exhausted, non è colpa del codice rovinato: hai semplicemente finito la memoria RAM assegnata a PHP. Se vedi errori relativi a versioni non compatibili (es. Parse error legato a funzioni deprecate), significa che il tuo server sta girando su una versione di PHP troppo vecchia per il nuovo aggiornamento.

Leggi anche: PHP, aggiornamento di sicurezza critico: cosa fare su aaPanel e sul proprio server

4. Isola l’incendio (senza toccare il core)

Adesso che hai le prove in mano, molto probabilmente ti renderai conto che il core di WordPress non c’entra nulla. Il 95% delle volte la colpa è di un plugin rimasto indietro con gli aggiornamenti o di una funzione del tema che fa a cazzotti con la nuova versione di PHP.

Leggi anche: PHP2Shell: la doppia falla che fa tremare milioni di siti web (WordPress compreso)

Se hai individuato il plugin canaglia dal file debug.log, non serve fare il downgrade di tutto il sito. Spegnilo al volo da terminale con WP-CLI:

Bash

wp plugin deactivate nome-plugin-colpevole

Se non hai WP-CLI a portata di mano, ti basta entrare via FTP nella cartella /wp-content/plugins/ e rinominare la cartella di quel singolo plugin (ad esempio da seo-plugin a seo-plugin-OFF). WordPress non trovandolo più lo disattiverà all’istante e il sito tornerà a respirare.

Verdetto finale: serviva davvero il downgrade?

Ora che le acque si sono calmate, fai la conta dei danni.

Se il sito è tornato online semplicemente disattivando un plugin secondario o aggiornando la versione di PHP dal pannello dell’hosting, hai risparmiato tempo, fatica e inutili salti nel vuoto.

Se invece scopri che a rompere tutto è il tema principale su cui poggia l’intero layout del sito — e lo sviluppatore non ha ancora rilasciato una patch correttiva — allora sì: la diagnosi ti dà il via libera per procedere con il downgrade in totale sicurezza. Ma almeno adesso sai esattamente cosa stai facendo e perché.