Während wir uns weiterhin damit befassen, was es bedeutet, ein unabhängiger WordPress-Entwickler zu sein, die erforderlichen Tools und die verschiedenen Strategien, die unsere Fähigkeiten verbessern können, habe ich die verschiedenen Konstanten, Plugins und Tools besprochen, die uns helfen.

Wenn Sie gerade über diesen Beitrag stolpern, empfehle ich Ihnen, sich meinen Leitfaden zu nativen WordPress-Debugging-Tools sowie die restlichen Beiträge der bisherigen Serie anzusehen.

Schließlich finde ich es wichtig, dass wir beim Durchgehen dieser Informationen alle auf der gleichen Grundlage – oder etwas eng Verwandtem – arbeiten.

Letztendlich ist der Einsatz eines Tools wie Xdebug unabdingbar, aber daran müssen wir uns heranarbeiten (für Neugierige habe ich vor etwas mehr als einem Jahr eine kleine Anleitung dazu geschrieben).

Fangen wir aber erstmal mit den Basics an. Im vorherigen Post bin ich mit folgender Aussage gegangen:

Im nächsten Beitrag beginnen wir mit der Untersuchung dessen, was notwendig ist, um das von WordPress generierte Fehlerprotokoll zu untersuchen und wie die angezeigten Informationen zu verstehen sind.

Und das möchte ich mir heute ansehen, weil es Ihnen nicht zuletzt etwas Praktisches gibt, mit dem Sie arbeiten können.

WordPress-Fehlerprotokolle verstehen, Teil 1

Bevor ich zu weit darauf eingehe, möchte ich eine Frage ansprechen, die von einem Mitglied der Seite gestellt wurde.

Ich wurde nämlich gefragt:

Wann werden wir uns mit objektorientierten Prinzipien befassen?

Obwohl ich in einer früheren Serie ein wenig darüber berichtet habe, arbeite ich daran, später in dieser Serie ausführlicher darauf einzugehen.

Nachdem dies gesagt ist, fangen wir jedoch an, uns die Fehlerprotokolle anzusehen.

Konfigurieren Ihrer Konstanten

Wenn du die Konstanten in deiner wp-config.php- Datei noch nicht konfiguriert hast, empfehle ich, dies jetzt zu tun, da dir dies die größtmögliche Genauigkeit bei der Untersuchung eventuell auftretender Probleme bietet.

Wenn Sie nicht aufgeholt haben, lesen Sie unbedingt diesen Beitrag (und wenn ja, stellen Sie sicher, dass die folgenden Konstanten in Ihrer Konfigurationsdatei definiert sind):

Sobald diese vorhanden sind, haben Sie alles, was Sie brauchen, um nicht nur Informationen auf dem Bildschirm zu sehen, sondern auch im Debug-Protokoll, das WordPress generiert.

Wo ist das Protokoll?

Je nach Art Ihrer Umgebung kann dies variieren; In den meisten Fällen finden Sie jedoch debug.log im wp-content- Verzeichnis, das sich über den Verzeichnissen plugins, themes und uploads befindet .

Wie Sie in der Vorschau des obigen Screenshots sehen können, enthält meine Debug-Datei eine Menge Inhalt. Wir werden uns das im nächsten Abschnitt genauer ansehen und erklären, wie man es versteht. Überprüfen Sie in der Zwischenzeit jedoch, ob diese Datei überhaupt existiert. Wenn dies der Fall ist, können Sie den Inhalt der Datei durchgehen. Sie können viel von dem verstehen oder auch nicht, aber der Inhalt in der Datei bedeutet, dass etwas in einem Design oder Plugin verschiedene PHP-Warnungen, Hinweise und Fehler auslöst, die WordPress abfängt und in die Protokolldatei schreibt.

Was bedeutet die Protokolldatei überhaupt?

Das bedeutet nicht unbedingt, dass etwas kaputt ist, aber es weist darauf hin, dass etwas nicht so funktioniert, wie es sollte, auf programmatischer Ebene nicht richtig erfasst und behandelt wird oder einfach etwas tut, was es nicht tun sollte.

So muss es nicht aussehen (kann aber!).

Als Entwickler sollten wir uns bemühen sicherzustellen, dass unser Code nichts generiert, was in das Fehlerprotokoll geschrieben würde.

Es ist eine Sache, dies in der Entwicklung zu tun, da wir Einblicke in das gewinnen können, was wir tun und wie WordPress funktioniert. Es ist jedoch eine andere Sache, wenn etwas, das wir auf Produktionsebene veröffentlichen, solche Dinge hervorbringt.

Lesen des Fehlerprotokolls

Offensichtlich gehört mehr dazu, das Fehlerprotokoll zu lesen, als es nur zu öffnen. Für viele ist der erste Eindruck, dass es ein Haufen Fachjargon sein kann. Das verstehe ich auch. Aber wenn Sie verstehen, was es Ihnen zeigt, ist es viel einfacher zu verstehen.

Schauen wir uns also ein wirklich einfaches Beispiel an. Dies ist auch kein erfundenes Beispiel. Tatsächlich ist dies eines, das von einem Plugin stammt, an dem ich gearbeitet habe. Das Fehlerprotokoll enthält die folgenden Informationen :

