Dove si trova

Vai su Impostazioni > Cisilino Site Defense Network (punto 1 dell’immagine) e apri la scheda Log di debug (punto 2). Le sezioni sono tre:

• punto 3: “Log di debug del sito”, con stato e accensione.
• punto 4: “File raccolti”.
• punto 5: “Ultime voci”.

A cosa serve il log di debug WordPress

Ti torna utile quando il sito mostra una pagina bianca o un errore critico, quando qualcosa si rompe dopo un aggiornamento, o quando il tuo hosting non ti lascia modificare wp-config.php né leggere i log. Le costanti WP_DEBUG e WP_DEBUG_LOG si definiscono prima del caricamento dei plugin, quindi un plugin non può accenderle. Questo log usa un gestore di errori PHP agganciato al caricamento del plugin.

Questo log si aggiunge, non sostituisce niente. Gli errori continuano ad arrivare anche dove arrivavano prima, cioè in debug.log e nel log del server. Non invia nulla al pannello.

Come si usa

1. Apri la scheda Log di debug.
2. Scegli Resta acceso per: 1 ora, 24 ore (predefinito) o 7 giorni.
3. Scegli Dimensione massima per file.
4. Premi Accendi il log di debug. Leggi “Log di debug acceso. Si spegne da solo allo scadere del tempo scelto; i file restano.”.
5. Riproduci il problema sul sito.
6. Torna alla scheda. Leggi “Ultime voci” oppure scarica il file dalla sezione “File raccolti”.
7. Quando hai finito premi Spegni il log di debug, oppure aspetta la scadenza. Vedrai “Log di debug spento. I file raccolti sono ancora qui sotto.”.

Lo “Stato:” ti dice se il log è “acceso, si spegne il gg/mm/aaaa hh:mm”, “spento (scaduto il …)” oppure “spento”. A log acceso puoi cambiare la dimensione con Salva dimensione.

File raccolti

La tabella elenca nome, dimensione e i pulsanti Scarica ed Elimina. Sotto trovi Elimina tutti i file. Prima di cancellare il plugin chiede conferma: “Eliminare questo file? L’operazione non si può annullare.”. Per Elimina tutti i file il testo è “Eliminare tutti i file del log di debug? L’operazione non si può annullare.”. Se non c’è nulla leggi “Nessun file: il log non è mai stato acceso o non ha ancora registrato nulla.”.

Ultime voci

Il riquadro mostra le 200 voci più recenti, dalla più nuova. Il menu Tutti i livelli ti permette di filtrare per Fatal error, Parse error, Recoverable error, Warning, Notice o Deprecated. Poi premi Filtra. Per tutto il resto scarica i file. Se il filtro non trova nulla leggi “Nessuna voce con questo filtro.”.

Una voce ha questa forma:

[2026-10-29 10:15:03 UTC] Warning: messaggio in /percorso/file.php:12 | GET /pagina

• L’orario è in UTC, diverso dall’ora del sito che vedi nel Registro attività.
• Dopo la barra verticale trovi metodo e percorso della richiesta, senza query string. Da riga di comando o cron vedi “cli/cron”.
• Un messaggio su più righe, come uno stack trace, resta una sola voce con le righe successive rientrate.
• Le righe “Info: log di debug attivato (utente N)” e “Info: log di debug disattivato (utente N)” non hanno un livello: con un filtro non compaiono.

Valori predefiniti e limiti

• Durata del log di debug WordPress: 1 ora, 24 ore o 7 giorni. Un altro valore diventa 24 ore.
• Dimensione per file: 1, 5, 10, 25 o 50 MB. Il predefinito è 5 MB. La dimensione scelta si salva quando premi Accendi il log di debug o Salva dimensione. Attenzione: Spegni il log di debug riporta la dimensione a 5 MB, perché quel modulo non contiene il menu della dimensione.
• Tetto complessivo: 200 MB, sommando file .log e .zip.
• Ogni messaggio è troncato a 4000 caratteri.
• Registra solo errori PHP: non query lente, errori JavaScript o richieste HTTP.

