Conflitto tra plugin WordPress dopo un aggiornamento: come individuarlo senza interrompere il sito

Un sito WordPress che smette di funzionare dopo un aggiornamento non dimostra automaticamente che l'ultimo plugin aggiornato sia il responsabile. L'aggiornamento può aver reso visibile un'incompatibilità già presente tra plugin, tema, versione PHP, cache o configurazione dell'hosting.

Per individuare un conflitto tra plugin WordPress serve una verifica ripetibile: il problema deve scomparire quando un componente viene disattivato e ricomparire quando viene riattivato, nelle stesse condizioni. Log e Recovery Mode aiutano a localizzare il punto in cui avviene l'errore, ma la conferma arriva dai test.

1. Prima di intervenire: proteggi il sito e registra il sintomo

Prima di disattivare plugin o cambiare tema, verifica di avere un backup utilizzabile o un restore point recente. Non è una diagnosi e non dovrebbe essere il primo rimedio automatico, ma consente di lavorare con un margine di sicurezza.

Annota inoltre:

• l'ora in cui il problema è comparso e l'aggiornamento eseguito poco prima;
• il messaggio di errore completo;
• se il difetto riguarda frontend, area amministrativa o entrambi;
• l'URL o l'azione precisa che produce l'errore;
• la presenza di cache, CDN, WAF o object cache;
• la versione PHP, se disponibile.

Se il sito gestisce vendite, prenotazioni, iscrizioni o utenti autenticati, non disattivare tutti i plugin in produzione come prima scelta. Usa prima uno staging, una sessione di troubleshooting isolata oppure programma una breve finestra di manutenzione. Su un sito informativo con poco traffico, invece, un test in produzione può essere accettabile solo se eseguito rapidamente e con un backup disponibile.

Evita di eliminare plugin o temi: la disattivazione e la rinomina temporanea sono reversibili e mantengono file e impostazioni utili alla diagnosi.

2. Escludi un aggiornamento incompleto o un problema evidente

Se il sito mostra il messaggio di manutenzione programmata subito dopo un aggiornamento interrotto, controlla nella directory principale di WordPress la presenza del file .maintenance. Rimuovilo soltanto se l'aggiornamento è effettivamente terminato o rimasto bloccato. La procedura di aggiornamento è descritta nella documentazione WordPress.

Svuota la cache del plugin, del server o della CDN solo quando il difetto sembra legato a file CSS, JavaScript o pagine obsolete. Non è una soluzione per un fatal error PHP, un timeout o un errore di database.

Se ricevi errori 404 dopo l'update, prova prima a salvare nuovamente le impostazioni in Impostazioni → Permalink, senza modificare nulla: l'operazione rigenera le regole di rewrite. Consulta la documentazione della schermata Permalink.

Errori come Allowed memory size exhausted, timeout, problemi di connessione al database, permessi errati o incompatibilità PHP possono comparire dopo un aggiornamento, ma non dimostrano un conflitto tra plugin. In questi casi verifica anche risorse e configurazione dell'hosting.

3. Raccogli le informazioni utili: Recovery Mode, debug e Salute del sito

Usa Recovery Mode per recuperare l'accesso

Quando WordPress rileva un fatal error PHP durante una normale richiesta, può inviare all'amministratore un'email con un link di Recovery Mode. La sessione permette di accedere al pannello e mettere temporaneamente in pausa il componente indicato. La documentazione di Recovery Mode spiega il funzionamento della modalità di recupero.

L'email può non arrivare e Recovery Mode non copre necessariamente cron, processi in background o errori non fatali. Il plugin indicato è il componente nel cui codice si manifesta il crash: va comunque verificato con i passaggi descritti più avanti.

Attiva il debug senza esporre errori ai visitatori

Se puoi modificare wp-config.php, aggiungi temporaneamente queste righe prima del commento finale previsto dalla configurazione standard:

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

Con questa configurazione WordPress scrive normalmente gli errori in wp-content/debug.log; il percorso può però essere diverso se WP_DEBUG_LOG è stato configurato con un valore personalizzato. La direttiva ini_set è una misura aggiuntiva: alcuni hosting possono applicare impostazioni PHP che la prevalgono. Segui la guida ufficiale al debug di WordPress.

Una riga come questa è un buon punto di partenza:

PHP Fatal error: Uncaught Error: Call to undefined function ...
in /wp-content/plugins/nome-plugin/includes/file.php on line 123

Cerca tipo di errore, timestamp, percorso del file, riga e azione che lo riproduce. Un percorso sotto /wp-content/plugins/nome-plugin/ restringe la ricerca, ma non basta da solo a stabilire la causa.

Terminati i test, rimuovi le costanti aggiunte oppure impostale esplicitamente a false. Verifica anche che il file di log non sia accessibile pubblicamente: può contenere percorsi del server, query o altri dati tecnici.

Controlla Salute del sito

In Strumenti → Salute del sito, la scheda Stato segnala problemi e miglioramenti consigliati; Informazioni riepiloga WordPress, PHP, tema, plugin, database e server. Salva le versioni e i dati PHP prima dei test: saranno utili anche in caso di richiesta al supporto.

Salute del sito non identifica automaticamente il plugin responsabile, ma aiuta a individuare anomalie dell'ambiente. Per approfondire, consulta la documentazione della schermata Salute del sito.

4. Preferisci staging o una sessione di troubleshooting isolata

