Xdebug unter Mamp Pro 1.9.5 einrichten, damit einwandfreies Debugging möglich ist. Gerne per Teamviewer.

Hi jepster,
definitiv problemlos ist die Installation XAMPP für MacOs und Netbeans einschl. debugger.

In php.ini folgendes ergänzen:

[XDebug]
;; Only Zend OR (!) XDebug
zend_extension_ts=”C:\xampp\php\ext\php_xdebug.dll”
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.profiler_enable=0
xdebug.profiler_output_dir=”/Applications/XAMPP/tmp”

Apache restarten und schon sollte Alles laufen

Viele Grüße
Jörg

Danke für deinen Post. Aber MacOS ist nicht Windows. Du kannst dir sicher sein, dass ich bereits viel Zeit investiert habe und es durchaus problematisch ist, Xdebug innerhalb von MAMP so einzurichten, dass man damit debuggen kann.

oh sorry, ich habe die Änderungen in php.ini aus dem Internet kopiert, auf dem MAC muss es heissen

zend_extension_ts=”/Applications/XAMPP/php/ext/php_xdebug.dll”

Viele Grüße
Jörg

Hallo.

Garantiert nicht. Wenn, dann xdebug.so.

@jepster Probier das mal: http://kwnetzwelt.net/wordpress/archives/381
Ich wollte gestern auch "noch schnell" xDebug einrichten, habs jedoch selbst kompiliert. Mit dem Ergebnis, dass die Erweiterung von Apache nicht geladen werden konnte :)

Hi,

Gib mal in der Console php -m ein um sicher zu gehen,
dass das xdebug modul von php korrekt geladen wurde.
Sie auch mal in den error logs von apache nach.

@undpaul
Diese erweiterung wird von php geladen, nicht von Apache.

Hihi ... kannst ruhig "stBorchert" schreiben :)

Ja, stimmt. Aber der Fehler wird im apache-Errorlog protokolliert :D

Wenn xdebug geladen ist, wird das auch über php -i | grep xdebug angezeigt. Wenn da nix kommt, dann ist die Extension nicht geladen (so wie bei mir gestern :/ ).

 Stefan

Habe ich eingegeben. Xdebug wird nicht angezeigt. Wobei es ja Mehrere PHP-Versionen auf einem MAMP-System gibt:
1, Die (alte) PHP-Version die MacOS beiliegt.
2., PHP 5.2.x
3., PHP 5.3.x

Sodass wohl die MacOS-PHP Version im Include Path steckt, welche ja nicht für die Verarbeitung unter MAMP verantwortlich ist. Mit phpinfo(); bekomme ich allerdings die Info, dass Xdebug geladen wurde. Damit debuggen kann ich allerdings nicht.

Habe nachgesehen. Davon ist dort nichts zu sehen.

bringt mir

Zeigt mir ebenso wie phpinfo(); an, dass Xdebug geladen ist. Der selbige Interpreter ist bei Netbeans eingestellt. Ich kann sowohl mit der xdebug.so von Komodo und der, die bei MAMP enthalten ist (die ist von der Dateigröße doppelt so schwer) keine Verbindung mit Netbeans aufbauen.

Wichtig: Wenn sich jemand definitiv sicher ist, das über eine Teamviewer-Sitzung lösen zu können, dann steht mein Angebot mit der Vergütung weiterhin.

Ich hab das gerade mal ausprobiert - hab hier MAMP 1.9.5 mit PHP 5.3.5 laufen.

Aktivierung der Extension in der php.ini:

Die xdebug.so stammt aus dem Standard-MAMP Paket - Download xdebug.so

Neustart Apache / MAMP - in der phpinfo() sollte ein Abschnitt, wie im Screenshot zu sehen sein.

Testen der Konfiguration über einfaches PHP-Script, welches versucht Verbindung zum Debugger aufzubauen:

Aufruf des Scripts über die Konsole:

Hier sollte dann nach einiger Wartezeit eine Verbindung zustande kommen.

Konfiguration von Netbeans nach Screenshot.. Hier muss auch die korrekte PHP Runtime und der Remote-Port eingetragen sein !

Zeitaufwand ca 0.5 Stunden :) - läuft auch nach Neustart noch wundervoll ...

SteffenR

Hallo,

danke für die Posts.

Es ist schön, dass ihr mir helfen wollt. Aber ich komme weiterhin leider nicht weiter.

