I log di errore di WordPress sono il modo più veloce per capire cosa sta rompendo il sito: un 500, la schermata bianca, il checkout bloccato, il backend lento. Invece di andare a tentativi, guardi il log e lui ti dice dove guardare. Qui vediamo come attivarli e leggerli in sicurezza, una procedura di diagnosi ordinata e le soluzioni rapide agli errori più frequenti.
La sintesi, prima del dettaglio:
- In
wp-config.phpattiva il debug solo per il tempo che ti serve. - Leggi
/wp-content/debug.loge i log PHP del server (cPanel/Plesk/SSH). - Isola il problema: disattiva cache/minify, passa a un tema di default, disattiva i plugin a blocchi.
- Gli errori tipici: Memory exhausted, Max execution time, Headers already sent, Call to undefined function, DB connection.
- Finito il debug: rimetti WP_DEBUG a false e ruota o cancella il log.
Attivare e leggere i log (in modo sicuro)
Modifica wp-config.php, sopra la riga “That’s all, stop editing!”. La cosa importante è non mostrare gli errori a schermo in produzione: li scrivi solo nel log.
|
1 2 3 4 |
define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors', 0); // ulteriore garanzia |
Dove leggere:
wp-content/debug.log(il log applicativo di WordPress);- i log del server (PHP/Apache/Nginx), via cPanel, Plesk o SSH.
Dove trovo i log del server
- cPanel: Metrics → Errors, oppure File Manager →
logs/error_log; - Plesk: dominio → Logs (filtra “Error”/”PHP”) o File Manager, cartella
logs; - SSH (il path può variare):
/var/log/apache2/error.logo/var/log/nginx/error.log.
|
1 2 3 4 5 |
# SSH: lettura in tempo reale tail -f wp-content/debug.log # Cerca solo gli errori fatali grep -i "fatal" wp-content/debug.log |
Procedura di diagnosi (sempre nello stesso ordine)
Il segreto qui è la disciplina: procedi sempre nello stesso modo, così isoli il colpevole senza girare a vuoto.
- Replica l’errore e annota data e ora precise.
- Disattiva cache, minify e concatenate temporaneamente (plugin di performance e CDN).
- Passa a un tema di default (Twenty Twenty-Five o simile) e disattiva i plugin a blocchi per trovare il responsabile.
- Controlla
debug.loge i log PHP del server in corrispondenza di quella data/ora. - Risolto il problema, riattiva un po’ alla volta cache e ottimizzazioni e ritesta.
Errori frequenti e soluzioni rapide
| Messaggio nel log | Causa probabile | Soluzione rapida |
|---|---|---|
| Allowed memory size exhausted | Plugin/tema pesante, loop, memoria PHP bassa | Alza il limite in wp-config.php con WP_MEMORY_LIMIT e WP_MAX_MEMORY_LIMIT, poi rimuovi il bloat e controlla plugin recenti e query pesanti. |
| Maximum execution time of 30 seconds exceeded | Processo lungo (import, API), limiti PHP bassi | Aumenta max_execution_time (hosting o .user.ini), spezza i job, verifica il cron. |
| Cannot modify header information – headers already sent | Output prima degli header (spazi/BOM, echo in plugin/tema) |
Rimuovi BOM e spazi prima di <?php, evita il ?> di chiusura, togli gli echo negli hook di login/redirect. |
| Call to undefined function / class | Dipendenza non caricata, ordine di hook sbagliato, estensione PHP mancante | Controlla require/autoload, sistema l’ordine degli hook (init vs plugins_loaded), abilita le estensioni PHP (es. mbstring, intl). |
| Error establishing a database connection | Credenziali DB errate, MySQL down, permessi utente | Verifica DB_NAME/USER/PASSWORD/HOST in wp-config.php, prova wp db check e wp db optimize, e chiedi all’hosting se il DB ha problemi o rate limit. |
| cURL error 28: Connection timed out | Timeout su chiamate esterne (API, WP.org), DNS/firewall | Aumenta il timeout della richiesta, verifica DNS e firewall, controlla eventuali blocchi IPv6/IPv4 dell’hosting. |
| Permission denied | Permessi o ownership sbagliati | Cartelle 755, file 644, wp-config.php 640. Riallinea l’ownership lato hosting. |
| REST API not working / 401/403/404 | Rewrite, sicurezza, cookie/sessione | Rigenera i permalink, consenti l’endpoint nel WAF, escludilo dal caching, controlla il nonce. |
| Mixed content | Asset in http su un sito https | Forza l’https (URL del sito), fai un search-replace nel DB, controlla CDN e regole di riscrittura. |
Comandi utili (WP-CLI e server)
|
1 2 3 4 5 6 7 8 9 10 |
# WP-CLI: diagnostica rapida wp plugin deactivate --all wp theme activate twentytwentyfive wp cache flush wp rewrite flush --hard wp db check # Server: log in tempo reale tail -f wp-content/debug.log tail -f /var/log/apache2/error.log # o il log di Nginx |
Finito il debug: chiudi i rubinetti
Una volta risolto, in produzione rimetti tutto a posto. Lasciare il debug attivo è un rischio (espone dati) e il debug.log cresce all’infinito.
|
1 2 3 |
define('WP_DEBUG', false); define('WP_DEBUG_LOG', false); define('WP_DEBUG_DISPLAY', false); |
- Ruota o cancella
wp-content/debug.log: non lasciarlo gonfiare. - Se usi un plugin di cache, svuota la cache e ritesta.
FAQ
Non vedo debug.log: perché?
Di solito è la cartella non scrivibile, le costanti messe nel punto sbagliato, o l’opcache che non ha ricaricato. Metti le costanti in alto nel wp-config.php e verifica i permessi di wp-content/.
Meglio mostrare gli errori a schermo?
No, non in produzione: tieni WP_DEBUG_DISPLAY su false. Gli errori a schermo possono esporre percorsi e dati sensibili a chiunque passi sul sito.
Il log è pieno di notice e warning: li ignoro?
I notice spesso non bloccano il sito, ma segnalano codice obsoleto. Non ignorarli del tutto: pianifica la correzione, perché un aggiornamento futuro può trasformarli in errori veri.
Manutenzione WordPress e WooCommerce: piani e cosa includono davvero
Sito WordPress hackerato con redirect: come ripulire (guida operativa)
