Conrad: PHP debuggen, die mit Ajax Daten liefert

Hallo,

ich übergebe mit Ajax, mehrere Paramater an eine PHP-Seite die die Daten verarbeitet und die Ergebnisse zurück liefert. Da diese PHP-Seite nicht zu sehen ist, wie kann ich meine Daten in dieser Seite verfolgen? Bisher habe ich einfach echos an den relevanten Stellen eingebaut und konnte somit kontrollieren was geschah. Das geht natürlich jetzt nicht mehr. Was kann ich statt dessen tun?

Gruss Conrad

  1. Hallo,

    Was kann ich statt dessen tun?

    z.b. mit log-Dateien arbeiten.

    Gruß
    Kalk

  2. Tach!

    Da diese PHP-Seite nicht zu sehen ist, wie kann ich meine Daten in dieser Seite verfolgen? Bisher habe ich einfach echos an den relevanten Stellen eingebaut und konnte somit kontrollieren was geschah. Das geht natürlich jetzt nicht mehr. Was kann ich statt dessen tun?

    Weiter echos verwenden (oder var_dump(), wenn es genauer sein darf). Und dann die im Browser eingebauten Werkzeuge verwenden, Richtung Netzwerkanalyse gehen und das vom Server gesendete Paket anschauen. Auch kann man das XHR-Objekt die vom Server gesendeten Daten entgegennehmen und per console.log() ausgeben.

    dedlfix.

  3. Was kann ich statt dessen tun?

    pl nutzt die Entwicklerkonsole. Zum Debuggen schmeiße ich serverseitig eine Ex und sende den dazugehörigen Dump mit HTTP-Status 502. In der Entwicklekonsole ist das dann sehr gut zu sehen und ausgesprochen hilfreich.

  4. Liebe(r) Conrad,

    ich habe mir eine Debug-Funktion geschrieben, die beliebig viele Parameter annimmt, um ihre String-Repräsentation in eine Textdatei zu schreiben:

    function debug () {
    	$arg_list = func_get_args();
    
    	foreach ($arg_list as $v) {
    		file_put_contents(
    			__DIR__.'/debug.txt',
    			(
    				is_string($v)
    				? $v
    				// true = no immediate output to browser
    				: print_r($v, true)
    			),
    			FILE_APPEND
    		);
    	}
    }
    
    // use
    debug("ein Array: ", array('key' => 'value'), " und noch anderes Zeuch\r\n");
    

    Der Inhalt von "debug.txt" ist dann meist sehr hilfreich...

    Liebe Grüße,

    Felix Riesterer.

  5. Was kann ich statt dessen tun?

    Neben den bereits genannten Ansätzen: das error.log des Webservers sollte man eh immer im Blick haben. Ohne Gewähr, da ich keine Ahnung von PHP habe: aber auch da soll man wohl reinschreiben können.

    Ausnahmsweise aber, halte ich h... ähem, pls Lösung für die Elegenteste.

    1. Ausnahmsweise aber, halte ich h... ähem, pls Lösung für die Elegenteste.

      Da ich nicht mehr editieren durfte, hier noch folgender Nachtrag:

      Ob eine Exception für einen Debug passend ist, sei mal dahingestellt. Aber direkt mit der Fehlerkonsole des Browsers zu sprechen, ist schon sehr charmant.

      1. Ausnahmsweise aber, halte ich h... ähem, pls Lösung für die Elegenteste.

        Da ich nicht mehr editieren durfte, hier noch folgender Nachtrag:

        Ob eine Exception für einen Debug passend ist, sei mal dahingestellt. Aber direkt mit der Fehlerkonsole des Browsers zu sprechen, ist schon sehr charmant.

        Viel wichtiger isses, den Dump in text/plain auszugeben. Und was untentdrunter liegt:

        Sämtlicher Code wo den Puffer für die Response befüllt (DB-Zugriffe, Benutzereingaben u.u.u.) liegt in einem try{}-Block. Der catch{}-Block sorgt für den o.g. Content-Type und dafür, dass der Ex-Text rausgeht, ggf. mit einem Trace. Einen Trace sollten natürlich nur die Entwickler sehen, nicht jedoch die normalen Besucher.

        Ins Log gucke ich schon lange nicht mehr, das ist viel zu aufwändig. Gezielt Loggen würde ich nur noch, wenn ich einem Fehler nicht anders auf die Spur kommen könnte. Mit der beschrieben Vorgehensweise habe ich jedoch bis jetzt JEDEN Bug gefunden, vor allem auch die Bugs die von besonders schlauklugen Kollegen fabriziert wurden.

        Was da z.T. an Code zum Vorschein kam, das war einfach nur grausig.

        1. Ins Log gucke ich schon lange nicht mehr

          Falls Du tatsächlich vom error.log Deines Webservers sprichst: dann begehst Du einen großen Fehler.

          1. Ins Log gucke ich schon lange nicht mehr

            Falls Du tatsächlich vom error.log Deines Webservers sprichst: dann begehst Du einen großen Fehler.

            Ich habe gar kein error.log wozu auch.

            1. Ich habe gar kein error.log wozu auch.

              Evtl. deshalb, weil das der Weg ist, mit dem der Webserver seine Diagnose- und Fehlerinformationen mitteilt?

              1. Ich habe gar kein error.log wozu auch.

                Evtl. deshalb, weil das der Weg ist, mit dem der Webserver seine Diagnose- und Fehlerinformationen mitteilt?

                Das kommt mir irgendwie bekannt vor, in soner Firma war ich auch mal, da wurden Fehler einfach nur geloggt, anstatt sie zu beheben. Es kam, was kommen musste, das errorlog war größer als das accesslog und der CTO begann, sich für das errorlog zu interessieren. Er hat noch vor mir die Firma verlassen ;)

                --
                Bulle: Wie issn das passiert? Fahrzeugführer: Keine Ahnung, hab grad telefoniert.
                1. Hallo

                  Ich habe gar kein error.log wozu auch.

                  Evtl. deshalb, weil das der Weg ist, mit dem der Webserver seine Diagnose- und Fehlerinformationen mitteilt?

                  Das kommt mir irgendwie bekannt vor, in soner Firma war ich auch mal, da wurden Fehler einfach nur geloggt, anstatt sie zu beheben.

                  Was hat das miteinander zu tun? Das error.log ist ein Werkzeug, um Fehlern auf die Spur zu kommen. Dass das in deiner ehem. Firma nicht zur Behebung der Fehler genutzt wurde, liegt nicht am Log.

                  Tschö, Auge

                  --
                  Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
                  Terry Pratchett, „Gevatter Tod“
                  1. hi,

                    Was hat das miteinander zu tun? Das error.log ist ein Werkzeug, um Fehlern auf die Spur zu kommen.

                    Es kann ein Werkzeug sein. Es gibt jedoch effizientere Methoden zur Qualitätssicherung.

                    1. Hallo

                      Was hat das miteinander zu tun? Das error.log ist ein Werkzeug, um Fehlern auf die Spur zu kommen.

                      Es kann ein Werkzeug sein. Es gibt jedoch effizientere Methoden zur Qualitätssicherung.

                      Was ist denn das für ein Argument?

                      Ein Hammer bleibt ein Hammer, auch wenn sich für bestimmte Aufgaben ein Schraubendreher mehr eignet.

                      Entweder das Log ist ein Werkzeug oder es ist keines. Ob sich andere Werkzeuge in manchen oder gar vielen Fällen besser eignen mag, spielt an dieser Stelle keine Rolle. Du versuchst hier gerade, ein Werkzeug aus dem Koffer auszuschließen, das hier wertvolle Dienste leisten kann, um Fehlerbilder zu finden oder auch auszuschließen.

                      Tschö, Auge

                      --
                      Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
                      Terry Pratchett, „Gevatter Tod“
                      1. hi,

                        Entweder das Log ist ein Werkzeug oder es ist keines.

                        Bei sporadisch auftretenden Fehlern kann Loggen hilfreich sein, wenn es entsprechend vorbereitet wird.

                        Ob sich andere Werkzeuge in manchen oder gar vielen Fällen besser eignen mag, spielt an dieser Stelle keine Rolle.

                        Falls Du mit 'an dieser Stelle' die Phase des Entwickeln meinst: Für mich ist ein error.log mit Sicherheit kein Entwicklerwerkzeug.

                        Kannst Du Dir vorstellen, ein Framework so zu konfigurieren, dass es sämtliche Fehler, einschließlich 404 so abfängt, dass der Webserver gar nichts davon mitbekommt? D.h., es wird gar kein error.log beschrieben, es sei denn, das FW-Script schmiert selbst ab.

                        1. Kannst Du Dir vorstellen, ein Framework so zu konfigurieren, dass es sämtliche Fehler, einschließlich 404 so abfängt, dass der Webserver gar nichts davon mitbekommt? D.h., es wird gar kein error.log beschrieben, es sei denn, das FW-Script schmiert selbst ab.

                          Du vermengst mit deiner Fragestellung zwei Aufgabenbereiche einer guten Fehlerbehandlung. Zum Einen ist es natürlich wünschenswert, die Fehlerbehandlung gegenüber dem Endnutzer deiner Anwendung so transparent wie möglich zu gestalten. Wenn beispielsweise keine Datenbankverbindung aufgebaut werden kann, kann versucht werden einen Fallback-Server zu kontaktieren. Zum anderen sollte dieser Fehler aber für die Entwickler dokumentiert werden. Ein regelmäßiges Scheitern der Datenbankverbindung deutet auf ein schwerwiegenderes Problem hin, dass nach Möglichkeit untersucht und behoben werden muss. Etwas Ähnliches kann man über die 404-Fehlermeldung sagen, die du bereits angesprochen hast. Hier ist ein transparenter Fallback nur schwer möglich. Wenn eine URL aber regelmäßig in den Error-Logs auftaucht, dann ist das ein Indiz dafür, dass die URL an einer anderen Stelle verlinkt ist, oder dass eine Weiterleitung fehlerhaft konfiguriert ist. Beides bedarf dann einen Entwickler, der die Fehlerursache behebt.

                          Error-Logs sind die Langzeit-EKGs der Software-Entwicklung, sie können auf Symptome hinweisen, die bei einer Sprechstunden-Untersuchung verborgen bleiben.

                          1. Hallo 1unitedpower,

                            Error-Logs sind die Langzeit-EKGs der Software-Entwicklung, sie können auf Symptome hinweisen, die bei einer Sprechstunden-Untersuchung verborgen bleiben.

                            Da war @Der Martin einen Ticken schneller mit dem Vorschlag in der Zitatesammlung.

                            Bis demnächst
                            Matthias

                            --
                            Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)
    2. Tach!

      Ausnahmsweise aber, halte ich h... ähem, pls Lösung für die Elegenteste.

      Finde ich nicht, weil nämlich mit dem Werfen der Exception auch gleich mal Schluss im Programmablauf ist. Das heißt, man kann genau bis zu einer Stelle gelangen und nicht eine ganze Reihe von Daten nacheinander in die Ausgabe bringen. Alternativ müsste man die auszugebenden Daten extra irgendwo sammeln, um dann am Ende eine Exception zu werfen. Aber dann kann man auch gleich direkt die Ausgabe schreiben und muss nicht noch den Umweg über eine Exception und das Abfangen mit einem selbst zu schreibenden Exception-Handler gehen.

      Die einfachsten Methoden sind das einfache Ausgeben der Debug-Werte in die Ausgabe (zur Not mit einem 500er Statuscode, damit der Ajax-Aufruf nichts weiter mit den Daten anstellt) und das Anschauen in den Entwicklertools des Browsers, oder das Schreiben ins error_log(), wenn man Zugang zur Serverkonfiguration hat.

      dedlfix.