Quando WordPress mostra un errore critico, un HTTP 500, una pagina bianca o un altro problema tecnico, il messaggio di errore visibile spesso non è sufficiente per identificare la causa effettiva.
WordPress e PHP possono quindi registrare informazioni dettagliate sugli errori. Questi log mostrano, ad esempio, quale tipo di errore si è verificato, in quale momento è sorto l'errore e quale file PHP è stato coinvolto.
WordPress dispone di un proprio sistema di debug con impostazioni come WP_DEBUG, WP_DEBUG_LOG e WP_DEBUG_DISPLAY. Inoltre, i log degli errori PHP sul lato server possono contenere informazioni importanti.
Il debugging, tuttavia, non significa mostrare pubblicamente il maggior numero possibile di messaggi di errore sul sito web. Su un sito web di produzione, i dettagli tecnici dovrebbero essere registrati il più possibile e successivamente analizzati in modo mirato.
Breve spiegazione: Attiva il debug solo in modo mirato per la ricerca degli errori. Su un sito web di produzione, i messaggi di errore di solito non dovrebbero essere mostrati pubblicamente. Utilizza invece un registro degli errori, riproduci l'errore, annota l'ora e successivamente esamina i log corrispondenti.
Cosa significa il debug in WordPress? #
Il termine debugging indica la ricerca sistematica di errori in un software o in un sito web.
In WordPress geht es beispielsweise darum herauszufinden, warum eine bestimmte Anfrage fehlschlägt, ein Plugin einen Fehler verursacht oder PHP die Verarbeitung einer Seite abbricht.
Invece di limitarsi a provare diverse impostazioni, il debugging fornisce informazioni tecniche sul reale svolgimento.
Ciò consente spesso di trasformare un sospetto in una diagnosi concreta.
Quando è utile il debug di WordPress? #
Il debugging è particolarmente utile quando un problema si verifica in modo riproducibile, ma il messaggio di errore visibile non fornisce una spiegazione sufficiente.
Ciò riguarda, ad esempio, errori critici di WordPress, errori HTTP 500, problemi dopo l'aggiornamento di un plugin o di un tema, errori dopo un cambio di versione di PHP o funzionalità che improvvisamente smettono di funzionare correttamente.
Anche in caso di comportamento anomalo di un plugin, un registro può fornire indizi, anche se il sito web in linea di massima continua a essere accessibile.
Il debug non è la stessa cosa che riparare #
Un registro degli errori non risolve automaticamente il problema.
Il debugging aiuta innanzitutto a identificarne la causa.
Se ad esempio un log mostra che si verifica un errore fatale di PHP all'interno di un determinato plugin, bisogna successivamente verificare perché questo errore si genera e quale soluzione sia adatta.
La forza del debugging risiede pertanto non in una riparazione automatica, ma in una diagnosi notevolmente più precisa.
Creare un backup prima delle modifiche #
Prima di modificare file di configurazione come wp-config.php dovrebbe essere presente un backup recente.
Un piccolo errore di sintassi in un file di configurazione PHP può fare in modo che WordPress non venga più caricato correttamente.
Per i siti web complessi o critici per il business, un ambiente di staging è fondamentalmente preferibile per estese attività di debugging.
Il file wp-config.php #
Le impostazioni di debug di WordPress più importanti si trovano solitamente in:
wp-config.php
definito.
Questo file si trova solitamente nella directory principale dell'installazione di WordPress o un livello sopra, a seconda di come è stata configurata l'installazione.
Contiene le impostazioni centrali dell'installazione di WordPress e pertanto dovrebbe essere modificata solo con cautela.
WP_DEBUG #
La costante centrale di WordPress per la modalità di debug si chiama:
WP_DEBUG
In un'installazione WordPress di produzione normale, il debug è solitamente disattivato:
define( 'WP_DEBUG', false );
Per una diagnosi mirata può essere attivato:
define( 'WP_DEBUG', true );
Con attivato WP_DEBUG WordPress aumenta la memorizzazione degli errori PHP e genera inoltre avvisi specifici di WordPress, ad esempio relativi a funzioni obsolete.
non mettere true e false tra virgolette #
Tra le costanti di debug ci sono vero e falso valori booleani.
Corretto è, ad esempio:
define( 'WP_DEBUG', false );
Non dovrebbe essere usato:
define( 'WP_DEBUG', 'false' );
La seconda variante contiene una stringa anziché un valore booleano e può quindi portare a un risultato inatteso.
Importante: Per le costanti di WordPress, il tipo di dati dovrebbe essere acquisito correttamente.
falsoe'falso'non sono la stessa cosa in PHP.
WP_DEBUG_LOG #
Con
WP_DEBUG_LOG
WordPress può scrivere i messaggi di debug in un file.
Una configurazione tipica è:
define( 'WP_DEBUG_LOG', true );
Se WP_DEBUG_LOG su vero impostato e WP_DEBUG è attivo, WordPress utilizza per impostazione predefinita:
wp-content/debug.log
come file di log di debug.
WP_DEBUG_LOG richiede WP_DEBUG #
Una connessione importante viene spesso trascurata:
WP_DEBUG_LOG
lavora all'interno del sistema di debug di WordPress insieme a:
WP_DEBUG
Se WP_DEBUG non è attivato, il solo fatto di impostare WP_DEBUG_LOG non il debug logging di WordPress previsto.
Percorso personalizzato per WP_DEBUG_LOG #
WordPress può essere utilizzato per WP_DEBUG_LOG utilizzare anche un percorso di file valido.
Ciò può essere utile se il registro degli errori non deve essere salvato direttamente all'interno della directory del sito web pubblicamente accessibile.
Quali percorsi siano sensibili e scrivibili in un particolare ambiente di hosting dipende dalla configurazione del server.
WP_DEBUG_DISPLAY #
La costante:
WP_DEBUG_DISPLAY
determina se i messaggi di debug debbano essere visualizzati all'interno del sito web.
Per un sito web di produzione, durante una diagnosi è spesso più sensata la seguente combinazione rispetto a un output pubblico degli errori:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Questo consente a WordPress di registrare gli errori senza mostrarli intenzionalmente ai visitatori del sito web.
Attenzione: I messaggi di errore dettagliati possono contenere percorsi di file, configurazioni tecniche e altre informazioni interne. Non dovrebbero essere visualizzati pubblicamente in modo permanente su un sito web di produzione.
considerare anche display_errors #
L'effettiva emissione di errori PHP può essere ulteriormente influenzata dalla configurazione di PHP.
Per una configurazione di diagnosi si può quindi utilizzare in aggiunta:
@ini_set( 'display_errors', 0 );
Una possibile combinazione è quindi:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Il fatto che le impostazioni PHP possano essere modificate o meno a runtime dipende tuttavia dalla configurazione del server.
Dove va inserito il codice di debug in wp-config.php? #
Le costanti di debug devono essere definite prima che WordPress venga caricato completamente.
In un tipico wp-config.php si trovano quindi di fronte alla nota riga finale o prima wp-settings.php viene integrato.
Se una definizione come:
define( 'WP_DEBUG', false );
Se è già presente, non dovresti crearne una seconda definizione contraddittoria in un altro punto.
Trova il file debug.log #
Nella configurazione predefinita, il file di debug di WordPress si trova in:
wp-content/debug.log
Ad esempio, è possibile accedervi tramite il file manager dell'hosting o un apposito accesso per il trasferimento dei file.
Il file non deve necessariamente esistere già. Verrà creato o scritto quando sarà possibile registrare i relativi messaggi.
Se non viene creato alcun file debug.log #
Se, nonostante il debug sia attivato, non compare alcun file, dovresti prima verificare se sia stato effettivamente generato un errore registrabile e se le costanti di debug siano impostate correttamente.
Inoltre, i permessi dei file, il percorso di log configurato e la configurazione dell'hosting o di PHP possono giocare un ruolo importante.
Un mancante debug.log non dimostra quindi automaticamente che WordPress funzioni senza errori.
Riprodurre l'errore in modo mirato #
Uno dei metodi più efficaci nell'analisi dei log è la riproduzione controllata del problema.
Se ad esempio il clic su „Aggiorna“ in una determinata pagina provoca un errore, apri prima il registro oppure prendi nota del suo stato attuale. Esegui quindi esattamente questa azione di nuovo.
Successivamente esamini le voci appena aggiunte.
In questo modo riduci il rischio di confondere un vecchio errore, non più rilevante da tempo, con il problema attuale.
I timestamp sono fondamentali #
Su un sito web attivo da tempo, un registro degli errori può contenere voci provenienti da molte situazioni diverse.
Un errore irreversibile di ieri potrebbe non avere nulla a che fare con il problema che si verifica oggi.
Annota quindi con la maggiore precisione possibile il momento in cui hai riprodotto l'errore e confrontalo con i timestamp nel registro.
Consiglio pratico: Riproduci un errore in modo controllato e annota l'ora. In questo modo è possibile distinguere molto più velocemente i log rilevanti dal vecchio rumore di protocollo.
Come si legge un errore PHP? #
Un errore PHP contiene spesso diversi componenti utili.
Particolarmente rilevanti sono il tipo di errore, il messaggio di errore, il percorso del file, il numero di riga e il timestamp.
Un esempio semplificato potrebbe apparire più o meno così:
PHP Fatal error: Uncaught Error ... in /wp-content/plugins/beispiel-plugin/datei.php on line 123
In questo modo sai già che PHP ha interrotto l'esecuzione a causa di un errore fatale e in quale area di codice l'errore è diventato visibile.
Errore fatale PHP #
Uno:
Errore fatale PHP
è un errore grave che impedisce a PHP di continuare l'esecuzione in modo normale.
Tali errori possono essere causati, ad esempio, da codice incompatibile, funzioni o classi mancanti, problemi di memoria e altri gravi bug di programmazione.
Un errore irreversibile è quindi particolarmente rilevante in caso di errore HTTP 500 o di pagina bianca.
Errore non intercettato e TypeError #
Messaggi come:
Errore non gestito
o:
Errore di tipo
indicano errori durante l'esecuzione di PHP.
Uno Errore di tipo può verificarsi, ad esempio, quando il codice passa un valore di un tipo non idoneo a una funzione.
Tali errori si verificano frequentemente in caso di incompatibilità o di plugin, temi o codice personalizzato difettosi.
Chiamata a funzione non definita #
Un messaggio come:
Chiamata a funzione non definita
significa che PHP ha tentato di chiamare una funzione che non è disponibile in questo contesto di esecuzione.
Le possibili cause includono codice incompatibile, una dipendenza mancante o un'estensione PHP non disponibile.
Il percorso del file e il nome della funzione forniscono importanti indizi per la diagnosi successiva.
Classe non trovata #
Un messaggio come:
Classe ... non trovata
può indicare che il codice di programma previsto non è stato caricato.
Ciò può essere causato, ad esempio, da file mancanti, dipendenze dei plugin, processi di autoloading errati o versioni incompatibili.
Impossibile rideclare #
Presso:
Impossibile rideclare
ad esempio è stato tentato di ridefinire una funzione già esistente.
Questo può verificarsi in caso di codice caricato due volte o sovrapposto ed è quindi interessante anche in caso di conflitti tra plugin o temi.
Dimensione della memoria consentita esaurita #
Il messaggio:
Dimensione di memoria consentita ... esaurita
indica che PHP ha raggiunto il limite di memoria consentito durante l'esecuzione.
Ciò non significa automaticamente che sia necessario solo un limite più alto. Un plugin o un processo potrebbe anche consumare una quantità insolitamente elevata di memoria.
Trattiamo la diagnosi esatta sotto Limite di memoria PHP in WordPress: individuare e risolvere gli errori.
Errore di analisi e errore di sintassi #
Un errore di sintassi si verifica quando il codice PHP non è strutturato correttamente.
Ciò può verificarsi, ad esempio, dopo una modifica manuale a:
functions.php
o:
wp-config.php
succedere.
Anche una sola parentesi mancante, un carattere errato o un punto e virgola difettoso possono fare in modo che PHP non riesca a interpretare correttamente il file.
Warning non è la stessa cosa di Fatal Error #
Uno:
Avviso PHP
è solitamente meno grave di un errore irreversibile.
PHP può continuare l'esecuzione a seconda della situazione nonostante un avviso.
Gli avvisi dovrebbero comunque essere esaminati, soprattutto se si verificano frequentemente o sono correlati a un malfunzionamento specifico.
Tuttavia, non ogni avviso spiega automaticamente l'errore per cui hai aperto il registro.
interpretare correttamente l'avviso #
Gli avvisi indicano spesso codice problematico o non pulito, senza interrompere immediatamente l'esecuzione.
Quando attivato WP_DEBUG perciò possono risultare visibili molti messaggi, anche se il sito Web a prima vista funziona.
La quantità di segnalazioni non deve indurre a trattare ogni voce come ugualmente critica.
Messaggi di deprecazione #
WordPress e PHP possono generare avvisi su funzioni o procedure obsolete.
Tali segnalazioni contengono spesso termini come:
Deprecato
Un'deprecazione non significa necessariamente che la funzione abbia già smesso di funzionare. Essa indica che il codice in questione è obsoleto e potrebbe diventare problematico nelle versioni future.
Nel caso di plugin o temi, molti nuovi avvisi di deprecazione dopo un cambio di versione sono quindi un indizio per verificare l'attualità e la compatibilità della relativa estensione.
Il numero più alto di segnalazioni non è automaticamente il problema più grande #
Un plugin può generare centinaia di avvisi, mentre un singolo errore fatale di un altro componente fa effettivamente crashare il sito web.
La diagnosi dovrebbe pertanto essere effettuata in base alla rilevanza e non semplicemente in base al messaggio che compare più frequentemente nel registro.
Leggere correttamente i percorsi dei file #
Un percorso di file può fornire un'importante indicazione sulla componente coinvolta.
Un percorso all'interno di:
wp-content/plugins/
porta a un plugin.
Un percorso all'interno di:
wp-content/themes/
porta a un tema o tema figlio.
Un percorso all'interno di:
wp-admin/
o:
wp-includes/
entra nel WordPress Core.
Un percorso del core di WordPress non dimostra un errore del core #
Se un messaggio di errore indica un file in wp-includes menziona, ciò non significa automaticamente che WordPress stesso sia difettoso.
Ad esempio, un plugin potrebbe chiamare una funzione del core di WordPress con dati non validi. L'errore potrebbe quindi diventare visibile all'interno della funzione del core, sebbene la causa reale si trovi al di fuori del core di WordPress.
L'intero contesto dell'errore è quindi più importante del solo ultimo percorso di file.
Capire lo Stack Trace #
In caso di errori gravi, è possibile registrare un cosiddetto stack trace.
Mostra in modo semplificato quali funzioni o metodi sono stati chiamati prima che si verificasse l'errore.
Ciò consente di capire in quale punto si trovava PHP quando l'esecuzione è stata interrotta.
Per gli sviluppatori e il supporto tecnico, un stack trace può quindi essere molto più significativo rispetto alla sola ultima riga di errore.
Indagare su conflitti di plugin o temi tramite i log #
Se un log fa ripetutamente riferimento a un determinato plugin o tema, questo componente rappresenta un punto di partenza utile per ulteriori analisi.
Dovrebbe comunque essere testata in modo controllato e non semplicemente cancellata.
Puoi trovare il nostro metodo di lavoro su Rilevare e risolvere i conflitti di plugin o temi in WordPress.
Errore dopo un cambio di versione di PHP #
Se immediatamente dopo il cambio della versione di PHP si verificano nuovi errori irreversibili (fatal error), type error o messaggi di deprecazione, è necessario verificare la compatibilità dei componenti coinvolti.
Il percorso del file nel registro degli errori può aiutare a identificare un plugin, un tema o uno snippet personalizzato obsoleto.
Spieghiamo di più al riguardo sotto Modificare la versione di PHP per WordPress e verificare la compatibilità.
Il file di debug.log di WordPress e il registro degli errori PHP non sono la stessa cosa #
Questa differenza è importante.
Il file:
wp-content/debug.log
si genera tramite il debug logging di WordPress, se è stato opportunamente attivato.
L'ambiente di hosting o PHP può anche mantenere i propri registri degli errori.
Questi log lato server possono contenere errori che non compaiono, o compaiono solo in parte, nel debug log di WordPress.
Quale log dovrebbe essere controllato per primo? #
Se un registro degli errori PHP o del server è disponibile tramite l'hosting, questo è spesso un ottimo punto di partenza in caso di problemi PHP gravi.
Non richiede un'indicazione pubblica permanente dell'errore e può già contenere l'errore fatale decisivo.
Se non ci sono informazioni sufficienti, un debug mirato di WordPress può fornire ulteriori dettagli.
Diagnosticare HTTP 500 con i log #
In caso di errore HTTP 500, il browser mostra spesso solo un messaggio di errore del server generico.
Il registro degli errori, d'altra parte, può contenere il fatal error PHP sottostante, un errore di memoria o altri problemi lato server.
La procedura completa è disponibile all'indirizzo Risolvere l'errore 500 in WordPress.
Indaga su un errore critico di WordPress #
WordPress può mostrare un messaggio di errore critico in caso di determinati errori PHP fatali e, se necessario, offrire la modalità di recupero.
Anche qui i log possono fornire ulteriori informazioni su quale componente ha generato l'errore.
Spieghiamo i relativi passaggi di ripristino su WordPress mostra una pagina bianca o un errore critico: cosa fare?.
Registra errore AJAX #
Un vantaggio di WP_DEBUG_LOG consiste nel fatto che possono essere registrati errori che non compaiono su una normale pagina visibile.
Ciò è utile, ad esempio, nelle richieste AJAX.
Quando un editor, un modulo o un plugin di WordPress utilizza una richiesta AJAX e questa fallisce sul lato server, un registro può fornire indizi sull'errore PHP.
WP-Cron e processi in background #
Anche gli errori durante le attività pianificate di WordPress possono essere difficili da individuare, perché nessun visitatore vede immediatamente un corrispondente messaggio di errore.
L'logging è quindi utile anche per WP-Cron e altri processi in background.
Se un processo pianificato fallisce ripetutamente, si dovrebbero esaminare i timestamp e i modelli di errore ricorrenti.
Errore API REST #
Le moderne funzionalità e i plugin di WordPress utilizzano spesso la REST API.
Un errore PHP lato server durante una richiesta REST potrebbe non comparire come normale messaggio di errore all'interno di una pagina WordPress visibile.
Anche qui i log possono fornire molte più informazioni rispetto all'interfaccia utente.
Gli errori JavaScript non si trovano necessariamente nel log di PHP #
Il debug di WordPress e i log degli errori PHP si concentrano sulle operazioni lato server.
Se ad esempio un menu, un cursore o un pulsante nel browser non risponde, la causa potrebbe invece essere legata a JavaScript.
Errori di questo tipo vengono spesso analizzati tramite gli strumenti di sviluppo del browser.
Un registro degli errori PHP vuoto, pertanto, non dimostra che non esistano errori tecnici su un sito web.
I problemi CSS di solito non compaiono nemmeno nel log di PHP #
Un elemento visualizzato in modo errato può essere causato dal CSS, anche se il PHP funziona in modo completamente privo di errori.
Se un sito web funziona tecnicamente, ma ad esempio spaziature, colori o layout vengono visualizzati in modo errato, gli strumenti di sviluppo del browser sono spesso lo strumento di diagnostica più adatto.
Errore del database #
Anche i problemi di database possono causare errori tecnici.
Con il debug di WordPress attivato, è possibile visualizzare o registrare informazioni aggiuntive sugli errori del database.
Un errore in una query SQL non dovrebbe tuttavia essere „riparato“ automaticamente tramite modifiche manuali al database. Innanzitutto si dovrebbe determinare quale componente genera la query problematica.
Il debugging può influenzare il sito web stesso #
La registrazione estesa genera ulteriori operazioni sui file.
Se un sito Web produce molti avvisi o note per richiesta, la registrazione attivata può scrivere una grande quantità di dati.
Il debugging dovrebbe quindi essere considerato uno strumento di diagnosi e non come lo stato normale permanentemente attivo di un sito web di produzione.
Un file debug.log può diventare molto grande #
Se lo stesso errore viene registrato più volte a ogni caricamento di pagina, si può:
wp-content/debug.log
crescere rapidamente in breve tempo.
Ciò occupa spazio di archiviazione e rende inoltre più difficile la valutazione.
Dopo una diagnosi, dovresti quindi verificare se il debugging è stato nuovamente disattivato e se un file di log non più necessario può essere rimosso in modo sicuro.
I log possono contenere informazioni sensibili #
I registri degli errori possono contenere percorsi di file interni, configurazioni tecniche, informazioni sulle query e, a seconda dell'applicazione difettosa, ulteriori dati.
Pertanto, non trattare i log come file di testo pubblicamente accessibili.
Quando un registro viene inoltrato al supporto o a uno sviluppatore, dovrebbe essere inviato solo il frammento necessario per la diagnosi e si dovrebbe verificare in anticipo se contiene dati sensibili.
Attenzione: Non pubblicare log di debug completi senza prima averli verificati in forum pubblici, ticket o social network. Controlla prima quali informazioni contengono.
debug.log in directory accessibile al pubblico #
Il percorso predefinito:
wp-content/debug.log
si trova all'interno della struttura delle directory di WordPress.
A seconda della configurazione del server web, un file salvato lì può potenzialmente essere accessibile tramite HTTP. WordPress stesso segnala quindi che i registri degli errori pubblicamente accessibili possono rappresentare un rischio per la sicurezza.
Sullevare i sistemi di produzione richiede pertanto un uso controllato della registrazione degli eventi e che il file di log non venga lasciato inutilmente attivo una volta completata la diagnosi.
Disattivare nuovamente il debug dopo la risoluzione dei problemi #
Dopo il completamento della diagnosi, un sito web di produzione dovrebbe essere riportato a una configurazione normale.
Una configurazione WordPress semplice può ad esempio tornare a:
define( 'WP_DEBUG', false );
usare.
Se sono state aggiunte costanti di debug aggiuntive solo per la diagnostica, si dovrebbe verificare se sono ancora necessarie.
Gestire il registro di debug dopo la diagnosi #
Se il file di log non è più necessario, può essere rimosso dopo aver salvato le informazioni eventualmente rilevanti.
Wird Debug-Logging später erneut aktiviert, kann WordPress beziehungsweise PHP wieder neue Meldungen protokollieren.
Das Entfernen einer alten Logdatei behebt allerdings keine Ursache. Es dient lediglich dazu, nicht mehr benötigte Diagnoseinformationen zu entfernen.
Alte Fehler nicht mit aktuellen Problemen verwechseln #
Eine vorhandene debug.log kann Meldungen enthalten, die Wochen oder Monate alt sind.
Wenn eine Website heute einen Fehler zeigt, sollte deshalb nicht automatisch der auffälligste alte Fatal Error als Ursache angenommen werden.
Der Vergleich mit dem aktuellen Zeitpunkt ist entscheidend.
Wiederkehrende Fehlermuster erkennen #
Wenn derselbe Fehler immer wieder zu bestimmten Zeiten auftritt, kann das auf einen geplanten Prozess hinweisen.
Beispielsweise können Cronjobs, Backups, Imports oder Sicherheits-Scans regelmäßig bestimmte Funktionen ausführen.
Ein zeitliches Muster im Log kann deshalb einen wichtigen Hinweis liefern, auch wenn die Website zwischen diesen Ereignissen normal funktioniert.
Logs vor und nach einer Änderung vergleichen #
Bei einer kontrollierten Diagnose solltest du möglichst nur eine relevante Variable gleichzeitig verändern.
Wenn beispielsweise ein Plugin deaktiviert wird, reproduziere anschließend den Fehler erneut und vergleiche die neuen Logeinträge.
Verschwindet der Fehler, ist das eine wesentlich stärkere Information als eine zufällige Änderung von fünf verschiedenen Einstellungen gleichzeitig.
Debugging bei einer langsamen WordPress-Website #
Ein Error Log ist kein vollständiges Performance-Analysewerkzeug.
Es kann jedoch Hinweise auf Prozesse liefern, die ständig Fehler oder Warnungen erzeugen und dadurch zusätzliche Last verursachen.
Für eine vollständige Performance-Diagnose müssen zusätzlich PHP-Verarbeitung, Datenbank, Plugins, Frontend-Ressourcen und Hosting-Ressourcen betrachtet werden.
Spieghiamo la procedura su WordPress è lento: trovare le cause e migliorare il tempo di caricamento.
Query Monitor und ähnliche Diagnosewerkzeuge #
Für weitergehende Analysen existieren WordPress-Plugins, die zusätzliche technische Informationen darstellen können.
Ein bekanntes Werkzeug ist beispielsweise Query Monitor. Damit können unter anderem Datenbankabfragen, PHP-Fehler, Hooks, HTTP-API-Aufrufe und weitere Informationen während einer Anfrage untersucht werden.
Solche Werkzeuge richten sich vor allem an Entwickler und technisch erfahrene Benutzer.
Sie sollten nicht dauerhaft nur deshalb installiert und aktiviert bleiben, weil eine Website irgendwann einmal einen Fehler hatte.
SCRIPT_DEBUG ist nicht dasselbe wie WP_DEBUG #
WordPress kennt zusätzlich:
SCRIPT_DEBUG
Diese Konstante ist nicht mit WP_DEBUG equiparare.
Sie wird insbesondere bei der Entwicklung und Diagnose von WordPress-Core-JavaScript- beziehungsweise CSS-Dateien verwendet und ist für eine normale PHP-Fehlersuche in der Regel nicht erforderlich.
SAVEQUERIES nur gezielt verwenden #
Für Datenbankdiagnosen existiert außerdem:
SAVEQUERIES
Damit können Informationen zu Datenbankabfragen gesammelt werden.
Diese Funktion erzeugt zusätzlichen Speicher- und Performance-Aufwand und sollte deshalb nur gezielt zur Diagnose eingesetzt werden.
Für normale WordPress-Benutzer ist sie bei einer üblichen Fehlersuche normalerweise nicht der erste Schritt.
Debugging auf Staging und Produktion unterscheiden #
Auf einer Entwicklungs- oder Staging-Umgebung können ausführliche Diagnoseinformationen sinnvoll sein, weil dort keine normalen Besucher betroffen sind.
Auf einer produktiven Website muss dagegen stärker darauf geachtet werden, dass technische Informationen nicht öffentlich ausgegeben werden und das Logging nur so lange wie nötig aktiv bleibt.
Die gleiche Debug-Konfiguration ist deshalb nicht automatisch für jede Umgebung geeignet.
Was du beim Debugging besser nicht tun solltest #
Aktiviere nicht einfach die öffentliche Ausgabe sämtlicher PHP-Fehler auf einer produktiven Website und lasse diese Einstellung anschließend dauerhaft bestehen.
Ändere außerdem nicht gleichzeitig mehrere Plugins, das Theme, PHP und die WordPress-Konfiguration. Dadurch wird schwer nachvollziehbar, welche Änderung den Fehler tatsächlich beeinflusst hat.
Lösche nicht sofort eine Komponente nur deshalb, weil ihr Dateipfad in einem Log erscheint. Prüfe zunächst den Zusammenhang und reproduziere den Fehler kontrolliert.
Und sende vollständige Logdateien nicht ungeprüft an beliebige Dritte.
Regola fondamentale: Fehler reproduzieren, Zeitpunkt notieren, relevante Logeinträge identifizieren und erst danach eine gezielte Änderung vornehmen. Anschließend denselben Fehler erneut testen. So wird aus Ausprobieren eine nachvollziehbare technische Diagnose.
Quali informazioni aiutano il supporto di CURIAWEB? #
Wenn du CURIAWEB wegen eines WordPress-Fehlers kontaktierst, beschreibe zunächst, welche Aktion den Fehler auslöst und wann er zuletzt aufgetreten ist.
Ein relevanter Logausschnitt mit Zeitstempel ist wesentlich hilfreicher als eine vollständige Datei mit tausenden älteren Meldungen.
Wenn ein Fatal Error vorhanden ist, sollte die vollständige zugehörige Fehlermeldung einschließlich Dateipfad und gegebenenfalls Stack Trace übermittelt werden.
Teile außerdem mit, ob unmittelbar zuvor WordPress, ein Plugin, das Theme, PHP oder individueller Code verändert wurde.
Entferne beziehungsweise schwärze sensible Informationen, falls sie für die Diagnose nicht benötigt werden. Passwörter solltest du niemals unaufgefordert in einem Fehlerprotokoll oder Support-Ticket mitsenden.
Riepilogo #
WordPress Debugging und Fehlerprotokolle gehören zu den wichtigsten Werkzeugen für eine systematische technische Fehlersuche. Statt lediglich aufgrund einer sichtbaren Fehlermeldung zu raten, können Logs zeigen, welcher Fehler tatsächlich aufgetreten ist, wann er entstand und welcher Codebereich beteiligt war.
Die zentrale Einstellung WP_DEBUG aktiviert den WordPress-Debug-Modus. Mit WP_DEBUG_LOG können Meldungen protokolliert werden, während WP_DEBUG_DISPLAY steuert, ob diese Informationen auf der Website angezeigt werden.
Auf einer produktiven Website ist es normalerweise sinnvoller, Fehler kontrolliert zu protokollieren, statt technische Details öffentlich auszugeben. Die standardmäßige WordPress-Debugdatei wp-content/debug.log sollte außerdem als potenziell sensible Datei behandelt werden.
Bei der Auswertung sind Fehlertyp, Zeitstempel, Dateipfad und gegebenenfalls Stack Trace besonders wichtig. Ein Dateipfad liefert einen Hinweis, beweist aber nicht immer allein, welche Komponente die eigentliche Ursache ist.
Nach Abschluss der Diagnose sollte Debugging auf einer produktiven Website wieder passend deaktiviert und eine nicht mehr benötigte Logdatei entfernt beziehungsweise sicher behandelt werden.
Die wichtigste Methode bleibt dabei einfach: Fehler reproduzieren, Log prüfen, Ursache eingrenzen, eine gezielte Änderung durchführen und anschließend erneut testen.
