Diese Woche wurde ich um Hilfe bei der Einrichtung von Xdebug mit PhpStorm auf einem Linux-Laptop in Verbindung mit Docker gebeten. Darüber schreibe ich vielleicht in einem kommenden Blogbeitrag. Heute möchte ich mich aber auf verschiedene Methoden zum Debuggen von PHP-Code konzentrieren.

1. echo, print_r, var_dump – der schnelle, aber hässliche Weg

Wer schon einmal etwas in PHP entwickelt hat, ist wohl nicht um eine der „Ausgabefunktionen“ herumgekommen. Mit echo kannst du einen generischen Wert wie einen String oder eine Zahl ausgeben. Für Arrays und Objekte verwendest du eher print_r oder var_dump.

Vorteile:

• Einfach: Die Methoden können einfach verwenden werden. Du musst nichts installieren, um sie nutzen zu können.
• Schneller Einblick: Wenn du einfach nur den Wert an einer bestimmten Stelle ausgeben möchtest, ist es mit den Funktionen sehr einfach, den aktuellen Wert an dieser Stelle auszugeben.

Nachteile:

• Ausgabe-Einschränkungen: Die Methoden sind eher einfach. Du erhältst nur den Wert dieser einen Variable, aber keinen „Kontext“. Da die Ausgabe oft in ein HTML-Dokument gerendert wird, musst du sie möglicherweise in ein <pre>-Tag für Arrays/Objekte einbetten oder sie im Quellcode anzeigen lassen.
• Störend: Wenn du die Variablen ausgibst, dann tust du das möglicherweise beim Rendern eines Templates. Das bedeutet, dass dein Layout/Design verzerrt wird.
• Unsicher: Wenn du diese Methode auf einer Live-Website verwendest, dann ist die Ausgabe für alle sichtbar. Das sieht nicht nur wie ein Fehler aus, es kann auch ein Sicherheitsrisiko darstellen, wenn der Inhalt der zu debuggenden Daten nicht sichtbar sein sollte.
• Aufräumen erforderlich: Selbst wenn du diese Methode nur beim lokalen Entwickeln verwendest, musst du daran denken, den Code wieder zu entfernen, bevor du ihn hochlädst oder du einen Commit und Push in eine Versionskontrolle machst. Es passiert recht schnell, dass man einige Zeilen übersieht, die dann auf einer Live-Website landen.

2. error_log, file_put_contents – Ausgabe in eine Datei

Anstatt die Debug-Ausgabe direkt auf dem Bildschirm auszugeben, könntest du sie in eine Datei schreiben. Dies hat einige Vorteile, aber auch einige Nachteile:

Vorteile:

• Trennung der Zuständigkeiten: Wenn du die Debug-Informationen in eine Datei schreiben lässt, dann hälst du den Anwendungscode frei von Debug-Ausgaben. Du könntest sogar deine eigene Debugging-Funktion als Wrapper für die error_log oder file_put_contents Funktionen einführen und innerhalb dieser Funktion prüfen, ob der „Debug-Modus“ aktiv ist.
• Dauerhafte Speicherung: Wenn du diesen „Debug-Modus“ aktiviert hast, kannst du die Daten über einen längeren Zeitraum in der Datei speichern und diese Datei dann später auf die möglichen Fehler hin überprüfen. Es ermöglicht dir auch das Debuggen von Anfragen von anderen Personen, womit du möglicherweise Probleme finden kannst, die du selbst nicht „siehst“.
• Keine störende Ausgabe: Deine Ausgabe auf der Website bleibt sauber, da alle Debug-Daten nur die Datei geschrieben werden.

Nachteile:

