Come sopprimere errori e avvisi in WordPress in caso di emergenza

A volte errori o avvisi PHP iniziano a comparire sul tuo sito WordPress in produzione e rovinano il design o confondono i visitatori. Puoi nascondere temporaneamente quei messaggi a schermo così il sito pubblico torna ad avere un aspetto normale. È solo un passaggio di emergenza. Non ripara il bug e non significa che il problema sia sparito.

Importante: nascondere avvisi o errori sullo schermo è solo temporaneo. Sopprimere ciò che viene mostrato non risolve la causa di fondo. Usalo soltanto come mitigazione a breve termine su un sito in produzione; poi ispeziona i registri in modo sicuro, identifica il plugin, il tema o il codice PHP responsabile, lavora da un backup o da una copia di staging, correggi o aggiorna quel codice e verifica il sito. Non trattare gli errori nascosti come se fosse sicuro ignorarli. Disattivare WP_DEBUG non scrive nemmeno gli errori in un file di registro.

Passaggio temporaneo: nascondere i messaggi di errore ai visitatori

WordPress include già una riga WP_DEBUG in wp-config.php. Modifica quella riga esistente. Non incollare un secondo define( 'WP_DEBUG', ... ): definire due volte la stessa costante può generare un avviso PHP. Inserisci queste impostazioni prima del commento /* That's all, stop editing! */, non dopo.

1. Individua `wp-config.php`

Collegati con un client FTP o il file manager del tuo hosting e apri wp-config.php nella directory principale della tua installazione WordPress.

2. Modifica la riga `WP_DEBUG` esistente

Cerca la riga che già assomiglia a define( 'WP_DEBUG', true ); o define( 'WP_DEBUG', false );. Modificala così il debug è disattivato:

define( 'WP_DEBUG', false );

Usa il valore booleano false senza virgolette. Un 'false' tra virgolette è una stringa e PHP lo tratterebbe come vero.

3. Nascondi gli errori PHP ancora visibili a schermo, se serve

Alcuni host stampano ancora errori PHP anche quando la modalità debug di WordPress è disattivata. Se succede, aggiungi la riga seguente vicino all’impostazione WP_DEBUG solo se non è già presente:

@ini_set( 'display_errors', 0 );

Dopo una modifica attenta, quella sezione dovrebbe apparire così, non come due copie di WP_DEBUG una sopra l’altra:

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

Cosa fa questo:

define( 'WP_DEBUG', false ); — Disattiva la modalità debug di WordPress. I visitatori non dovrebbero più vedere l’output di debug di WordPress. Questo non registra gli errori al posto tuo.
@ini_set( 'display_errors', 0 ); — Dice a PHP di non stampare gli errori nell’HTML della pagina. È un’impostazione di visualizzazione, non una correzione.

Evita error_reporting(0); come approccio principale. Silenzia i report PHP in modo così completo che diventa più difficile capire cosa si è rotto.

Cosa devi fare dopo: diagnosticare e correggere l’errore reale

Non appena il sito pubblico torna leggibile, trova la causa. Un buon flusso di lavoro:

Fai un backup prima di modificare plugin, temi o codice.
Riproduci il problema su una copia di staging o su un sito locale ogni volta che puoi, così i visitatori non vedono mai l’output di debug.
Su quella copia di staging, attiva la registrazione senza mostrare errori a schermo. Inserisci questo prima di /* That's all, stop editing! */ e aggiorna le righe di debug esistenti invece di duplicarle:

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

Come funzionano insieme queste righe:

WP_DEBUG — deve essere true perché le altre due costanti di debug abbiano effetto.
WP_DEBUG_LOG — scrive i messaggi in wp-content/debug.log (o in un altro percorso che imposti). Non fa nulla se WP_DEBUG è false.
WP_DEBUG_DISPLAY — impostato su false, più display_errors impostato su 0, tiene quei messaggi fuori dalla pagina così puoi leggerli nel registro.

Apri debug.log tramite FTP o il file manager del tuo host, non lasciandolo scaricabile nel browser. Un file di registro dentro wp-content può esporre percorsi del server e nomi di plugin se qualcuno lo ottiene via HTTP. Quando hai finito, disattiva di nuovo il debug ed elimina o limita il file di registro.

Usa il registro per identificare il plugin, il tema o il file PHP che ha generato l’avviso o l’errore. Aggiorna o correggi quel codice, poi ricarica le pagine interessate per confermare che il messaggio è scomparso.

WordPress documenta questa configurazione di debug nel suo manuale per sviluppatori.

Perché non dovresti fermarti a nascondere il messaggio

Gli errori nascosti possono comunque rompere funzioni, rallentare il sito o lasciare un problema di sicurezza. La pulizia a schermo protegge solo i visitatori mentre lavori. L’obiettivo reale è un sito stabile con il problema di fondo risolto.

Conclusione

In emergenza puoi nascondere l’output degli errori di WordPress e PHP modificando la riga WP_DEBUG esistente in false e, se serve, disattivando display_errors: sempre prima del commento “stop editing” e mai definendo due volte la stessa costante. Poi diagnostica la causa su un backup o un sito di staging con registrazione di debug, correggi il plugin, il tema o il codice PHP responsabile e verifica. Nascondere un avviso è temporaneo; ciò che resta è correggere l’errore.