Configurare debug.log WordPress in modo sicuro

Il file debug.log è il log nativo di WordPress, attivato tramite costanti in wp-config.php. Usarlo in produzione richiede cautela: posizione, permessi e accesso devono essere blindati per evitare leak di informazioni sensibili. Vediamo come configurarlo in sicurezza affiancandolo a WP Error Monitor.

Costanti chiave

WP_DEBUG=true attiva il debug; WP_DEBUG_LOG=true scrive su wp-content/debug.log (path default); WP_DEBUG_DISPLAY=false impedisce di mostrare errori a video; SCRIPT_DEBUG=true carica versioni non minificate JS/CSS (utile solo in dev). Mai abilitare WP_DEBUG_DISPLAY in produzione: leak di path server e info sensibili.

Posizione sicura del log

Per default debug.log finisce in wp-content/debug.log, accessibile via HTTP se non blindato. Best practice: spostalo fuori dalla web root con WP_DEBUG_LOG='/var/log/wp/sito.log'. Crea la directory con: mkdir -p /var/log/wp && chown www-data:www-data /var/log/wp && chmod 750 /var/log/wp. Aggiungi un .htaccess in wp-content con 'Require all denied’ su debug.log come safety net.

Integrazione con WP Error Monitor

L’agent legge debug.log e ne fa tail incrementale: nuove righe diventano eventi nel CRM, parseate e categorizzate. Così' hai il meglio di entrambi i mondi: file locale per debug deep + dashboard cloud per visibilità team. Imposta WPEM_TAIL_DEBUG_LOG=true per attivare la feature.

Centralized logging con syslog

Per setup multi-server, scrivere debug.log su file locale è subottimale: serve aggregazione. Configura PHP per inviare error log a syslog: in php.ini error_log = syslog, log_errors = On. Syslog poi inoltra a logstash/fluentd/rsyslog centrale, che aggrega in Elasticsearch o Loki. WP Error Monitor può coesistere: cattura eventi structured nel CRM, mentre syslog ha gli error_log raw per investigazione deep.

Log structured con JSON

Invece di plain text, scrivi log in formato JSON Lines: ogni evento è un JSON con campi standard (timestamp, severity, message, context, file, line, request_id). Vantaggio: parsing automatico in ELK/Loki, filtri per campo, dashboard avanzate. WP Error Monitor logga sempre in JSON internamente; per debug.log custom, configura WPEM_LOG_FORMAT=json.

Permessi e ownership corretti

I permessi del file debug.log devono bilanciare scrivibilità (PHP deve write) e leggibilità limitata (no public read). Setup ideale: file owner www-data:www-data, mode 0640 (rw per owner, r per group, nothing per others), directory parent 0750. Così' PHP scrive, ops team legge via sudo o group membership, altri utenti server non vedono. ACL extended per casi complessi: setfacl -m u:devops:r-- debug.log per dare lettura a utente specifico senza essere in group. WP Error Monitor verifica permessi all’attivazione e segnala se più larghi del necessario (security issue).

Sensitive data scrubbing

I log possono contenere dati sensibili: email utenti, IP, query string con token. GDPR richiede minimizzazione. WP Error Monitor implementa scrubbing automatico: pattern regex per maschera dati comuni (email -> [REDACTED_EMAIL], carte -> [REDACTED_CC], token -> [REDACTED_TOKEN]). Per debug.log, configura PHP error_log con filter custom che applica scrubbing prima della scrittura. Senza scrubbing, un dump var_dump nel log può esporre PII compromettendo compliance. Verifica con audit periodico: grep 'pattern_email’ debug.log; se trovi match, scrubbing non sta funzionando.

Workflow giornaliero di debug

Workflow tipico mattutino del webmaster che usa WP Error Monitor: 1) apri dashboard alle 9:00, filtra ultime 24h, 2) controlla widget 'Eventi CRITICAL/ALERT' (max 5 minuti), 3) verifica trend errori vs giorno precedente (anomalie?), 4) apri top 3 pattern errori e decidi azione (fix oggi, ignora, ticket), 5) controlla SSL Monitor per cert'in scadenza, 6) verifica backup test della notte, 7) chiudi con review ticket Perfex linkati a eventi. Tempo totale: 15-20 minuti per stato pulito di multipli siti gestiti.

Documentazione runtime

Mantieni documentazione runtime aggiornata accanto al codice: README.md della repo elenca tutte le costanti debug usate e il loro scopo, così nuovi sviluppatori capiscono subito il comportamento atteso senza dover indovinare. Aggiungi anche esempi di valore tipico per ambiente.

Procedura passo-passo

1. Apri wp-config.php del sito.
2. Aggiungi: define('WP_DEBUG', true);
3. Aggiungi: define('WP_DEBUG_LOG', '/var/log/wp/'+'sito.log');
4. Aggiungi: define('WP_DEBUG_DISPLAY', false);
5. Aggiungi: @ini_set('display_errors', 0);
6. Crea directory /var/log/wp con permessi 750 e owner www-data.
7. Aggiungi blocco in wp-content/.htaccess che nega l’accesso a debug.log.
8. Abilita WPEM_TAIL_DEBUG_LOG=true per integrare con WP Error Monitor.
9. Verifica via curl che il log non sia accessibile via HTTP.
10. Configura php.ini error_log=syslog per centralizzazione.
11. Setta WPEM_LOG_FORMAT=json per structured logs.

Errori comuni e come risolverli

• debug.log non viene scritto: Permessi cartella wp-content non corretti: chmod 775 wp-content/ con owner www-data.
• File log enorme che riempie disco: Configura logrotate o usa WPEM_LOG_MAX_SIZE=10M per rotation automatica.
• Log accessibile pubblicamente: Sposta fuori web root: è la soluzione definitiva, no workaround.
• Syslog non riceve messaggi: Verifica facility configurata (LOG_USER tipica) e rsyslog rules.
• JSON non parsato da Loki: Controlla che logstash/promtail abbia parser JSON configurato.

Domande frequenti

D: Posso usare WP_DEBUG in produzione?
R: Sì, purchè WP_DEBUG_DISPLAY=false e log fuori web root.

D: debug.log rallenta il sito?
R: Marginalmente (<1%): write append è veloce.

D: Posso disabilitare debug.log in determinate ore?
R: Sì, con codice condizionale in wp-config.php basato su date('H').

D: Quanto pesa structured logging?
R: Meno del 5 percento in più rispetto plain text: trascurabile.

D: Posso usare anche file debug.log?
R: Sì, WPEM scrive entrambi se WPEM_LOG_DUAL=true.

Hai bisogno di aiuto?

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