• Manuelle Überprüfung: Du erhältst die Debug-Informationen nicht sofort. Wenn du dies auf einer Live-Website ausführst, siehst du möglicherweise sogar die Debug-Informationen einer anderen Person. Mithilfe des tail Befehls kannst du die Datei aber fast in „Echtzeit“ debuggen.
• Schwieriger zu debuggen: Wenn du eine gemeinsame Debug-Datei für alle Funktionen verwendest, erhältst du alle Debug-Daten ohne jeglichen „Kontext“. Wenn du also die Datei/Zeile einer bestimmten Meldung identifizieren möchtest, musst du sie vielleicht noch __FILE__ und __LINE__ voranstellen und zusätzlich auch Datum/Uhrzeit voranstellen, damit du weißt, wann der Eintrag geschrieben wurde.
• Overhead: Das Loggen von Daten in eine Datei kann die Leistung der Website beeinträchtigen, insbesondere wenn du eine große Menge Daten debuggst. Du solltest auch die Dateigröße der Debug-Datei von Zeit zu Zeit überprüfen und sicherstellen, dass der Debug-Modus nur dann deaktiviert ist, wenn du ihn wirklich braucht, da du sonst leicht den gesamten verbleibenden Speicherplatz auf deinem Server mit einer riesigen Protokolldatei füllen kannst.
• Sicherheitsrisiko: Ja, auch die Verwendung einer Debug-Datei kann ein Sicherheitsrisiko darstellen, falls diese öffentlich zugänglich ist. Wenn sie allerdings nicht öffentlich zugänglich ist, dann ist das Debuggen mit einer Datei wieder schwieriger, du den Inhalt dann nur über ein Terminal oder durch Herunterladen einsehen kannst. WordPress beispielsweise speichert die debug.log Datei im wp-content Ordner und macht sie für alle aufrufbar. Du kannst aber den Pfad anpassen, um den direkten Zugriff zu verhindern.

Debug-Plugins – das Beste aus beiden Varianten bekommen

Für WordPress verwende ich normalerweise immer das Query Monitor-Plugin. Dieses Plugin bietet mehrere Actions zum Debuggen von Variablen. Eine davon ist die qm/debug Action.

Vorteile:

• Keine direkte Ausgabe: Durch die Verwendung dieser Action gibst du die Debug-Daten nicht auf der Seite aus, die Website wird also nicht verzerrt dargestellt.
• Sicherheit: Du siehst die Debug-Daten von Query Monitor (und dem Hook) normalerweise nur denn, wenn du ein Administrator der Website bist. Aber du kannst es sogar (mithilfe eines Cookies) verwenden, wenn du ausgeloggt bist.
• Keine Debug-Datei erforderlich: Es sendet die Debug-Daten mit der Response und speichert keine Datei auf dem Server ab. Damit hast du nicht die Nachteile der vorherigen Methode.

Nachteile:

• Debug-Code in deinem Anwendungscode: Wie bei den anderen Methoden musst du immer noch Code zum Debuggen in deinen Anwendungscode schreiben. Du würdest diesen Code dann auch auf einer Live-Website haben oder einem Repository haben. Das sollte für „unveröffentlichten“ Code in Ordnung sein, aber du möchtest ihn lieber nicht in einem Plugin/Theme veröffentlichen. Bevor du also eine neue Version des Plugins/Themes veröffentlichst, müsstest du den Debug-Code wieder entfernen.
• Kann keine defekten Seiten debuggen: Da diese Debugging-Methode das Query Monitor-Plugin erfordert, kannst keinen schwerwiegenden Fehler debuggen, der den Query Monitor daran hindert angezeigt zu werden.
• Du siehst nur deine eigenen Fehler: Du kannst diese Methode nicht verwenden, um Probleme zu debuggen, die eine andere Person mit deiner Website hat, und du möchtest der anderen Person wahrscheinlich auch nicht die Berechtigung geben, Query Monitor selbst zu verwenden.

Xdebug – die nächste Stufe des Debuggens

Wenn du noch nie von Xdebug gehört hast und/oder es noch nie verwendet hast: verwende es direkt, nachdem du diesen Blogbeitrag gelesen hast! Für mich ist es das beste Tool, um komplexe Probleme zu debuggen. Xdebug ist eine PHP-Erweiterung, die installiert und aktiviert werden muss. Du benötigst auch eine IDE wie PhpStorm oder VS Code, um es zu verwenden, aber dann kann es dir wirklich helfen, diese schwer zu debuggenden Probleme zu finden.

Vorteile:

