Das Debuggen von PHP ist immer noch ein nicht ganz triviales Thema. Oder genauer – einen Debugger für PHP zu finden und zum Laufen zu bringen. Es gibt im Grunde zwei oder drei populäre Optionen, die im Grunde auch weitgehend gleich sind bzw. aufeinander basieren:
- Zend Debugger
- Xdebug
Grundlage ist der Zend-Debugger Dazu noch einige kommerzielle Lösungen wie die von PHPStorm, bei der aber m.W. auch auf den Zend-Debugger wohl zurückgriffen wird.
Aber wenn man das kostenlose Xdebug einsetzen will, ist das nicht ganz so einfach. Es gibt ziemlich viele Hilferufe im Internet, dass das Zeug nicht (richtig) laufen will. Insbesondere das Anhalten bei einem Breakpoint will wohl nicht immer gelingen – vor allen Dingen nicht unter Windows.
Ich habe Xdebug nun schon eine ganze Weile installiert, aber bisher eher nicht wirklich beachtet. Meist komme ich bei PHP-Debugging mit den klassischen Techniken (echo-Ausgaben, Fehlerkonsole, Fehlerfunktionen und -variablen von PHP und Auskommentieren) aus.
Aber ich habe die letzten drei Tage in Neuwied einen PHP-Kurs gehalten und da das sehr erfahrene Programmierer waren, sind wir auch auf das grundsätzliche Debuggen als auch die erweiterten Möglichkeiten mit dem Debugger zu sprechen gekommen. Und da ist mir aufgefallen, dass eben das Anhalten bei einem Breakpoint in meinem System nicht funktioniert hat. War kein Beinbruch, aber für mich der Anlass, um heute morgen doch mal meine Konfigurationen genauer anzusehen. Vielleicht brauche ich da doch mal bei PHP einen echten Debugger.
Was habe ich da eben alles an Problemen und Lösungen in Verbindung mit Xdebug im Internet gefunden:
- Bei der Verwendung von localhost würde Windows einen Konflikt bekommen – stattdessen 127.0.0.1 verwenden.
- Das Mapping des Path ausschalten oder auch einschalten
- Auf die Einstellungen des Breakpoints achten und die diversen Skip-Breakpoints-Optionen an oder ausschalten
Die letzten Punkte betreffen von allen Dingen die Verwendung von Xdebug mit Eclipse und den PDT.
Aber nichts dergleichen bei mir. Der Hinweis auf den Konfigurations-Wizard von Xdebug hat mich dann auf die Lösung in meinem Fall gebracht. Dort kann man in einem Formular die Ausgabe von phpinfo() als HTML-Code reinkopieren und die Analysieren da, ob Xdebug richtig installiert und konfiguriert ist. Davon bin ich ausgegangen, aber die Analyse hat gemeint, dass da bei mir was nicht stimmt – was im Grunde auch Eclipse mit den PDT mir in der Konfiguration gezeigt hat, ich aber einfach nicht wahrgenommen habe.
Und so ist mir doch ein so grottenblöder Fehler in meinen
Konfigurationseinstellungen aufgefallen, dass es fast lächerlich ist.
Ich hatte den Pfad zu den Zend-Extensions in der Datei php.ini in
Hochkommata gesetzt und das darf man nicht machen. Deshalb hat der Debugger nicht angehalten, weil er eben nicht sauber konfiguriert war. Was eine
triviale Ursache mit weitreichenden Konsequenzen.
Nun geht aber alles.
Hier ist nochmal die bei Xdebug zu findende Schrittfolge, um Xdebug einzurichten, wobei man natürlich immer die neuste DLL nehmen sollte und alle Pfade anzupassen sind (das ist Stand von heute):
- Download php_xdebug-2.6.1-7.1-vc14.dll
- Move the downloaded file to F:\xampp\php\ext
- Update
F:\xampp\php\php.ini
and change the line
zend_extension = F:\xampp\php\ext\php_xdebug-2.6.1-7.1-vc14.dll
- Restart the webserver
Dazu wird noch empfohlen, in der php.ini das einzutragen, wobei das natürlich an die Pfade auf dem eigenen System anzupassen ist (bitte beachten – 127.0.0.1 statt localhost, was ja angeblich besser ist – bei mir spielt das keine Rolle):
[XDebug]
xdebug.remote_enable=true
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.profiler_enable=0
xdebug.profiler_output_dir="F:\xampp\php\ext\tmp"
Dann geht es auch mit dem Nachbarn – äh Debugger. Etwa aus Eclipse heraus.