PHP Entwicklung mit Eclipse/Subversion (SVN)/XDebug

Ich möchte hier kurz beschreiben, was notwendig ist, um PHP Programme effektiv mit Eclipse zu entwickeln. Eclipse for PHP Developers (oder kurz Eclipse PDT für die darin enthaltenen PHP Development Tools) bietet eine solide Grundlage, um Webapplikationen mit PHP zu entwickeln. Eclipse PDT ist dabei mehr als nur ein besserer Texteditor mit Code-Completion und Syntaxhighlighting – zumindest wenn man weiß wie man die Möglichkeiten von Eclipse voll ausreizen kann.

Eclipse spielt seine ganze Stärke in Bezug auf PHP erst im Verbund mit anderen Systemen und ein paar weiteren Plugins aus. Hierauf möchte ich kurz eingehen.

Fileupload mit Eclipse

Wer in Eclipse PDT einen Fileupload mittels STRG+SHIFT+U (oder ähnliches) erwartet, sucht vergebens. Und wer ihn sucht macht vermutlich einen konzeptionellen Fehler:

Die Idee hinter dem “Uploadmanagement” von Eclipse ist eine andere: erst testen, dann ausliefern. Im einfachsten Fall heißt das, dass man erst lokal alle Änderungen vornimmt, sie lokal testet, und dann gesammelt auf den Live-Server überträgt.

Für eine lokale Testumgebung bedarf es nicht viel: ein WAMP-Server (WAMP=Windows Apache MySQL PHP) ist dank verschiedener Installer schnell installiert (siehe weiter unten). Und mit einem lokalen Webserver kann man dann auch ohne den Live-Server zu beeinträchtigen seine Programe in aller Ruhe entwickeln, dann testen und wenn alles funktioniet bereitstellen. Und hier kommen wir zum Remote System Explorer (RSE) für Eclipse.

Der Remote System Explorer bietet verschiedene Dienste wie SSH, FTP und weitere, von denen uns hier aber nur die FTP Verbindung interessiert. Zuerst einmal müssen wir aber den Remote System Explorer installieren (bei Eclipse Helios als Administrator), da dieser in seinem vollen Umfang nicht standardmäßig installiert wird.

  • Unter “Help”->”Install new software…” öffnen
  • Bei “work with” den Punkt “Helios – http:// download.eclipse.org/releases/helios” auswählen (sofern es sich um die Eclipse Helios Verison handelt)
  • Im Feld “type filter text” nach “Remote System Explorer End-User Runtime” suchen
  • Die angebotene Extension auswählen und auf “next” klicken und die Installation abschließen

