In PHP war das Debugging noch nie eine einfache Angelegenheit. Wenn der zu untersuchende Code auf einem entfernten Server lief, welcher sich hinter einer Firewall / NAT verbirgt, wurde es noch ein Stückchen komplizierter.
Wunderbar dass es mit TYPO3 Flow noch ein wenig komplexer wird, als es bereits sowieso schon ist. Der Grund liegt ganz einfach an der Tatsache, dass TYPO3 Flow für eure Services, Controller und anderen Klassen sogenannte Proxy Klassen generiert, welche dann zur Laufzeit ausgeführt werden.
Dies bedeutet, dass ein Breakpoint innerhalb der IDE im UserController auf der indexAction (z.B. Zeile 18) im später generierten und ausgeführten Proxy mit dem ungefähren Namen “UserController_Original” eine ganz andere Zeile ist. Das führt dazu dass z.B. PHPStorm bei einem Breakpoint entweder gar keine Reaktion zeigt oder das Debugging mit einer Fehlermeldung endet.
Lösung: DebugProxy
Ein DebugProxy schaltet sich zwischen eurer IDE und dem xDebug Protokoll und ist in der Lage, Zeilennummern und Dateipfade für TYPO3 Flow zu mappen.
Im besten Fall arbeitet der DebugProxy völlig transparent ohne das die IDE oder man selbst etwas davon mitbekommt.
Eines dieser DebugProxy Scripte war der debugproxy von sandstorm mitte 2012, welcher im April 2013 noch für TYPO3 Flow 2.0 angepasst wurde, mit den aktuellen Versionen jedoch nicht mehr zu funktionieren scheint.
https://github.com/sandstorm/debugproxy
Inzwischen gibt es jedoch vom User dfeyer auf GitHub einen neueren und deutlich schnelleren DebugProxy geschrieben in Googles Programmiersprache GO zum Download.
https://github.com/dfeyer/flow-debugproxy
Mein Setup (PHP 5.6, Debian 8, TYPO3 Flow 3.0)
Installation von GO und setzen der benötigten Go-Pfade
apt-get install golang export $GOPATH=/usr/local/go export $GOBIN= export $GOROOT=/usr/lib/go
Setup des DebugProxy Scripts
cd /usr/local/go/src # GitHub Repo klonen git clone https://github.com/dfeyer/flow-debugproxy.git cd /usr/local/go/src/github.com/dfeyer/flow-debugproxy # Go Dependencies & Build go get go build
Nun haben wir das flow-debugproxy Go Script bereit zur Ausführung:
/usr/local/go/bin/flow-debugproxy --xdebug 127.0.0.1:9000 --ide 127.0.0.1:9010 --vv
Remote Server / Firewall / NAT ?!
Eine der wohl einfachsten Lösungen dieses Problems ist ein SSH-Tunnel von eurem lokalen Rechner auf dem PHPStorm läuft zum entsprechenden Remote-Server.
SSH-Tunnel auf OS X öffnen
ssh user@host -p 22 -R9010:127.0.0.1:9010
Hier wird eine SSH Sitzung gestartet welche den lokalen Port 9010 auf den Remote-Server Port 9010 tunnelt.
Auf dem Remote-Server lauscht auf Port 9010 nun der (vorher gestartete) DebugProxy von dfeyer, welcher die Daten an xDebug (welcher an Port 9000 lauscht) weitergibt bzw. zuvor ein Path-Mapping vornimmt.
Weitere Informationen / Links
Flow DebugProxy Script von dfeyer: GitHub: dfeyer/flow-debugproxy
Altes DebugProxy Script von sandstorm: GitHub: sandstorm/debugproxy
Hilfreiches Gist: https://gist.github.com/michaelgerdemann/7a4e2f5315c19ff6f896
Edit:
Mittlerweile gibt es auch auf discuss.neos.io einen entsprechenden Beitrag zu dem Thema:
Neos.io: how-to-debug-a-flow-application-with-xdebug-and-phpstorm
Nachtrag: PHPStorm / xDebug / DebugProxy
Folgendes Setup auf einem MacBook mit MAMP (Free)
xDebug Einstellungen in der php.ini
[xdebug] zend_extension="/Applications/MAMP/bin/php/php5.6.10/lib/php/extensions/no-debug-non-zts-20131226/xdebug.so" ; Achtung! Pfad muss angepasst werden! xdebug.remote_autostart=1 xdebug.remote_enable=1 xdebug.remote_host=127.0.0.1 xdebug.remote_port=9000 xdebug.idekey=phpstorm-xdebug
flow-debugproxy starten
Nachdem der flow-debugproxy von dfeyer in Go kompiliert wurde, können wir diesen nun starten:
./flow-debugproxy –v (Pfad: /Users/…./go/bin)
PHPStorm Einstellungen
