Come debuggare WordPress in produzione senza mettere offline il sito

Quando qualcosa si rompe su un sito WordPress in produzione, il tempo è nemico. Ma abilitare il debug in modo errato può mostrare errori sensibili agli utenti, mettere il sito offline o esporre informazioni private. Ecco come fare debug in sicurezza, senza compromettere l’esperienza utente.

⚠️ Cosa NON fare mai

Non usare mai queste righe in produzione senza precauzioni:

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);

➡️ Mostrerai errori a chi visita il sito, e se c’è un path assoluto, un nome file o una query SQL sensibile, rischi una falla di sicurezza o un disastro SEO.

✅ Debug sicuro in produzione: le best practice

🔧 1. Attiva WP_DEBUG, ma disattiva display

Nel file wp-config.php:

👉 Così gli errori saranno registrati in /wp-content/debug.log ma non visibili agli utenti.

🔧 2. Usa plugin per il debug backend-only

Per esempio:

• Query Monitor
  Mostra query lente, hook, errori PHP, chiamate AJAX — solo per utenti loggati admin.
• Debug Bar
  Rende visibili errori e hook di WordPress, solo in backend.
• Log Deprecated Notices
  Perfetto per plugin obsoleti.

📌 Tutti questi strumenti non espongono info agli utenti normali.

🔧 3. Imposta un clone temporaneo per test approfonditi

• Usa un plugin come WP Staging per creare una copia del sito (su sottodominio o cartella)
• Debugga liberamente senza influenzare la versione live
• Puoi poi applicare le modifiche sul sito principale

🔧 4. Attiva il logging anche a livello di server

Se sei su un hosting con accesso avanzato (es. VPS, Plesk, cPanel):

• Abilita log PHP da php.ini
• Verifica log errori in /var/log/apache2/error.log o /logs/error_log

Questo ti aiuta se WordPress è completamente bianco o se i plugin interferiscono.

🛠️ Suggerimenti extra per sviluppatori

• Aggiungi breakpoint JS in Chrome DevTools per problemi di front-end
• Attiva SCRIPT_DEBUG per usare i file JS/CSS non minificati:

  define( 'SCRIPT_DEBUG', true );

  Log personalizzati:

  error_log( 'Messaggio di test' );

  Traccia hook o funzioni con:

  do_action('log_hook', debug_backtrace());

   

🔐 Sicurezza prima di tutto

Ricorda di disattivare tutto il debug una volta risolto il problema. I file di log non vanno lasciati attivi in produzione per motivi di performance e sicurezza.

define('WP_DEBUG', false);

E cancella il file debug.log se non più necessario.

🔚 Conclusione

Fare debug in produzione non significa mettere a rischio il sito. Con le giuste accortezze, puoi intervenire in tempo reale su problemi urgenti, in modo professionale e invisibile per i visitatori.

🛟 Serve una mano con un errore urgente in produzione?

Posso aiutarti a isolare e correggere bug su WordPress in ambienti live, senza downtime e senza rischi per la SEO o l’utente.