[05-Jul-2018 19:43:53 UTC] PHP Fatal error:  Uncaught Error: Class 'EasyEmailExportAdminEmailExportSubmenu' not found in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php:37
#8 /U in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 37
[05-Jul-2018 19:44:03 UTC] PHP Warning:  include_once(./src/Admin/EmailExportSubmenu.php): failed to open stream: No such file or directory in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25
[05-Jul-2018 19:44:03 UTC] PHP Warning:  include_once(): Failed opening './src/Admin/EmailExportSubmenu.php' for inclusion (include_path='.:/usr/local/Cellar/php/7.2.5/share/php/pear') in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Beachten Sie, dass es im obigen Kern drei Zeilen gibt. Die beste Vorgehensweise beim Lesen von Fehlerprotokollen ist, unten anzufangen und sich nach oben zu arbeiten. Dies liegt daran, dass Dinge, wenn sie in Ausführung ausgeführt werden, auf einem Stack arbeiten.

Ein kurzer Exkurs über Stacks

Ich werde nicht auf die Informatikdefinition des Begriffs eingehen, aber der Code wird so ausgeführt und funktioniert so, dass Funktionen auftreten und sich im Gedächtnis eines Computers buchstäblich übereinander stapeln.

Daher befindet sich das Neueste, das ausgeführt werden soll, immer oben, wo die Wurzel des Ausgangspunkts unten ist. Da wir Code für eine bereits vorhandene Anwendung schreiben, ist das WordPress; dann ist unser Code wahrscheinlich immer ganz oben.

WordPress-Fehlerprotokolle verstehen: Es ist nicht diese Art von Stack

Die Idee ist, dass der Code in WordPress ausgeführt wird und sich bis zu der Arbeit vorarbeitet, die wir erledigen. Wenn es einen Hinweis, eine Warnung oder einen Fehler gibt, wird es normalerweise etwas in unserem Code sein (obwohl WordPress nicht ausgenommen ist, ist das im Allgemeinen der Fall).

Wenn Sie also das Fehlerprotokoll durchlesen, lesen Sie im Wesentlichen einen sogenannten Stack-Trace durch. Wikipedia hat, wie verlinkt, eine ziemlich ausführliche Definition zu diesem Thema, aber der vielleicht relevanteste Teil dieses Beitrags ist wie folgt:

