PHP Debugging für .NET Dummies (IIS – WordPress – PhpStorm – Xdebug)

Vor einigen Tagen stand ich vor der Aufgabe im Zuge eines kleinen Projektes eine Verbindung zwischen der .NET und der PHP Welt herstellen zu müssen.

Als .NET Entwickler bin ich es eigentlich gewohnt mit Visual Studio zu arbeiten. Auch wenn man nicht immer mit VS super zufrieden ist, kann man damit aber doch ganz ordentlich Entwickeln. daher war es mir  wichtig auch für diesen PHP Ausflug zuerst einmal eine “gescheite” Entwicklungsumgebung für dieses Projekt aufzubauen.

Da ich neben ReSharper (Visual Studio Plugin) bereits WebStorm (beides Erstklassige Produkte von JetBrains) einsetze war für mich sehr schnell klar, dass als PHP IDE PhpStorm vom gleichen Hersteller zum Einsatz kommen soll.

Unter einer “gescheiten” Entwicklungsumgebung verstehe ich ab er als minimale Anforderung:

  • Einen guten Editor (IDE) (Am besten Syntax highlighting)
  • Einen ordentlichen Debugger (Am besten in der IDE integriert)

Mit PhpStorm habe ich die “gute”  IDE bereits ausgewählt.

Das Problem des integrierten Debugger kann ich aber weder mir PhpStorm noch mit einer anderen mir bekannten Entwicklungsumgebung für PHP direkt und einfach lösen.

Um PHP zu debuggen gibt es eine Extension mit der Bezeichnung “Xdebug”,  die direkt zusammen mit PHP arbeitet und in der PHP.INI konfiguriert werden muss.

Und genau diese Konfiguration und Einrichtung ist mir als .NET Entwickler irgendwie nicht wirklich einfach von der Hand gegangen.

Die Konfiguration von Xdebug in PHP war noch recht einfach und auch ganz ordentlich dokumentiert. Wie man jedoch aus der IDE (PhpStorm) Breakpoints setzen und den Debugger nutzen kann, dass blieb zuerst ein Buch mit vielen Siegeln.

Über die Konfiguration von PHP und Xdebug auf einem IIS unter Verwendung von PhpStorm, gab es eigentlich keine oder nur unvollständige Anleitungen (oder ich habe sie einfach nicht gefunden).

Nun aber genug der Vorreden, ab hier geht es nun um die Beschreibung (Schritt für Schritt Anleitung) wie man auf einem Windows Rechner eine komplette Entwicklungsumgebung für PHP einrichten kann, mit der sogar ein .NET Entwickler etwas anfangen kann 🙂 .

Systemumgebung, Programme, Voraussetzungen:

  • Windows 2008 R2 Server (Windows 7 mit installiertem IIS würde auch funktionieren)
  • WordPress (Oder jede andere PHP Anwendung wie z.B. Joomla)
  • imagePhpStorm 3.X
  • Xdebug (Debugger Tool für PHP)

Installation / Überprüfung IIS

Benötigt wird ein IIS 7 oder 7.5 (kein IIS Express).

Unter dem W2K8 geht das einfach indem man die Serverrolle Webserver (IIS) auswählt und installiert.

image

Es werden keine speziellen Rollendienste benötigt, also einfach nur auf Weiter und Installieren klicken bis die Installation abgeschlossen ist.

image

WordPress (und alle benötigten Komponenten installieren)

Der einfachste Weg um ein Produkt wie WordPress auf einem Windows Rechner zu installieren ist sicherlich die Verwendung des Web Plattform Installer (Der übrigens auch in WebMatrix integriert ist).

Der Web Plattform Installer stellt selbst fest welche Komponenten auf dem Rechner vorhanden sind und welche installiert werden müssen um das ausgewählte Produkt verwenden zu können.

Hier kann man dem Web Plattform Installer herunterladen

Also Web Plattform Installer herunterladen und aufrufen (installieren).

Nach der Initialisierung geben wir im Suchfeld “WordPress” ein und bestätigen die Eingabe mit der Enter Taste.

Nun wählen wir WordPress in der gewünschten Sprache aus und betätigen den Button hinzufügen.

image

Wenn man nun auf Installieren klickt werden die folgenden Tools und Produkte installiert.

image

Während der Installation müssen wir noch folgende Angaben machen:

image

Da ich eine Entwicklungsumgebung aufbauen möchte, werde ich MySQL auf dem lokalen Rechner installieren lassen. (Weiter klicken)

Nun bekommt man noch mal alle zu installierenden Produkte angezeigt und wird aufgefordert den Lizenzbedingungen zuzustimmen.

image

Jetzt muss noch ein root Passwort für die MySQL Installation angeben werden:

Beim Weiter Klicken, geht die Installation schon los.

Die Installation kann je nach Internet Geschwindigkeit unterschiedlich lange dauern, da während der Installation die aktuellen Pakete heruntergeladen und installiert werden.

Bei DSL 16000 und einem Rechner mit I7 Prozessor dauert die Gesamte Installation 3 – 5 Minuten.

Nächster Stop Webseite für WP konfigurieren:

image

Da ich WordPress nur in der Entwicklungsumgebung aufrufen und nicht von extern zugänglich machen möchte, lasse ich die Einstellungen wie vorgegeben. Das führt nach der Installation dazu, dass die Seite unter localhost/wordpress erreichbar sein wird.

Noch ein Stop Datenbank erstellen

image

Datenbank auswählen / erstellen und Root Passwort

image

Da wir MySQL gerade erst installiert haben, müssen wir natürlich eine Neue Datenbank erstellen.