• Kein zusätzlicher Code erforderlich: Anstatt Debugging-Funktionen in deinen Code zu schreiben, setzt du einfach einen „Breakpoint“ in deiner IDE in einer bestimmten Zeile.
• Du kannst alles debuggen: Sobald ein Breakpoint erreicht ist, kannst du jede Variable debuggen! Du bist also nicht auf eine einzelne Variable beschränkt, sondern du kannst den Wert aller Variablen einsehen. Du kannst auch den „Aufrufstapel“ sehen, also jede Funktion, die vor dem Erreichen dieses Punktes aufgerufen wurde. Du kannst auch zu diesen Funktionen zurückgehen und die Parameter untersuchen, mit denen sie aufgerufen wurden.
• Nur bestimmte Fälle untersuchen: Angenommen, dein Code bricht nur in Fällen ab, in denen eine Variable einen bestimmten Wert hat. In diesem Fall kannst du einen bedingten Breakpoint verwenden, der nur anhält, wenn diese Bedingung erfüllt ist.
• „Was-wäre-wenn“: Du hast also ein Problem mit einer Variable und ihrem Wert gefunden und nun fragst du dich, ob der Code mit einem anderen Wert funktionieren würde? Wenn du an einem Breakpoint bist, kannst du den aktuellen Wert einer Variable überschreiben und dann fortsetzen, um zu sehen, was in diesem Fall passieren würde.

Nachteile:

• Schwierige Einrichtung: Wenn du Xdebug noch nie zuvor verwendet hast, könnte es schwierig sein, es einzurichten. Du musst die PHP-Erweiterung auf dem Rechner, auf dem du den Code ausführst, installieren und aktivieren und deine IDE konfigurieren. Wenn du es mit Docker verwendest, musst du auch sicherstellen, dass der PHP-Container mit deiner IDE „kommunizieren“ kann. Obwohl es viel einfacher geworden ist und PhpStorm heutzutage (fast) keine Konfiguration mehr benötigt, könnte es schwierig sein, es beim ersten Mal zum Laufen zu bringen. Ich verwende es normalerweise in Kombination mit DDEV und weiß jetzt, wie ich es schnell zum Laufen bringen kann. Aber deine Konfiguration könnte eine andere seit.
• Könnte deinen Request abbrechen: Da du den Request beim Debuggen „anhältst“, könnte es möglich sein, dass deine Website nicht mehr angezeigt wird, wenn du den Code hast durchlaufen lassen. Das ist normalerweise der Fall, wenn du nginx als Webserver verwendest. Du erhältst dann einen Error 500, weil die Anfrage an das „PHP-Backend“ abgelaufen ist.
• Auf Live-Umgebungen nicht wirklich verwendbar: Xdebug ist super für die Entwicklung in einer lokalen Umgebung, aber es nicht das beste Tool für den Einsatz auf einer Live-Website. Xdebug hat einen großen Einfluss auf die Performance. Da Xdebug mit deiner IDE „kommunizieren“ muss, könnte es auch schwierig bis unmöglich sein, eine Konfiguration zu finden, die mit deiner IDE und einer Live-Site funktioniert.

Fazit

Es gibt verschiedene Methoden zum Debuggen von PHP-Code, und alle von ihnen haben ihre Vor- und Nachteile – sogar mehr, als ich in diesem Blogbeitrag erwähnt habe. In einigen Fällen reicht ein schnelles Debuggen mit echo aus. Aber es gab in der Vergangenheit einige Probleme, die ich ohne die Hilfe von Xdebug niemals gefunden hätte. Daher empfehle ich dringend, eine Konfiguration zu finden, die für dich funktioniert.

Ich habe einige Leute nach ihren Debugging-Methoden gefragt. Etwa 40% verwenden häufig Methode 1, etwa 5% Methode 2 und „nur“ 55% haben schonmal Xdebug benutzt. Ich hoffe, dass ich die anderen 45% auch endlich davon zu überzeugen, Xdebug als ihr Debugging-Tool zu benutzen.

Und was ist mit dir? Hast du Xdebug schon mal benutzt? Verwendest du andere Methoden, die ich nicht erwähnt habe und die für dich gut funktionieren? Dann hinterlasse bitte einen Kommentar.