Debuggen mit FirePHP

Ich versuche schon seit längerer Zeit das Debug-Plugin zum Laufen zu bringen. Leider ohne Erfolg. Die Plugins Log, Debug, Benchmark und BenchmarkEvents sind installiert und aktiviert. FirePHP 0.7 und auch 1.0 Beta wurde ausprobiert. Ohne Erfolg. Bei aktiviertem FirePHP lässt sich keine Seite mehr aufrufen und das Netzwerkmodul in FireBug meldet “aborted”. Kennt jemand das Problem bzw. hat jemand eine Lösungsidee?

Bei mir ging es lokal auch nicht und große Lust hatte ich auf Firefox eh nicht. Du hast zwei Möglichkeiten: 1. Installier einfach selber ChromePhp und pack in die shopware.php im root ein require_once. 2. Um richtig professionell debuggen und arbeiten zu können, solltest du xdebug installieren (bei MAMP / XAMP ist das dabei) und das für deine IDE konfigurieren. Das ist wirklich ein Game Changer und bringt dich wirklich up-to-speed. Außerdem verstehst du so schneller was unter der Haube von Shopware vor sich geht.

1 „Gefällt mir“

Hallo zusammen, ich würde das Thema gerne nochmals aufgreifen. Der Vorschlag mit xdebug ist okay, doch ich möchte eigentlich meine Live Installation testen und da gibt es nun mal keinen xdebug. Prinzipiell funktioniert bei mir das Debuggen mit FirePHP. Nur sobald ich die Artikelkategorien anzeigen lassen möchte steigt Firefox aus. Ich habe von diesem Problem auch schon hier bei Shopware 3 gelesen. Hat jemand eine Idee an was das liegen könnte? Grüße sunflower PS: ChromePHP kannte ich bislang noch nicht, werde ich mir mal ansehen.

Also lokal funktioniert das Debuggen mit FirePHP bei mir. Ich habe mal alternativ die Ausgabe im Debug-Modul auf ChromePHP umgeleitet. Hier bricht es an einer bestimmten Stelle ab. Ich tippe einfach mal, dass es an der Größe der Daten liegt. Ich habe diesbezüglich mit einem der Shopware-Entwickler geredet. Demnächst soll eine Developer-Toolbar veröffentlicht werden, die sämtliche Debug-Funktionalitäten übernimmt. Ich warte einfach mal ab. Vielleicht hat sich mit etwas Glück ja bei der 4.1 etwas in dem Bereich getan… LG Marcus

Mittlerweile ist Shopware 4.2.2 draußen und auch während den Schulungen wurde uns zu dem Debug Plugin geraten. Aber nach wie vor funktioniert es für Firefox nicht. (Fehler: Verbindung unterbrochen)Hat jemand diesbezüglich aktuelle Informationen? Auffällig ist, dass der Fehler nicht bei allen Seiten auftritt. Die Startseite z.B. funktioniert, die Produktdetailseite dagegen nicht.

Ich hatte in der Template Schulung auch gesagt bekommen, dass ich mit FirePHP arbeiten soll und brauche die Informationen zur Templateentwicklung auch dringend. Zunächst hat das ganze auch wunderbar funktioniert, aber nach etwa zwei Wochen reibungsloser Arbeit, kam auch bei mir plötlich von einen Tag auf den anderen „Verbindung abgebrochen“ Nach dem ersten Schock, Anschuldigungen gegen den Serverbetreiber und grenzenloser Panik fiel dann auch mal auf, dass das Problem nicht mehr auftaucht, wenn FirePHP deaktiviert ist. Dann habe ich natürlich mal getestet, ob es bei den Shops die voher reibungslos mit FirePHP gearbeitet haben, auch zu dem Fehler kommt. Kann ja sein, dass man sich mit irgendeinem Plugin oder sonstwas die Funktion zerschossen hat. Aber leider funktionierte das ganze von da an in keinem Shop mehr. Reinstallation des kompleten Browsers inklusieve Plugins und Einstellungen und was weiß ich nicht alles, brachte auch nichts. Das systemathische Testen von Versionskombinationen, die vorgeblich in Kombination stabil gelaufen sind, brachte mich auch nicht weiter. Und jetzt verzweifel ich langsam, weil mir die Ideen ausgehen, wie ich dieses Plugin zum laufen bringen soll. Gibt es schon irgendwen der das Problem gelöst hat?

Ihr könnt euch die Variable auch mit smarty ausgeben lassen. Das ist erst mal eine Notlösung. Der Shop sollte dafür in den Wartungsmodus oder besser noch nicht live sein. http://stackoverflow.com/questions/2431 … p-var-dump