Uno staging riproduce il sito in un ambiente separato e consente di disattivare plugin, cambiare tema e aggiornare componenti senza modificare il sito pubblico. È l'opzione da preferire per e-commerce, membership, multisite e siti con processi di pagamento.

Quando non hai uno staging, il plugin Health Check & Troubleshooting può offrire una modalità di troubleshooting che disattiva plugin e cambia tema soltanto nella sessione dell'amministratore. Le istruzioni del progetto sono disponibili anche nel manuale del supporto WordPress.

Il risultato di una sessione amministrativa non coincide sempre con quello di un visitatore anonimo: cookie, ruoli utente, checkout, membership e cache possono cambiare il comportamento. Inoltre, cache del server, CDN, drop-in e must-use plugin possono restare attivi. I mu-plugin non sono gestiti come plugin normali e, negli hosting gestiti, possono controllare cache, sicurezza o integrazioni del provider; non rinominarli senza sapere quale funzione svolgono. La loro gestione è descritta nella documentazione per mu-plugin.

5. Isola plugin e tema con test progressivi

Se lavori in staging, in una sessione isolata o in una finestra di manutenzione, segui questa sequenza:

1. Disattiva tutti i plugin normali e ripeti esattamente l'URL o l'azione che genera l'errore.
2. Se l'errore scompare, riattiva un plugin alla volta e ripeti ogni volta la stessa prova.
3. Se il problema resta con tutti i plugin inattivi, attiva temporaneamente un tema WordPress predefinito compatibile e ripeti il test.
4. Se il difetto rimane anche con tema predefinito e plugin normali inattivi, interrompi la ricerca del plugin responsabile: controlla mu-plugin, cache, PHP, database, permessi e hosting.

Registra ogni passaggio: configurazione testata, URL o azione, risultato ed eventuale riga del log. Questo evita di scambiare un effetto della cache per una correzione reale.

Verifica una possibile interazione

Un plugin può funzionare correttamente da solo e fallire solo insieme a un altro plugin o al tema. In questo caso prova una combinazione minima:

• tema predefinito, nessun plugin;
• plugin A da solo;
• plugin B da solo;
• plugin A e B insieme;
• tema originale con A e B;
• cache o minificazione riattivate, se pertinenti.

Se A e B funzionano separatamente e l'errore torna solo con A+B, hai individuato un'interazione da documentare. Se compare soltanto con il tema originale, controlla anche child theme, template personalizzati e integrazioni del page builder.

Un caso tipico riguarda un page builder che torna a funzionare con il plugin di cache disattivato, ma genera di nuovo l'errore quando entrambi sono attivi. Prima di attribuire il problema a uno solo dei due componenti, ripeti il test con cache svuotata e nelle stesse condizioni: l'informazione utile per il supporto è la combinazione precisa che riproduce il difetto.

6. Se wp-admin non è accessibile

Prova prima Recovery Mode. Se non è disponibile, dal File Manager o via FTP rinomina la cartella del plugin indicato, per esempio da /wp-content/plugins/nome-plugin/ a /wp-content/plugins/nome-plugin.hold/. WordPress non potrà caricare quel plugin, permettendoti di verificare se il sito torna accessibile.

Rinominare l'intera cartella /wp-content/plugins/ può essere utile solo per recuperare temporaneamente l'accesso, ma non costituisce una disattivazione persistente. WordPress conserva infatti l'elenco dei plugin attivi nel database: una volta ripristinato il nome della cartella, i plugin possono tornare caricabili. Dopo aver recuperato l'accesso, disattivali dal pannello e riattivali progressivamente.

Con SSH e WP-CLI puoi usare:

wp plugin deactivate nome-plugin
wp plugin deactivate --all
wp theme activate twentytwentyfive

I flag --skip-plugins e --skip-themes possono aiutare a eseguire comandi senza caricare plugin e temi normali; i mu-plugin restano un'eccezione. Vedi la documentazione di wp plugin deactivate.

La modifica diretta del database è un'ultima risorsa e richiede un backup. In una normale installazione singola, l'opzione active_plugins si trova nella tabella il cui prefisso può essere diverso da wp_. Impostarla a a:0: disattiva l'elenco dei plugin attivi, ma non esegue gli hook di disattivazione: alcuni plugin possono quindi lasciare cache o configurazioni da rimuovere manualmente. In multisite, i plugin attivi in rete si gestiscono dall'amministrazione di rete, non dal singolo sito.

7. Risolvi il problema e documenta la causa

Dopo avere identificato il componente o la combinazione coinvolta, controlla changelog e requisiti di WordPress e PHP. Potrebbe essere disponibile una correzione, essere necessario sostituire il plugin o il tema, oppure avere senso un rollback ragionato della sola versione problematica. Se il problema riguarda risorse o configurazione, coinvolgi l'hosting invece di lasciare disattivato un componente che non è la causa.

Per aprire un ticket utile, invia errore anonimizzato, versioni di WordPress, PHP, plugin e tema, passaggi per riprodurre il difetto, combinazione che lo attiva e dati pertinenti di Salute del sito. Un report riproducibile è molto più utile di "il sito non funziona dopo l'aggiornamento".

Dopo la correzione, verifica frontend da visitatore anonimo, accesso amministrativo e funzioni essenziali come moduli, ricerca, pagamenti o aree riservate. Svuota le cache solo se necessario, disattiva il debug e annota causa e soluzione. Per siti critici o non testabili senza impatto sugli utenti, è prudente affidare l'analisi a un servizio di assistenza WordPress e usare uno staging per i futuri aggiornamenti.