Typo3 Flow XDebug

Typo3 Flow ist ein mächtiges Framework und ich muss sagen, es macht echt Spaß damit zu arbeiten. Allerdings ist das Debuggen etwas umständlich. Entweder, man debuggt die Proxy Klassen, dafür muss man aber immer vom POI (Point of Interest) weg oder man erstellt ein Mapping.

Sebastian Kurfürst von Sandstorm Media hat einen Pfadmapper umgeschrieben, der das Mapping für Flow übernimmt. Dazu gibt es auch ein Tutorial von ihm. Dabei werden die Debug Kommandos die die IDE und XDebug austauschen auf die Pfade angepasst. Dass heisst ihr könnt in euren Klassen Haltepunkte setzen und diese werden dann auch angesprungen.

Wenn ihr alle Daten auf eurem System habt und auch der Webserver lokal läuft ist das alles kein Problem, es funktioniert wunderbar.

Typo3 Flow xDebug auf einem Remoteserver

Problematisch wird es erst, wenn die Daten und dem Webserver extern sind. Der PathmappingProxy wird lokal ausgeführt und dieser verbindet sich dann mit xDebug auf dem Server. Man wird aber feststellen, dass das Mapping so nicht funktioniert. Da im Pathmapper von der Server Flow Uri ausgegangen wird, die aber nicht zwangsläufig mit der Datenbasis URI in der IDE übereinstimmt. Der Pathmapper schaut aber nach, ob er auf die Datei zugreifen kann. Kann er das nicht, kommt kein Mapping zustande. Wir müssen also dem Pathmapper noch die lokale Pfadangabe übergeben, damit er prüfen kann, ob die Datei existiert.

Dazu habe ich in dem Debugproxy von Sebastian einen weiteren Parameter eingefügt. Mit dem Parameter kann man nun den Lokalen Pfad mit übergeben. Wichtig ist dabei, dass dies momentan nur im LAN funktioniert, da ich nach wie vor einen Filezugriff auf die Daten benötige. Ich prüfe jetzt nur noch zusätzlich, ob die Proxydatei unter der übergebenen BaseURI + Pfad existiert. Diese können nur auf dem Server selber existieren, da sie zur Laufzeit geändert werden.

Mein Aufbau ist also wie folgt:

Dedizierter Entwicklungsserver im LAN mit Dateifreigabe
Netbeans IDE am Entwicklerrechner (Netbeans arbeitet mit der Datei freigabe)
Debugproxy.php auf dem Entwicklerrechner mit „lokaler“ Pfad übergabe (z.B. als Netzlaufwerk) -b Argument

Ich starte also die Debugproxy.php lokal mit

php pfad/zum/proxy/debugproxy.php -f -c Development -b V:/Flow

V:/Flow steht für mein Netzlaufwerk mit meinem Projekt zum Debug.
Sollte aus irgendeinem Grund die Möglichkeit der Dateifreigabe versagt sein, kann man auch FTP verwenden. Das Argument ist -r gefolgt von den FTP Daten zusätzlich gibt man mit dem -b Argument den ServerPfad zum Projekt an:

php debugproxy.php -f -d -c Development -b /var/www/flow -r flow.intern;user;pass

Ich hoffe dies hilft dem einen oder anderen weiter 🙂

Und hier der gepatchte DebuggerProxy:

git clone https://github.com/mrwhy-orig/debugproxy.git

 

2 Gedanken zu „Typo3 Flow XDebug“

  1. Hallo

    Ich würde das so gerne mit folgenden Setup zum laufen bringen:

    – TYPO3 Flow 2.2
    – auf einer VirtualBox (Vagrant) mit Ubuntu
    – PhpStorm auf Windows mit SSH Verbindung auf Server

    Xdebug läuft soweit mit meinem System.
    Aber ich verstehe nicht genau was ich hier noch umstellen könnte.

    Bei meinen Untersuchungen ist mir auch aufgefallen das bei mir in PhpStorm der Port 9001 als Standard ist und nicht 9010. Und Ich benutze einen SubContext.
    Deswegen habe ich mal etwas rumgespielt:

    php debugproxy.php -f -d -c Development/SubContextLocal -b /var/www/oqm -p 9001

    Dies habe ich auf dem Server ausgeführt.

    Aber über die Zeile:
    „if (socket_select($toRead, $write = null, $except = null, 10) < 1) {"
    kommt es schon nicht!

    Grüße
    Kim

    1. Hi Kim,

      auf welchem Port läuft denn dein xDebug auf der VM? Ist es Port 9000 wie es von dem Skript per default angenommen wird, oder hast du ihn auf 9001 gesetzt um mit PHPStorm in anderen Projekten direkt debuggen zu können?

      Grüße

      Björn

Schreibe einen Kommentar

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