Das ist zwar eine nette Idee, aber in meinem Fall, kenne ich meist den Inhalt den ich suche und will wissen, wie die Variable heißt, mit der ich das ausgebe. Zum Beispiel wollte ich den Header Kategorieabhängig ändern. Dafür habe ich das Bildfeld, das im Backend für eigene Templateanpassungen angeboten wird befüllt und in der Listenansicht rausgesucht wo der Wert drinsteht. Dann habe ich den Rest der Listenansicht gestyled und am nächsten Tag funktionierte irgendwann das Plugin nicht mehr. Jetzt weiß ich nicht, wie ich den gleichen Wert auf der Detailseite bekomme. Ich bräuchte also eher eine Art Funktion, die alle verfügbaren Variablen Dropt. Da ich selten Templateanpassungen in Livesystemen mache, könnte ich auch mit einer Notlösung leben, die das ganze wirklich als Text ausgibt. Falls es eine öffentliche Liste der Templatevariablen gibt, die ich bislang immer übersehen habe, wäre mir damit natürlich auch erstmal geholfen. EDIT: Zu Testzwecken habe ich mal versucht wieder eines der Standadtemplates anzuwählen, da dies ja das Einizige ist, was ich verändert habe. Leider brachte das nicht den gewünschten Erfolg. Danach habe ich mir den Laptop einer Kollegin ausgeliehen, FireBug und FirePHP installiert (in der gleichen Version, wie auf meinem Rechner) und siehe da die gleichen Shops geben plötzlich Informationen über ihre Templatevariablen raus. Es muss sich also um eine Art Wechselwirkung mit irgendetwas anderem handeln, dass offensichtlich nicht nur ich zum Arbeiten brauche. Da der Rechner meiner Kollegin sehr rudimentär ausgestattet ist, kann ich leider nur schwersagen, was in Frage kommt, da die Liste der Programme, die ich intalliert habe und sie nicht äußerst lang ist.

Hallo, ich hänge mich hier mal dran … Arbeite gerade an einem Plugin für die 4.2.1 Version. Firebug / FirePHP sind installiert und aktiv. Plugin „Log“ ist - nach meinem Verständnis - ja nun in den core-root umgezogen, kann es nicht mehr manuell aktivieren. Logs werden jedoch brav in die s_core_logs geschrieben. Plugin „Debug“ ist aktiv, alle Häkchen bei den Einstellungen gesetzt. Bei Fehlern im Plugin wird jedoch nur „…konnte nicht erfolgreich installiert werden“ ausgegeben, jedwege Debug-Ausgabe (Log,Trace,…) verweigert den Dienst. Hat jemand mit der gleichen Version eine Lösung ? Mit den 4.1.x Versionen lief das problemlos im ersten Take. Gruss, Tobias

Entschuldigt die etwas „generische“ Antwort, aber mir hat folgendes geholfen: http://wiki.shopware.de/Einrichtung-und … _1067.html 1:1 befolgt. xDebug ist wie bereits erwähnt eine Gamechanger, Breakpoints setzen und alles in der IDE debuggen - einfach ein Traum. Die Developertoolbar habe ich auch erst jüngst kennengelernt: http://store.shopware.de/administration … lertoolbar Ebenfalls außerordentlich hilfreich, insbesondere wenn man mehrere Plugins hat, die sich auf dieselben Events/Hooks registriert haben. Debug Plugin + FirePHP ist nützlich, wenn man nach bestimmten Templatevariablen sucht. Lokal wie Remote einfach installiert und es lief. Wichtig ist evtl darauf zu achten, dass keine/eure IP in dem Plugin eingetragen ist. @buchhenne: Was sagen die Logs? unter /logs/ hat man meist recht vielsagende Fehlermeldungen, IP im Plugin eingetragen, Cache geleert? (das übliche… :wink: ) Grüße, Ruben

1 „Gefällt mir“

@Netzturm: xDebug scheint eine gute Variante zu sein, obwohl ich wirklich gerne mit der Fire-PHP Variante arbeiten möchte… in den Logs ist nichts aussagekräftiges dabei - der Plugin Manager catched den Fehler wohl…

Mittlerweile funkt Xdebug fein (lohnt sich auf jeden Fall, das aufzusetzen), jedoch schaffe ich es immer noch, Doctrine-Fehlermeldungen zu generieren, die anscheinend nicht seitens Xdebug ausgewertet werden. Kann jemand dieses Verhalten bestätigen und hat evtl. einen Lösungsansatz zur Hand ? Update: Warum wirft Doctrine bei Verwendung der create() Funktion der …\Components\Api\Resource\Article.php diesen Fehler: “Entity has to be managed or scheduled for removal for single computation” … Dies deutet doch darauf hin, dass mit flush() / persist() etwas nicht stimmt, aber dies ist in der Article.php korrekt implementiert … Code: $articleResource = \Shopware\Components\Api\Manager::getResource(‘Article’) $article = $articleResource->create($minimalTestArticle); $minimalTestArticle scheint korrekt, zumindest werden sämtliche im Array enthaltenen Daten in die Datenbank geschrieben und sind auch im Backend sichtbar Update: Wenn jemand erfahreneres nur kurz anmerken könnte, ob die Verwendung der internen API für diesen Zweck überhaupt eine gute Idee ist, wäre mir sehr geholfen …

… ich antworte dann mal selber: funktioniert genau so, muss jedoch von der Orchestrierung her abgestimmt sein, die interne API bereits bei der install Methode zu verwenden, war keine gute Idee …