Programmierer verwenden häufig Stack-Tracing beim interaktiven und Post-Mortem-[Debugging] (https://en.wikipedia.org/wiki/Debugging). Endbenutzer sehen möglicherweise einen Stack-Trace, der als Teil einer Fehlermeldung angezeigt wird, die der Benutzer dann einem Programmierer melden kann.

Das stimmt mit dem überein, was ich oben skizziert habe, richtig? Aber genug darüber geredet, was ein Stack-Trace ist (es wird klarer, wenn wir uns eingehender mit dem Debuggen befassen), kehren wir zum Lesen der Protokolldatei in ihrem aktuellen Zustand zurück.

Zurück zum Lesen des Protokolls

Einschließlich Dateien

Schauen wir uns zunächst das Endergebnis im obigen Kern an. Es enthält Folgendes:

[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(): Failed opening './src/Admin/EmailExportSubmenu.php' for inclusion (include_path='.:/usr/local/Cellar/php/7.2.5/share/php/pear') in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Dies sagt mir, dass in Zeile 25 meiner Datei easy-email-export.php eine Datei zum Einschließen nicht geöffnet werden konnte. Dies bedeutet, dass ich eine include_once – Anweisung im Code habe, die auf ./src/Admin/EmailExportSubmenu.php verweist, die es nicht finden kann.

Die beste Vorgehensweise wäre also, Zeile 25 zu finden und festzustellen, warum die Datei nicht gefunden wird. Vielleicht gibt das den vollständigen Pfad aus, wo es sucht. Wir werden gleich darauf zurückkommen, wenn wir über das Schreiben in das Fehlerprotokoll sprechen.

Den Fehlern einen Sinn geben

Die nächste Zeile (d. h. die Zeile über der gerade betrachteten) enthält Folgendes:

[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(./src/Admin/EmailExportSubmenu.php): failed to open stream: No such file or directory in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Diese spezielle Zeile unterscheidet sich nur geringfügig, gibt aber zusätzliche Einblicke, und das ist in der Klausel enthalten, die lautet: „Keine solche Datei oder kein solches Verzeichnis.” Das ist aufschlussreich, weil es uns buchstäblich sagt, dass die Datei nicht existiert.

Zumindest existiert es nicht dort, wo es hinschaut. Also die beiden Möglichkeiten sind:

1. Wir haben die Datei, auf die wir verweisen, nicht erstellt.
2. Wir verweisen auf den Speicherort der Datei an der falschen Stelle

Als Erstes müssten wir also prüfen, ob die Datei an dem Ort existiert, den wir einzufügen versuchen. Wenn dies nicht der Fall ist, sollten wir die Datei erstellen.

Wenn die Datei existiert, wissen wir, dass das Plugin versucht, sie vom falschen Pfad zu laden. Daher müssen wir uns möglicherweise unseren Autoloader, unseren Aufnahmepfad oder wie auch immer die Dateien abgerufen werden, ansehen. Denn wenn die Datei existiert, versucht sie wahrscheinlich, von einem Ort geladen zu werden, an dem sie sich nicht befindet.

Ein nicht erkannter Fehler

In der letzten Zeile des Codes sehen Sie etwa Folgendes:

[05-Jul-2018 19:43:53 UTC] PHP Fatal error: Uncaught Error: Class 'EasyEmailExportAdminEmailExportSubmenu' not found in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php:37
#8 /U in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 37

Dies ist erstens ein gutes Beispiel, weil es ausdrücklich erklärt, dass dies ein nicht abgefangener Fehler ist. Dies bedeutet, dass unabhängig von der Funktionalität etwas einen Fehler auslöst und nicht abgefangen wird.

• Dies könnte eine Ausnahme sein,
• Dies könnte ein Problem sein, wenn Sie versuchen, eine nicht vorhandene Funktion aufzurufen.
• dies könnte auf eine nicht definierte Variable angewendet werden,
• usw.

Letztendlich gibt es eine Fülle von Problemen, die vorhanden sein könnten. Die gute Nachricht in diesem Beispiel ist, dass es praktisch dasselbe ist wie oben: Eine Datei wurde nicht gefunden.

Anstatt eine Warnung auszugeben, setzt PHP uns explizit darauf, dass dies ein schwerwiegender Fehler ist und das Programm die Ausführung nicht fortsetzen kann, bis diese Codezeile aufgelöst ist. Bevor wir dies als etwas abtun, das dasselbe ist wie im vorherigen Abschnitt (weil es gewissermaßen so ist), müssen wir erkennen, dass dies ausdrücklich als schwerwiegender Fehler angegeben ist, während es im vorherigen Beispiel als behandelt wurde Warnung.

Es gibt verschiedene Möglichkeiten, dies zu konzipieren, aber die Art und Weise, wie ich darüber denke, ist die folgende:

• Ein Hinweis sagt mir, dass etwas im Code nicht stimmt, aber es ist nicht schlimm genug, um eine Unterbrechung der Ausführung zu rechtfertigen.
• Eine Warnung ist etwas schwerwiegender, weil sie bedeutet, dass etwas nicht funktioniert.
• Ein direkter Fehler besagt: „Das funktioniert nicht und das Programm kann nicht fortfahren.”

Jetzt wissen wir, dass das Problem sozusagen atemberaubend ist, und wir wissen, was das Problem ist. Einfach ausgedrückt, eine Datei, die das Programm benötigt, um seine Ausführung abzuschließen, wird nicht gefunden und das Programm hört auf zu arbeiten.

Das ist sicherlich ein fataler Fehler.

Was ist die Lösung?

Was ich als Lösung für mein Problem anbiete, wird nicht vorschreiben, was für Sie funktionieren wird. Bei mir war es eine Zeile in meiner Composer-Konfiguration, dass der Composer-Autoloader die Datei nicht am richtigen Ort finden konnte (das hat aber mehr mit Dateiorganisation, Namensräumen usw. zu tun).

Bei dir kann es etwas anderes sein.

• Vielleicht sucht es nach einer Datei im falschen Verzeichnis,
• Vielleicht heißt die Datei anders als im Code angegeben,
• oder vielleicht ist es etwas anderes.

Was auch immer der Fall ist, der Punkt ist, dass es darum geht, sich von unten nach oben durch die Protokolldatei zu arbeiten, um das Problem zu diagnostizieren und zu verfolgen, was PHP, WordPress und Ihre Arbeit tun, und es dann von dort aus zu diagnostizieren.

Schreiben in das Fehlerprotokoll

Im nächsten Beitrag werden wir uns einen Moment Zeit nehmen, um zu sehen, wie wir in das Fehlerprotokoll schreiben können. Manchmal ist es in Ordnung, die Datei zu lesen, und einfach zwischen dem, was wir sehen, hin und her zu gehen und die Probleme zu lösen, ist nett.

Aber was ist, wenn wir etwas ausgeben wollen, um einen Einblick zu bekommen, was WordPress oder PHP sieht? Das ist auch nützlich.

Im nächsten Teil dieser Serie zum Verständnis von WordPress-Fehlerprotokollen werden wir genau das tun.

Was kommt danach?

Als Nächstes sehen wir uns an, wie Sie einige der zuvor beschriebenen Plugins verwenden, um Code zu testen und unseren Code zu profilieren, um sicherzustellen, dass wir alles in unserer Macht Stehende getan haben, um sicherzustellen, dass wir ein Qualitätsniveau produzieren.

Das bedeutet nicht, dass wir mit dem Debugging-Prozess vollständig fertig sind, aber wir sind definitiv einen Schritt näher gekommen, und wir sind in der Lage, Code mit einem Grad an Qualität zu schreiben, der nicht zu einer Datei führt, die verschiedene nuancierte Probleme darstellt Wir waren zu nachlässig, um es zu beheben (geschweige denn zu verstehen).