FirePHP als Debugger für PHP und Ajax einsetzen

Jeder Entwickler benötigt einen Debugger. Abhängig von Programmiersprache und Entwicklungsumgebung gibt es unzählige Möglichkeiten, die Ausführung der entwickelten Applikation zu überwachen. Entwickler von Webapplikationen haben dabei oft das Problem, dass sie eine ganzheitliche Lösung brauchen, um über mehrere Ebenen zu debuggen: Das Backend (meist eine Mischung aus Datenbank und Skriptsprache), ggf. im Backend auch noch Schnittstellen zu Drittsystemen und zusätzlich das Frontend, dabei den statischen und dynamischen Anteil – zumeist JavaScript. Bei der Verwendung von asynchronen HTTP-Anfragen zurück ins Backend wird es noch komplizierter: Die Antwort auf den Request hat im Grunde keinen Platz für Log- oder Fehlermeldungen. Klar, man kann sich die Meldungen in der HTML-Seite ausgeben lassen oder man parst den Rückgabewert noch einmal durch das JavaScript. Oder man lässt den AJAX-Prozessor ins Fehlerlog des Webservers schreiben und überwacht dieses parallel auf der Kommandozeile per tail.Alle diese Methoden bedeuten aber vermehrten Aufwand bei der Erzeugung (und später auch wieder bei der Entfernung) der Meldungen. Insbesondere steigt beim Einsatz verschiedener Mechanismen die Gefahr, dass die Debugger irgendwie ihren Weg in den Produktivcode finden, weil man nicht aufpasst.

Debugging PHP im Browser

Für die weit verbreitete Skriptsprache PHP gibt es auch anspruchsvollere Lösungen: Der Zend Debugger wird oft verwendet, findet auch in PDT Einsatz. Das Aptana Studio (ebenfalls ein Eclipse-Derivat) hat ein eigenes Firefox-Addon, welches sich jedoch leider ziemlich mit dem unverzichtbaren Firebug beisst. Allerdings besteht bei allen Helferlein das Problem, über die oben angesprochenen Ebenen hinweg zu überwachen. Christoph Dorn hat sich deshalb hingesetzt und eine feine Lösung gebaut: FirePHP. FirePHP ist eine weitere Firefox-Extension, die ein zuvor installiertes Firebug benötigt und dann im Firebug-Stil die Meldungen des im Backend vorhandenen Debuggers ausgibt.

Was brauche ich?

Die Liste der notwendigen Tools ist kurz, die Installation trivial:

Die weiteren Beispiele beziehen sich der Einfachheit halber auf die standalone-Version. Im Grunde reichen zwei Zeilen Code, um FirePHP ans Laufen zu bringen:

<?php
require dirname(__FILE__) . '/extlib/firephp-0.2.1/fb.php';
FB::log(array('Peter','Paul','Mary'), 'Names');
?>

Hat man die beiden Addons Firebug und FirePHP im Mozilla Firefox installiert und das Tracking für Konsole und Netzwerk eingeschaltet, bietet sich in der Firebug-Konsole ein wunderschönes Bild:

Screenshot: FirePHP in der Firebug-Konsole

Magie! Doch das ist noch nicht alles. Neben unterschiedlichen Nachrichtenarten (log, info, warn, error) gibt es unzählige weitere Einsatzmöglichkeiten. Unter anderem fängt FirePHP auch Exceptions und lässt sich über ein Singleton auch als Objekt verwenden, um Traces zu bauen oder tabellarisch Inhalte anzuzeigen.

Debugging AJAX-Handler per FirePHP

Der Clou an der Sache: FirePHP portiert die Nachrichten über den HTTP-Header (gut, irgendwie müssen sie ja zum Browser kommen). In JSON-Syntax wird die entsprechende Meldung übermittelt. Das bedeutet, dass auch nachgelagerte Anfragen (AJAX) und deren Algoritmen brav in die Konsole schreiben. Ich muss mich also – gerade bei kleinen Projekten – nicht verbiegen, um die sonst so stillen Listener zum Reden zu bringen.

Screenshot: JSON-Syntax im HTTP-Header

So kann ich das console-Objekt vom Firebug munter mit dem FB::-Debugger mischen und mir aus allen Teilen der Applikation Meldungen sichtbar machen.

Mischung Firebug und FirePHP

Vorsicht beim Deployment!

Die Verwendung ist natürlich auch nicht ungefährlich. Man will unbedingt verhindern, dass derartige Meldungen und die Debug-Anweisungen irgendwo in einem Produktiv-System landen (das ist wohl bei jedem Debugger so). Aus diesem Grund benötigt man einen strengen Mechanismus, der auf Unaufmerksamkeit böse reagiert. Ein vernünftiger pre-commit hook im Versionierungssystem bietet sich an. Wer seine Webapplikation z. B. per Ant bauen lässt, kann in seiner build.xml eine entsprechende Sicherheitsabfrage unterbringen. Für die Überprüfung bietet sich z. B. der phpCodeSniffer an, der sich wiederum im pre-commit hook einsetzen lässt. Dazu gibt es eine großartige Zusammenfassung von Ronny Ristau.

Dieser Beitrag wurde unter PHP, Software, Web-Entwicklung abgelegt und mit , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>