Im Eingabefeld (roter Pfeil(, müssen wir das Root Passwort eingeben, dass wir während der Installation von MySQL vergeben haben.

Datenbankbenutzer / Passwort eingeben

image

Die Einträge mit den grünen Pfeilen müssen wir nicht anpassen.

In den Feldern mit den roten Pfeilen muss nun noch ein Kennwort für den Datenbank Benutzer eingegeben werden. Das muss nicht, kann aber das gleiche wie das Root Passwort sein (aber bitte nur auf lokalen Entwicklungssystemen, sonst sollten die Datenbank Passwort nicht dem Root Passwort entsprechen)

In allen weiteren Felder müssen keine Eingaben gemacht werden.

image

image

Damit sind nun WordPress und alle benötigten Tools und Programme installiert.

WordPress sollte nun schon funktionieren, also testen wir es mal.

Browser öffnen und localhost/wordpress eingeben.

image

Am besten geben wir gleich die notwendigen Daten für WP ein, so dass wir später direkt auf die Homepage von WordPress und nicht mehr auf die Admin Setup Seite geleitetet werden.

Beim nächsten Aufruf sollte das so aussehen:

image

Xdebug installieren

Nun müssen wir die Xdebug Extension installieren.

Wie wir weiter oben sehen wurde PHP in der Version 5.2 installiert, also müssen wir nun auch die Xdebug Version für PHP 5.2 herunterladen und installieren.

Aber Achtung es gibt 2 verschiedene Varianten:

Eine Thread sichere und eine Nicht Thread Sichere (nts), für die Installtion auf dem IIS muss die nts Variante verwendet werden.

Hier geht es direkt zum Download xdebug version 2.1.2 für PHP 5.2 Not Thread Safe

Die Extension besteht lediglich aus einer DLL Datei mit dem Namen:

php_xdebug-2.1.2-5.2-vc6-nts.dll

Nachdem man die Datei heruntergeladen hat muss diese in das Ext Verzeichnis von PHP kopiert werden.

Bei einer Standardinstallation auf einem W2K8 Server (64 BIT) findet man das Ext Verzeichnis unter folgendem Pfad:

C:\Program Files (x86)\PHP\v5.2\ext

Als nächstes muss die PHP.INI angepasst werden um die Debugger Extension verwenden zu können

Die PHP.INI befindet sich im Verzeichnis:

C:\Program Files (x86)\PHP\v5.2

Also öffnen wir die PHP.INI mit einem Texteditor und fügen folgende Einträge hinzu:

[xdebug]
zend_extension = "C:\Program Files (x86)\PHP\v5.2\ext\php_xdebug-2.1.2-5.2-vc6-nts.dll"
xdebug.remote_enable = On
xdebug.remote_host = "localhost"
xdebug.remote_port = 9000
xdebug.remote_handler = "dbgp"

Eigentlich ist es gleich an welcher Stelle diese Einträge hinzugefügt werden, aber wer sich gerne strikt an Vorgaben hält, kann die Einträge direkt unter dem folgenden Eintrag einfügen, dann funktioniert es auf jeden Fall.

image

Nun speichern wird die PHP.INI und müssen noch den IIS Neu starten:

Entweder über die Konsole “Internetinformationsdienste (IIS)-Manager

oder über die Kommandozeile:

net stop WAS (zum stoppen des IIS)

und dann

net start W3SVC (um den IIS wieder zu starten.)

Später (nachdem wir PhpStorm installiert haben und damit auch einen brauchbaren Editor  zur Verfügung haben)  prüfen wir auch noch ob die Extension richtig eingerichtet wurde.

PhpStorm installieren

PhpStorm gibt es in einer 30 Tage Trial Version, wer also keine Lizenz besitzt kann sich  erst einmal 30 Tage lang anschauen ob im PhpStorm das Geld, was es kostet, wert ist (Ich denke dass ist es auf jeden Fall, ein tolles Produkt wie eigentlich alle Produkte von JetBrains. Nein ich bekomme keine Prozente 🙂 )

Den Download gibt es hier: http://www.jetbrains.com/phpstorm/download/

Nachdem herunterladen installieren wir PhpStorm einfach mit allen Standardeinstellungen.

WordPress Projekt in PhpStorm einrichten

Nun öffnen wir PhpStorm und wählen die nachfolgende Option aus:

Create New Project from Existing Files

image

Das Szenario: Lokaler Web Server und Source Code unterhalb des Web Root passt genau für unser vorhaben.

image

Nun wählen wir das Root Verzeichnis (Nicht das WordPress Verzeichnis auswählen) des Default WEB unseres localhost aus.

image

Jetzt geben wir dem Projekt Server noch einen Namen (z.B. MyLocalServer)

image

In nächsten Schritt (Siehe Abbildung oben) geben wir nun die Projekt URL unserer WordPress Installation an.

Und haben damit das Projekt eingerichtet (Wie man auch in der folgenden Abbildung sehen kann).

Xdebug überprüfen

Wir öffnen die Datei index.php aus dem Root Verzeichnis unserer WordPress Installation im PhpStorm Editor.

Dort fügen wir die Funktion phpInfo() direkt nach dem Kommentar ein und speichern die Datei ab.

image

Nun öffnen wir den Browser und geben localhost/wordpress ein. Wenn anstelle der normalen WordPress Startseite diese PHP Info Seite angezeigt wird, haben wir bis hierhin schon mal alles richtig gemacht.

image

Um die Prüfung von Xdebug durchführen zu können, benötigen wir den Source Code der im Browse dargestellten phpinfo Seite.

Dazu lassen wir uns den Quelltext der Seite anzeigen, markieren den gesammten Quelltext, kopieren diesen in die Zwischenablage, und öffnen anschließend folgende Webseite:

http://xdebug.org/find-binary.php

image

Dort wo der rote Pfeil hinzeigt fügen wir dann den in der Zwischenablage befindlichen Quelltext ein und betätigen anschließend den “Analyse my phpinfo() output” Button.

Wenn Xdebug richtig installiert ist, sollte das Ergebnis wie folgt aussehen:

image

Wenn Xdebug nicht richtig installier ist, sollte man überprüfen, ob die Pfadangabe und der Dateiname der Xebug DLL in der PHP.INI richtig angegeben sind.

PhpStorm für das Debugging konfigurieren

image

Wir öffnen den Dialog “Edit Configurations”

image

Nun fügen wir eine neue Konfiguration hinzu:

image

Eine PHP Web Application Konfiguration

image

Im Feld unnamed geben wir unserer Konfiguration einen Namen. Zum Beispiel IIS.

Dann müssen wir einen Server auswählen (da wir aber noch keinen Konfiguriert haben, müssen wir zuerst einmal einen neu anlegen).

Hier Dialog zum einrichten eines neuen Server öffnen:

image

Dann im Dialog auf das + um einen neuen Server anzulegen:

image

Hier der bereits ausgefüllte Dialog:

image

Eingabe bestätigen und anschließend folgende Eingaben noch ergänzen, siehe Beschreibung unterhalb der Abbildung.

image

Der Konfiguration einen Namen geben (z.B. LocalIISWordPress)

Und die StartUrl um WordPress ergänzen, so dass der korrekte Link (http://localhost/wordpress) unter der Start URL angezeigt wird.

Das sollte dann so aussehen:

image

Dann bestätigen wir auch diesen Dialog

Und wenn wir nun auf den RUN Button drücken ….

image

Sollte sich der Default Browser mit der WordPress Seite automatisch öffnen.

Eigentlich sollte das setzen von Breakpoint nun auch schon funktionieren, probieren wir das doch mal indem wir einen Breakpoint auf die Zeile phpinfo() setzen die wir in der index.php eingefügt haben.

image

Einen Breakpoint kann man übrigens ganz einfach dadurch setzen, indem man mit der Maus an die Stelle klickt auf die der Rote Pfeil zeigt.

Und wenn wir nun anstelle des RUN Button, den DEBUG Button drücken …..

image

Richtig, der Programmablauf bleibt am Breakpoint stehen und wartet darauf das wir den Programmablauf fortsetzen.

So und nun viel Spaß beim PHP Debugging.

The URL ‚….. for Web project ‚….‘ is configured to use IIS Express as the web server but the URL is currently configured on the local IIS web server.

Die komplette Fehlermeldung die ich erhalten habe lautet wie folgt:

20110622 - IIS Express

Auch wenn dieser Fehler bei arbeiten an einem DotNetNuke Modul aufgetreten ist, kann dieser Fehler in jedem anderen Web Projekt unabhängig von DotNetNuke auftreten.

Was war geschehen.

Ich habe ein laufendes Projekt, von einem Windows 7 Rechner mit Visual Studio 2010 auf dem auch der IIS7 installiert ist, in ein Mercurial Repository gespeichert, und dann später auf einem zweiten Rechner geklont um auf diesem anderen Rechner einige Änderungen vornehmen zu können.

Nach dem Klonen des Projekts musste ich, da der Rechner auf dem ich den Klone erstellt habe, keinen IIS sondern nur den IIS Express installiert hat die Projekteigenchaften dahingehend ändern, dass das Projekt mit dem IIS Express funktioniert.
Was übrigens auch kein Problem war und einwandfrei funktioniert hat.

Bereits zu diesem Zeitpunkt hatte ich mir tatsächlich schon überlegt, ob es zu Problemen führen könnte, wenn ich das Projekt später wieder eingecheckt und dann auf dem ursprünglichen Rechner aktualisiere. Bin aber, da ich neben dem echten IIS auch den IIS Express auf dem ursprünglichen Rechner installiert habe zu der Überzeugung gekommen, dass es keine Probleme geben dürfte, was sich, wie man hier lesen kann nicht bewahrheitete.

Einige Wochen später, natürlich hatte ich mittlerweile vergessen, dass ich eine Umstellung von IIS auf IIS Express vorgenommen hatte, habe ich das Projekt aus dem Mercurial Repository auf dem ursprünglichen Rechner wieder ausgecheckt, bzw. eigentlich nur aktualisiert.

Und nachdem ich mit Visual Studio das Projekt geöffnet habe, kam es zu dem oben beschriebenen Fehler.

Mit der Fehlermeldung konnte ich erst überhaupt nichts anfangen. Dann fiel mir aber ein das ich ja diese IIS Express Änderungen an dem Projekt machen musste um es auf dem auf dem anderen Rechner zum laufen zu bekommen.

Das eigentliche Problem bei diesem Fehler ist, dass sich das Visual Studio Projekt nicht mehr öffnen lässt und daher auch keine Einstellungen geändert werden können. So dass man nicht einfach die Verwendung des IIS Express wieder ausschalten kann. (Ich hätte natürlich händig auch den IIS Express konfigurieren können, das hätte vermutlich auch geholfen)

Ich habe dann folgende Lösung entdeckt, und möchte diese für mich und gegebenenfalls auch für andere die ein solches Problem haben hier veröffentlichen, damit man,  wenn ein solches Problem wieder auftritt diese Lösung wieder finden kann und nicht wieder nach einer Lösung suchen muss.

So nun aber zur eigentlichen Lösung des Problems:

In der Konfigurationsdatei [Projektname].vbproj.user befindet sich unter der Region PropertyGroup folgende Einstellung:

<PropertyGroup>
       <UseIISExpress>true</UseIISExpress>
</PropertyGroup>

Diese Einstellung ändert man auf false, speichert die Datei, macht ein Reload der Projektdatei.

Und fertig.