Im View “Remote Systems” kann man nun mittels “Define a connection to remote system” eine Verbindung zu einem Webserver einrichten. Ist dies geschehen, kann man diesen Webserver verwenden um die lokalen Daten dorthin zu exportieren (Rechtsklick auf die zu exportierenden Dateien dann “Export…”->”Remote Systems”->”Remote file system”. Im nun aufgehenden Dialog kann man die Exporteinstellungen vornehmen. Damit man nicht bei jedem Export all diese Einstellungen erneut vornehmen muss, kann man sie mittels “Save the settings of this export in the workspace” z.B. im Projekt speichern. Will man die Daten erneut exportieren, reicht nun ein Rechtsklick auf diese Settings und die Auswahl von “Export to remote file system” – schon sind die Dateien exportiert.

Da wir nun wissen, wie wir korrekt entwickeln sollten (erst testen, dann bereitstellen), möchte ich aber dennoch auf zwei weitere Möglichkeiten hinweisen. Zum einen ermöglicht der Remote System Explorer auch das anlegen kompletter Remote Projekte, welche sich gar nicht lokal befinden – man arbeitet dann direkt auf dem entfernten Server. Zum anderern existiert doch noch die Möglichkeit des Fileuploads mittels STRG-SHIFT-U: das Aptana Studio kann als Plugin in Eclipse geladen werden, und bietet unter anderem die Möglichkeit zum direkten File Upload mittels Tastenkürzel – vielleicht nicht best practice, aber für eine quick-‘n’-dirty Anpassung am Webserver immer noch sehr hilfreich.

Eclipse und Subversion (SVN)

Da in der Softwareentwicklung eine Versionsverwaltung unumgänglich ist, wollen wir diese auch mit Eclipse nutzen. Eclipse bietet von Haus aus eine Verbindung zum Concurrent Versioning System (CVS), was aber meiner Meinung nach nicht mehr zeitgemäß ist (wenn auch weit verbreitet). Subversion (SVN) bietet da einiges mehr. Um Eclipse um SVN Unterstützung zu erweitern, steht Subclipse als Plugin zur Verfügung. Dieses erhält man seit Eclipse Helios über den neuen Marketplace in Eclipse. Einfach dort auf ‘install’ klicken, und schon besitzt Eclipse SVN Unterstützung.

Das Subclipse Plugin alleine reicht in Eclipse natürlich noch nicht aus. Um die Versionskontrolle nutzen zu können, benötigt man einen Subversion Server. Wie man diesen unter Windows schnell und einfach einrichten kann, habe ich an anderer Stelle bereits beschrieben (siehe “Subversion unter Windows“).

Ist dieser eingerichtet kann auf das SVN Repository über die View “SVN Repositories” zugegriffen werden. Legt man hier nun ein neues Repository an, kann dieses in der Projektübersicht (z.B. im PHP Explorer View) genutzt werden. Im Eigenschaftsmenü des Projektes “Team”->”Share Project…” auswählen, und dort dann das zuvor angelege Repository auswählen. Will man auf Projekte in einem bereits bestehenden Repository zugreifen, kann man diese z.b. einfach mittels Rechtsklick auf das Projekt im Repository auschecken, und so ein neues Eclipse Projekt erstellen.

Weitere Informationen:

[Hinweis: kurz nach Release von Eclipse Helios war eine fehlerfreie Installation von Subclipse nur möglich, wenn man Eclipse mit Administratorrechten gestartet hat, und dann Subclipse global installiert hat. Anschließend konnte man Eclipse wieder als normaler User starten, und die Subclipse Views standen normal zur Verfügung. Wurde die Installation nicht als Administrator ausgeführt, waren die Views nicht verfügbar, auch wenn das Plugin als installiert gemeldet wurde. – Mir ist derzeit unbekannt, ob dies bereits gefixed wurde.]

PHP Debugging mit Eclipse

Aber warum sollte man Eclipse PDT verwenden, wenn man Code Editing, File Transfer und SVN Anbindung auch beispielsweise mit deutlich kompakteren Tools wie dem Notepad++, Filezilla und TortoiseSVN nutzen kann?

Hier kommt der Eclipse Debugger ins Spiel. Sicherlich kann man PHP Skripte auch einfach mittels ‘echo’, ‘print_r’ oder ‘var_dump’ debuggen, und sich so den Zustand eines Programms ausgeben lassen – übersichtlich oder komfortabel ist dies aber nicht. Wer bereits einmal mit einer IDE wie Microsofts Visual Studio gearbeitet hat, weiß eine gute Debugging Unterstützung zu schätzen. Breakpoints und das zeilenweise Vorrangehen im Code sind nur zwei von zahlreichen komfortablen Merkmalen einer guten IDE.

Eclipse PDT bringt diese von Haus aus mit. So ist es über die bereits genannten Möglichkeiten hinaus möglich z.B. Variablen und beliebige Ausdrücke zu untersuchen, oder auch während der Laufzeit zu verändern, um beispielsweise die Reaktion des Programms auf falsche Eingaben zu prüfen. Um den Debugger in Eclipse aber nutzen zu können benötigt man einen Webserver mit PHP und aktiviertem XDebug Modul.

Einen lokalen Webserver unter Windows einzurichten ist dank verschiedener zur Verfügung stehender Installer sehr einfach: Installer herunterladen, Anweisungen folgen, fertig. XAMPP oder WampServer sind zwei entsprechende Pakete. Zusätzlich benötigt man noch das XDebug Modul für PHP. Einfach die zur verwendeten PHP Version passende php_xdebug.dll herunterladen und im PHP Extension Verzeichnis speichern (bei XAMPP beispielsweise unter “C:\xampp\php\ext\php_xdebug-2.1.0-5.3.0.dll“).

Anschließend muss noch die php.ini angepasst werden (bei XAMPP unter “C:\xampp\apache\bin\php.ini“). Am Ende der php.ini muss die Sektion XDebug eingefügt werden:

[XDebug]
zend_extension_ts = “C:\xampp\php\ext\php_xdebug
-2.1.0-5.3.0.dll”
xdebug.profiler_output_dir = “C:/xampp/tmp/xdebug”
xdebug.profiler_output_name = “cachegrind.out.%p”
xdebug.profiler_enable = 0
xdebug.profiler_append=0
xdebug.extended_info=1
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.idekey=ECLIPSE_DBGP
xdebug.remote_log=”c:/xampp/tmp/xdebug/xdebug_remote.log”
xdebug.show_exception_trace=0
xdebug.show_local_vars=9
xdebug.show_mem_delta=0
xdebug.trace_format=0

Startet man dann den lokalen Webserver, kann man mittels phpinfo() überprüfen, ob das XDebug Modul korrekt geladen wurde. Damit wäre der lokale Webserver bereit für eine Debug-Session.

Verwendet man nun als Eclipse Workspace das htdocs Verzeichnis des lokalen Webservers, und legt dort die entsprechenden Eclipse PHP Projekte an, so muss nur noch der Eclipse Debugger konfiguriert werden:

  • Über “Run”->”Debug Configurations” die Debug Einstellungen aufrufen
  • Unter “PHP Web Page” mit einem Klick auf das “New Launch Configuration” Icon eine neue Debug Konfiguration anlegen
  • Unter “Server” als “Server Debugger”->”XDebug” auswählen
  • Als Datei wählt man die gewünschte Datei aus dem PHP Projekt aus
  • “Break at first Line” kann man nach Geschmack auswählen
  • Die “URL” kann in diesem Fall mittels “auto generate” ermittelt werden.
  • “Apply” und “Close” speichern und schließen das Fenster, mittels “Debug” startet man direkt eine Debug-Session.

Im Editor kann man nun z.B. einfach mittels Doppeklick auf den linken Rand einen Breakpoint in einer Zeile erzeugen. Mittels F11 läßt sich der Debugger schnell starten, und sollte bei gesetztem Breakpoint dann auch in der entsprechenden Zeile (vor deren Ausführung) anhalten. Je nach Konfiguration wird dabei zum einen die Eclipse PHP-Debug Perspektive geöffnet, und je nach Einstellung auch ein externer Webbrowser.

Für eine einzelne PHP Datei kann sicher auch das einfache Skript Debugging verwendet werden, aber die Konfiguration als “PHP Web Page” bietet den Vorteil, dass eine Debug-Session es erlaubt über die Web Seite zu surfen und diese im Browser ganz normal zu benutzen. Ob einfaches surfen, oder auch Login oder Formular-Auswertung – innerhalb einer Debug-Session kann man mit Eclipse und XDebug die verschiedenen Reaktionen des Programms beobachten und testen bzw. die Umstände bei auftretenden Fehlern auf komfortable Art und Weise untersuchen.

Weitere Details zur Verwendung von Eclipse PDT mit XDebug finden sich in “XDebug Support in PDT 2.0“.

Hinweis: Die Bedingungen im Expressions View können dazu führen, dass die Debug Session abgebrochen wird (“Unexpected termination of script …”), insbesondere wenn Funktionsaufrufe und nicht nur Variablen/Parameterabfragen darin enthalten sind. Einfach die Bedingunen dann löschen, dann läuft es wieder.

Weitere Informationen:

Sonstiges