Wenn ich mittels phpinfo(); nachsehen will, ob Xdebug geladen ist, so erhalte ich dort einen Block zu Xdebug. Ähnlich wie in SteffenRs Screenshot. Mit

bekomme ich auch die Info, dass das Modul geladen ist. Wenn ich mit dem PHP-Code, von dir SteffenR, die Verbindung zu Xdebug testen will, dann erhalte ich damit selbst nach 30 Minuten keine Verbindung. Egal ob mit Port 9000 oder Port 9010 im Test-Code sowie in der betreffenden php.ini. Selbstverständlich bekommt auch Netbeans weiterhin keine Verbindung. Auch der versuchsweise Austausch der xdebug.so, die du freundlicherweise hochgeladen hast, zeigt keinen positiven Effekt.

@stBorchert: Hast du die Konfiguration bei dir mittlerweile geschafft? Wolltest es ja am Abend testen.

»Möglicherweise« funktioniert es bei mir, wenn ich es auf die grobe Tour mache und MacOS neu installiere. Aber es kann nicht sein, dass dieser Weg gerechtfertigt ist, wenn das Problem nur mit den Dateien innerhalb von MAMP zutun haben soll.

Hat jemand von euch weitere Vorschläge, was ich tun könnte, um das Problem zu lösen? Weis jemand, wie man unter MacOS prüfen kann ob Port 9000 oder 9010 von anderen Programmen belegt sind und wenn ja, von welchen?

Danke im Voraus für eure Mühe!

Firewall checken, mit netstat schauen welche Ports benutzt werden, einfach mit telnet auf den Port zugreifen, ...

Es ist mir nichts davon bekannt, dass ich unter MacOS eine Firewall installiert hätte. Ist da von Haus aus etwas konfiguriert? Kennst du aus dem Stegreif den betreffenden Telnet Befehl?

D.h. ja nicht, dass es schadet entsprechend mal nachzuschauen ob nicht doch die FW aktiv ist.

Der Telnet-Befehl heißt telnet und Details erfährt man wie auf nem Unix-System üblich über die man-Page ("man telnet").

Hallo,
um auf MAC OS nachzusehen ob der debugger am Port
9000 hört:

Dann solltest du so etwas sehen:

Mach es am besten so:
1. Schau mit netstat nach welcher Port noch nicht belegt ist.
2. Dann stellst du XDebug auf den freien Port ein.
3. Apache neustart
4. nochmal netstat um zu sehen ob an diesem Port gehört wird (LISTEN)

Sollte es dann immer noch nicht klappen hast du warscheinlich eine Software Firewall
oder ein ähnliches Security Tool im System.

Gruss

Mit

bekomme ich nur das hier

Habe unter http://snippets.dzone.com/posts/show/5712 jedoch eine Alternative gefunden:

Damit sehe ich weder in der Spalte PID, dass eine Port-ID 9000 oder 9010 belegt ist noch das irgendwo :9000 oder :9010 indem ich

an den Befehl hänge.

Hi,

ich würde hier eher annehmen, dass die PID
die Prozess ID ist und keine Port Nummer.
Ich habe allerdings keinen MAC.

LG

Hi,

