Cinque costanti di debug essenziali in wp-config.php

wp-config.php: 5 costanti di debug essenziali

Conoscere le costanti di debug di wp-config.php è fondamentale per ogni webmaster WordPress. In questa guida elenchiamo le 5 più utili, con esempi di valori sicuri per produzione e per ambienti di sviluppo.

WP_DEBUG

È l’interruttore master: attiva la modalità debug che mostra warning, notice e deprecated. In produzione tienilo su false di default, ma puoi abilitarlo temporaneamente per indagini su un’incidence. WP Error Monitor cattura eventi anche con WP_DEBUG=false grazie al proprio error handler, quindi non dipendi dalla costante per la visibilità in dashboard.

WP_DEBUG_LOG e WP_DEBUG_DISPLAY

WP_DEBUG_LOG=true (o path string) scrive su file. WP_DEBUG_DISPLAY=false sopprime l’output a video. La combinazione tipica per produzione è: WP_DEBUG=true + WP_DEBUG_LOG='/var/log/wp/sito.log' + WP_DEBUG_DISPLAY=false. Questo ti dà i log senza esporre dati.

SCRIPT_DEBUG

Quando true, WordPress carica versioni non minificate di JS/CSS core. Utile per debug front-end in dev, mai in produzione (raddoppia il peso degli asset). È indipendente da WP_DEBUG: puoi attivarlo singolarmente.

SAVEQUERIES

Salva tutte le query SQL nella global $wpdb->queries con tempo di esecuzione e backtrace. Profondo impatto memoria (>50MB su pagine pesanti), quindi solo dev/staging. Plugin tipo Query Monitor lo richiedono per profilare. WP Error Monitor lo usa quando WPEM_TRACE_SLOW_QUERIES=true.

WP_ENVIRONMENT_TYPE

Costante introdotta in WordPress 5.5: define WP_ENVIRONMENT_TYPE production o staging o development o local. Plugin moderni la leggono per cambiare comportamento (es. Stripe usa test mode in non-prod). WP Error Monitor la usa per tag automatico negli eventi: così in dashboard vedi 'staging' vs 'production' senza configurazione manuale. Best practice: sempre definita esplicitamente, non lasciare default 'production' su staging.

WP_DEBUG_LOG con path personalizzato

Da WordPress 5.1 WP_DEBUG_LOG accetta una stringa con path assoluto: define WP_DEBUG_LOG con path /var/log/wordpress/sito.log. Usalo per spostare il log fuori web root. Verifica che il path sia scrivibile dall’utente PHP (chmod 755 + chown www-data). Combinato con WP_ENVIRONMENT_TYPE, puoi differenziare path per ambiente.

ALLOW_UNFILTERED_UPLOADS e rischi

Per default WordPress blocca upload di file 'pericolosi' (PHP, EXE, SVG con script). La costante define ALLOW_UNFILTERED_UPLOADS true bypassa il check, ma è rischiosa: utenti possono caricare web shell. Use case legittimo: import migrations o asset speciali da utenti trusted. Best practice: NON definire MAI in produzione, usa solo temporaneamente per operazioni admin, rimuovi subito dopo. WP Error Monitor logga ogni upload con tag 'file_type' e segnala upload sospetti (estensione non whitelist) come ALERT. Se ALLOW_UNFILTERED_UPLOADS attivo, WP Error Monitor emette warning.

WP_AUTO_UPDATE_CORE strategie

WordPress 5.6+ ha core auto-update minor di default (security patch). define WP_AUTO_UPDATE_CORE controlla comportamento: 'minor' (default, solo security), 'true' (anche major), 'false' (nessun'auto), 'betà o 'rc' (track beta). Per produzione: usa 'minor' per ricevere security automatica, ma blocca major (rischio breaking). Verifica con wp core check-update. WP Error Monitor avvisa quando major release disponibile (alert non-critical) così pianifichi update controllato. Mai usare WP_AUTO_UPDATE_CORE=true in prod senza staging gemellato.

Riepilogo costanti debug essenziali

Riepilogando le costanti debug essenziali in wp-config.php: WP_DEBUG attiva il debug master, WP_DEBUG_LOG redirige errori su file, WP_DEBUG_DISPLAY false nasconde a video, SCRIPT_DEBUG carica JS/CSS non minified in dev, SAVEQUERIES salva queries per profiling. A queste aggiungi WP_ENVIRONMENT_TYPE per distinguere prod/staging/dev, FORCE_SSL_ADMIN per HTTPS in admin, DISALLOW_FILE_EDIT per disabilitare editor codice da wp-admin (security). La combinazione corretta varia per ambiente: produzione richiede debug logged ma non displayed, dev permette display, staging mima prod ma con logging verbose.

Aggiornamento WordPress major

Quando aggiorni WordPress major, rivedi le costanti debug perché alcune cambiano semantica tra versioni. Documentazione ufficiale WordPress mantiene changelog dettagliato delle costanti supportate ed è riferimento autoritative per ogni upgrade significativo.

Procedura passo-passo

  1. Apri wp-config.php in editor con backup.
  2. Aggiungi sezione 'BEGIN WP Debug' prima della riga 'That's all, stop editing'.
  3. Inserisci: define('WP_DEBUG', true);
  4. Inserisci: define('WP_DEBUG_LOG', true);
  5. Inserisci: define('WP_DEBUG_DISPLAY', false);
  6. Inserisci: @ini_set('display_errors', 0);
  7. Per dev/staging aggiungi: define('SCRIPT_DEBUG', true); define('SAVEQUERIES', true);
  8. Salva e verifica con WP Error Monitor che gli eventi inizino ad arrivare.
  9. Aggiungi define WP_ENVIRONMENT_TYPE staging sui siti staging.
  10. Configura WP_DEBUG_LOG con path assoluto fuori web root.

Errori comuni e come risolverli

  • Errore 'cannot redefine constant': Le costanti sono già definite altrove (es. plugin): rimuovi i duplicati.
  • Log non popolato: Permessi cartella, oppure WP_DEBUG_LOG non valorizzato correttamente.
  • Sito rallentato in dev: SAVEQUERIES è attivo: disattivalo se non stai profilando.
  • WP_ENVIRONMENT_TYPE ignorata: Versione WordPress sotto 5.5: aggiorna o usa fallback wp_get_environment_type() che funziona da 5.5.
  • Path log non scrivibile: chown www-data:www-data e chmod 755 sulla directory parent.

Domande frequenti

D: Posso usare WP_DEBUG in modo selettivo?
R: Sì, con condizioni PHP: if ($_SERVER['REMOTE_ADDR']=='IP_MIO') define('WP_DEBUG', true);

D: WP_DEBUG attiva anche errori di plugin?
R: Sì, tutti i WP_Error sollevati e i trigger_error vengono mostrati/loggati.

D: WP Error Monitor sostituisce queste costanti?
R: No, le complementa. Suggeriamo di tenerle attive con log fuori web root.

D: Posso usare WP_ENVIRONMENT_TYPE dinamicamente?
R: Sì, basato su HTTP_HOST in wp-config.php.

D: Quanti env tipici?
R: production, staging, development, local: standard de facto.

Hai bisogno di aiuto?

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

Hai trovato utile quest'articolo?