Nachlese zum WordPress Meetup #110 – Debugging

Beim November-Meetup fiel leider unser geplanter Speaker Jan Wittler krankheitsbedingt aus und Torsten hat ad hoc seinen Talk vom WordCamp Stuttgart aus dem Jahr 2019 nochmal genutzt und das Health-Check-Plugin vorgestellt.

Hier die Slides vom Abend:

Click here to display content from Speaker Deck.
Erfahre mehr in der Datenschutzerklärung von Speaker Deck.

Das Plugin ist in der „Featured“-Liste bei den Plugins oder hier als Direktlink zu finden:
https://de.wordpress.org/plugins/health-check/

Die Slides sind von 2019. Das Plugin hat sich inzwischen deutlich weiter entwickelt und bietet sowohl für die Komponente im Core als auch für das Plugin inzwischen noch deutlich mehr als in den Slides erwähnt wird. Hier sind die Änderungen nachzulesen (inkl. Code für Erweiterung und Anpassung, die in den Slides gezeigt wird):
https://make.wordpress.org/core/2019/04/25/site-health-check-in-5-2/
https://make.wordpress.org/core/2019/09/25/whats-new-in-site-health-for-wordpress-5-3/
https://make.wordpress.org/core/2020/11/15/site-health-check-changes-in-5-6/
https://make.wordpress.org/core/2021/06/22/extending-the-site-health-interface-in-wordpress-5-8/
https://make.wordpress.org/core/2022/10/06/new-cache-site-health-checks-in-wordpress-6-1/

Um Fehler in eine Log-Datei zu speichern, muss das standardmäßige define( 'WP_DEBUG', true ); in der wp-config.php auskommentiert werden. Danach werden folgende drei Zeilen benutzt, um das Logging zu aktivieren, bei gleichzeitig deaktivierter Ausgabe der Fehlermeldungen auf dem Bildschirm. Die Log-Datei debug.log findet sich dann im /wp-content-Ordner.

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

Diese Datei sollte entweder gegen öffentlichen Zugriff gesichert werden oder man löscht sie zeitnah, nachdem das Debugging abgeschlossen ist.

Wenn ein Fehler auftritt, dann kann der „Fatal Error Handler“ von WordPress (ab Version 5.2) die Ausgabe unterbinden. Ohne Zugriff auf die Mail ist dann ein Debugging schwer. Der „Fatal Error Handler“ kann jedoch einfach in der wp-config.php über eine Konstante deaktiviert werden:
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

Mehr zum „Fatal Error Handler“:
https://make.wordpress.org/core/2019/04/16/fatal-error-recovery-mode-in-5-2/

Noch ein kleiner, kaum bekannter Tipp: Um die Home/URL-Einstellungen einer Installation einzusehen, reicht es hinter die Domain /wp-json zu hängen:
https://www.wpmeetup-hamburg.de/wp-json/

Deutlicher tiefere Einblicke in alles mögliche (Datenbankzugriffe, geladene Sprachen, geladene Skripte/Styles, etc.) gibt der Query Monitor von John Blackbourn:
https://de.wordpress.org/plugins/query-monitor/

Ebenfalls von John Blackbourn stammt diese Sammlung von allen Stellen im WordPress-Core an denen Mails versendet werden und wie sie gefiltert werden können:
https://github.com/johnbillion/wp_mail

Wie ein einzelnes, kleines Detail beim Debugging manchmal helfen kann, die Lösung zu finden, zeigt dieser Artikel:
https://torstenlandsiedel.de/2022/11/04/fatal-error-durch-meinen-normalizer-code/

Zum Ende wurde noch ein Exemplar von „Einstieg in WordPress 6“ von Peter Müller verlost, was Torsten als Rezensionsexemplar bekommen hatte. Wer nach einer guten Einführung in WordPress 6 sucht, findet hier mehr Infos zum Buch:
https://einstieg-in-wp.de/

Teile diesen Beitrag in den Netzwerken

Schreibe einen Kommentar