meine jetzt zu wissen woran es liegt. Xdebug ist mit der Version der Zend Engine API nicht kompatibel. Die Version der xdebug.so die bei MAMP dabei ist (!!!) sowie die Version von Komodo (= http://code.activestate.com/komodo/remotedebugging/) werden beide mit einer nahezu gleichen Fehlermeldung gemängelt. Nur die Nummer neben »version« ist etwas anders. Wenn ich also php -v oder drush eingebe, erhalte ich die Meldung

Nun habe ich auf beim FAQ von Xdebug einen Hinweis darauf gefunden, dass ich Xdebug selber kompilieren sollte. Das habe ich jedoch bereits versucht und da gibt es Probleme mit phpize.

Ich will also den Xdebug-Wizard unter http://xdebug.org/find-binary.php befolgen.

1., Paste den Output von phpinfo(); in das Textfeld
2., Komme auf eine Seite wo ich

sehen sollte, wenn ich

in die Konsole eingebe. Die bei mir ausgegebenen Zahlen stimmen jedoch nicht mit den angezeigten überein:

Es sollte stattdessen laut Wizard folgendes angezeigt werden:

Führe ich

oder

in der Konsole aus, erhalte ich nur

Ich befinde mich wohlgemerkt im Verzeichnis von den entpackten Xdebug Source-Dateien. Wobei ich auf dem gesamten System eben nur die zwei genannten phpize Dateienhabe.

Fazit: Es ist mir also unmöglich, die richtige Xdebug Version zu kompilieren, weder Xdebug auf irgendwie zu recherchierende Weise zu installieren. Xdebug ist ein krass zusammen gebastelter Rotz - den sich kein Dienstleister zu supporten traut. Danke liebe verkonfiguriert verbastelte OpenSource-Welt.

Hi nochmal,
ich hatte genau die gleichen Probleme unter Win32
mit xdedug,
Kann Dir leider nicht mehr genau sagen wie ich das gelöst habe,
Aber grundlegend lag es daran dass ich 32 bit und 64 bit Module
gemischt hatte.
Ich konnte das alles jedenfalls erst lösen indem ich alles auf 32 bit hatte
die Fehlermeldungen waren gelcih (Zend API requires blah ....).

Hoffe das hilft Dir weiter.

BTW:
Ich verwende Eclipse + XAMPP

Hab mir ne eigene xdebug.so Datei laut dem 64Bit-Tutorial von http://www.netbeans-forum.de/viewtopic.php?f=30&t=3166 kompiliert, aber nach dem Neustart ist genauso tote Hose wie vorher. Mit php -m habe ich das Modul nicht. Das Xdebug hat mal funktioniert: ohne Kompilierung. Ich werde wohl auf den Zend Debugger umsteigen müssen. Hoffe da ist besser vorausgedacht worden als bei Xdebug, sodass die Software benutzbarer und weniger zeitintensiv ist.

Schade dass es nicht geklappt hat.
Wenn Du xdebug auf 64 bit kompilierst muss ALLES 64 bit sein.
PHP und alle PHP Module 64 Bit, Apache 64 Bit, C Runtime 64 Bit.
Ein Mix funktioniert da nicht.
Ich hatte das erst hinbekommen (unter Windows7 64 Bit) als alles 32 Bit war.

Gruss

Liebe Community,

erstmal herzlichen Dank für euer Mitlesen und das Austauschen eures Expertenwissens.

Ich bin nochmal alle php.ini Einstellungen durchgegangen und habe die xdebug.so von Komodo benutzt (weiter oben im Thread mehrmals erwähnt). Anschließend habe ich den Rechner neu gestartet. Die für Xdebug relevanten php.ini-Einstellungen sehen bei mir momentan so aus:

Zudem ist es halt wichtig, dass man die Projekt Properties und die PHP-Einstellungen von Netbeans korrekt einstellt. Dazu den Projektnamen mit rechter Maustaste anklicken, im Kontextmenü »Properties« wählen und da unter »Run Configuration« die Project URL bestimmen. Bei mir steht da nur http://mein-projekt (nutze MAMP Pro Vhost).

Dann halt noch in den Netbeans-Einstellungen das PHP-BInary als PHP-Interpreter bestimmen. Bei »Open Result« ist bei mir nur »Output Window« ausgewählt. Sobald ich debugge, öffnet sich das Browserfenster. Doch selbst wenn ich »Output Window« unausgewählt lasse, öffnet sich immer das Browserfenster.

Habe dann testweise den MacGDBp laufen lassen, welcher die Debug-Session startet, sobald der PHP-Interpreter startet. Ein sehr primitiver Debugger ohne Breakpoints - für Drupal-Projekte kann man ihn vergessen. Als ich testweise meine Drupal-Seite auf meinem lokalen Webserver aufgerufen habe, ging MacGDBp mit. Somit habe ich gesehen, dass Xdebug tut. Zunächst habe ich eine Test PHP-Datei mit Netbeans aufgerufen, aber Netbeans konnte wiedermal keine Verbindung aufbauen. Versuchsweise habe ich dann eine .module-Datei aus meinem Drupal-Projekt ausgewählt und den Debugger gestartet - zack - der Debugger ging mit.

Jetzt hoffe ich, dass der Debugger auch weiterhin funktioniert und ich seine Funktionen stressfrei erkunden kann.

Eins noch: ich habe auch Eclipse mit PDT sowie Zend Studio ausprobiert. Diese Programme sind unglaublich überladen. Netbeans ist bezgl. der Übersichtlichkeit seiner Oberfläche ein wahrer Segen...