WP_DEBUG_DISPLAY vs WP_DEBUG_LOG

Due costanti di debug WordPress spesso confuse: WP_DEBUG_DISPLAY controlla se gli errori vanno a video, WP_DEBUG_LOG se vanno su file. Capire la differenza è fondamentale per evitare leak di informazioni in produzione.

WP_DEBUG_DISPLAY: gli errori a video

Quando WP_DEBUG_DISPLAY=true, WordPress invia gli errori PHP direttamente nell’HTML della pagina, in coda al body o dove avvenuti. Vantaggio: feedback immediato durante sviluppo. Svantaggio: in produzione espone path assoluti server, versioni software, e informazioni sensibili che possono essere usati da attaccanti per reconnaissance. Default WordPress: true (pericoloso se non lo si setta a false esplicitamente).

WP_DEBUG_LOG: gli errori su file

Quando WP_DEBUG_LOG=true (o string path), gli errori vengono appesi a un file di log. Vantaggio: visibilità senza esporre nulla all’utente. Svantaggio: richiede check manuale del file. WP Error Monitor risolve il problema facendo tail incrementale e portando i log su dashboard. Path consigliato: fuori web root.

Combinazione ottimale

Produzione: WP_DEBUG=true + WP_DEBUG_LOG='/var/log/...' + WP_DEBUG_DISPLAY=false. Staging: stessa di prod per realismo. Dev locale: tutto true, log a video durante coding. Mai produzione con DISPLAY=true.

Direttive php.ini correlate

Le costanti WordPress sono solo metà del puzzle: PHP ha sue direttive che possono override. display_errors=Off in php.ini sovrascrive WP_DEBUG_DISPLAY=true. log_errors=Off impedisce WP_DEBUG_LOG anche se true. error_reporting controlla quale livello viene loggato. Best practice produzione: display_errors=Off, log_errors=On, error_reporting tutti gli errori escluso deprecated e strict. WP Error Monitor non dipende da queste direttive perché ha proprio handler.

Strategie per debug temporaneo in produzione

A volte serve debug rapido in produzione senza modificare wp-config.php (rischio commit accidentale). Trick: 1) Drop-in mu-plugin temporaneo con codice debug condizionale (es. solo se parametro URL wpem_debug TOKEN nell’URL), 2) WP Error Monitor 'Live Tail’ mode che mostra eventi in real-time in dashboard, 3) Plugin Debug This (visibile solo admin) per ispezione live. Sempre rimuovere/disabilitare dopo l’investigazione.

Production checklist

Prima di passare un sito WordPress in produzione, esegui checklist debug: 1) WP_DEBUG_DISPLAY=false, 2) display_errors=Off in php.ini, 3) WP_DEBUG_LOG con path fuori web root, 4) WP_ENVIRONMENT_TYPE='production', 5) DISALLOW_FILE_EDIT=true (no editor wp-admin), 6) FORCE_SSL_ADMIN=true se HTTPS attivo, 7) WP_HTTP_BLOCK_EXTERNAL=true se vuoi limitare outbound (con WP_ACCESSIBLE_HOSTS whitelist), 8) WP Error Monitor agent installato e funzionante. Il pannello 'Sito Health' di WP segnala se mancano. WP Error Monitor ha companion command 'wp wpem audit-prod’ che verifica tutto in un colpo.

Logging best practice per developer

Quando scrivi codice custom, segui best practice di logging: 1) usa error_log() per debug interni, MAI echo/print/var_dump (output diretto), 2) prefixa messaggi con plugin name per facile grep ('[MyPlugin] processing item 123'), 3) usa severity appropriata (warning vs error), 4) struttura messaggi con campi consistenti (timestamp, action, target), 5) evita PII in log (vedi GDPR), 6) cleanup log temporanei. WP Error Monitor cattura tutti i error_log() e li categorizza come 'context=custom_code' con plugin source attribuito automaticamente.

Esempio configurazione per ambiente

Esempio configurazione completa per ogni ambiente: in dev locale tutte le costanti debug a true incluse SAVEQUERIES e SCRIPT_DEBUG, errori displayed e logged; in staging WP_DEBUG=true e WP_DEBUG_LOG con path fuori webroot ma DISPLAY=false (mima prod ma con log accessibili al team); in prod WP_DEBUG=true (per logging) ma DISPLAY=false e LOG con path assoluto fuori webroot e SCRIPT_DEBUG=false e SAVEQUERIES=false (impatto memory). Plus WP_ENVIRONMENT_TYPE settato esplicitamente in ogni ambiente così plugin che lo leggono cambiano comportamento appropriato (Stripe usa test mode in non-prod, ecc.).

Procedura passo-passo

1. Verifica in wp-config.php la presenza delle costanti.
2. Per produzione setta WP_DEBUG_DISPLAY=false e @ini_set('display_errors', 0).
3. Setta WP_DEBUG_LOG con path assoluto fuori web root.
4. Verifica con phpinfo() o test pagina che display_errors sia 0.
5. Crea una pagina di test che triggera un'E_NOTICE.
6. Conferma che a video non appaia nulla e nel log si.
7. Configura WP Error Monitor per fare tail del log.
8. Verifica direttive php.ini con phpinfo() pagina di test.
9. Setta error_reporting allineato a WP_DEBUG.

Errori comuni e come risolverli

• DISPLAY=false ma errori visibili: Altro setting (es. ini_set in tema/plugin) sovrascrive: cerca display_errors nel codebase.
• LOG=true ma file non creato: Permessi wp-content/ insufficienti: verifica con touch wp-content/debug.log.
• Log scritto ma pagina mostra errore generico WordPress: È il fatal handler di WP 5.2+: comportamento corretto.
• WP_DEBUG_DISPLAY=true ma errori nascosti: display_errors=Off in php.ini sovrascrive: cambia php.ini o .user.ini.
• Log non scritto nonostante WP_DEBUG_LOG: log_errors=Off in php.ini: setta a On.

Domande frequenti

D: Posso vedere errori solo per IP specifico?
R: Sì, usando condizione PHP su REMOTE_ADDR prima di settare DISPLAY=true.

D: Quanto velocemente cresce debug.log?
R: Dipende dal sito: tipicamente 1-50MB/giorno. Usa logrotate per gestione.

D: WP Error Monitor scrive su debug.log?
R: No, ha un proprio canale separato. Può leggere debug.log esistente.

D: Posso usare .user.ini?
R: Sì, per shared hosting dove non hai accesso a php.ini globale.

D: WP Error Monitor live tail rallenta?
R: Polling WebSocket leggero: impatto trascurabile.

Hai bisogno di aiuto?

Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.