Esempi

• Errore critico dopo l’aggiornamento di un plugin: accendi per 1 ora, ricarica la pagina, filtra “Fatal error”. La voce indica file e riga, per esempio /…/plugins/xyz/file.php:210 | GET /negozio/.
• Avvisi sporadici: 24 ore, filtro Warning o Deprecated. Se il file è stato ruotato, scarica lo zip.
• Sito lento senza una causa chiara: 7 giorni con file da 25 MB, poi cerca Notice e Warning che si ripetono.

Tieni acceso il minimo necessario: spesso basta 1 ora.

Attenzione: i file del log di debug contengono percorsi del server e frammenti di dati. Non condividerli in pubblico. Restano sul disco anche dopo lo spegnimento e dopo la disinstallazione del plugin, che cancella le opzioni ma non i file. Eliminali tu quando hai finito. Il tetto complessivo è di 200 MB.

Attenzione: su server nginx l’accensione può essere rifiutata finché il server non blocca la cartella csdn-debug-*. Il messaggio è “Log di debug non acceso: i file della sua cartella risultano raggiungibili da internet (probabile server senza supporto a .htaccess, come nginx). I log possono contenere percorsi e dati: blocca l’accesso alla cartella csdn-debug-* nella configurazione del server e riprova.”. Se non gestisci il server, chiedi a chi lo gestisce.

Attenzione: il log non vede gli errori soppressi con @ né quelli generati prima del caricamento del plugin. Per esempio non vede gli errori di wp-config.php. Il log di debug WordPress del plugin non sostituisce i log del server.

Cosa succede dietro le quinte

Il log di debug WordPress salva i file in una cartella wp-content/uploads/csdn-debug- seguita da 16 caratteri casuali. Dentro ci sono un index.php, un .htaccess che nega l’accesso e il file in uso csdn-debug.log. All’accensione il plugin scrive un file di prova e prova a leggerlo via HTTP. Se risponde, rifiuta di accendere il log.

Quando il file in uso supera la dimensione scelta viene chiuso, compresso in .zip e ne parte uno nuovo. Nessuna voce va persa. Il .log originale si cancella solo dopo aver verificato lo zip. Se la compressione non riesce, il .log resta. Le voci di “Ultime voci” vengono lette solo dal file in uso, quindi dopo una rotazione quelle vecchie sono negli zip.

Prima di ruotare il plugin controlla il tetto di 200 MB. Se è raggiunto, il log si ferma per non sovrascrivere nulla. Compare l’avviso giallo: “Il log si è fermato perché i file hanno raggiunto il tetto di spazio (200 MB): per non sovrascrivere i dati non scrive più. Scarica o elimina i file, poi riaccendilo.”. Per ripartire elimina i file e riaccendi.

Alla scadenza il log si spegne da solo, ma i file restano. Il plugin non li tronca e non li cancella mai: lo fai solo tu con Elimina o Elimina tutti i file. Per gli errori fatali la voce viene scritta a fine richiesta.

Se il log di debug WordPress non funziona

• “Log di debug non acceso: la cartella dei caricamenti non è scrivibile.”: controlla i permessi della cartella wp-content/uploads.
• Il log non scrive: se la scrittura fallisce, il plugin lo segnala con una voce “Log di debug del sito: …” negli “Ultimi tentativi” della scheda Registro attività.
• Il log è fermo per il tetto: scarica ciò che ti serve, elimina i file e riaccendi.

La guida generale al manuale spiega dove si colloca questa scheda. Per capire meglio le costanti di WordPress guarda la guida ufficiale al debug di WordPress: spiega WP_DEBUG e WP_DEBUG_LOG, che questo plugin non può sostituire.

Capitolo precedente: Registro attività. Capitolo successivo: Risoluzione dei problemi e domande frequenti.

The post Log di debug: gli errori PHP in un file proprio first appeared on Matteo Cisilino.