Ankündigung

Einklappen
Keine Ankündigung bisher.

Debuggen von PHP-Skripten in AJAX-Anwendungen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Debuggen von PHP-Skripten in AJAX-Anwendungen

    Beim Debuggen von PHP-Skripten die über Ajax angesprochen werden gibt es ja das Problem, das Ausgaben die zum Beispiel mit var_dump() gemacht werden nicht im Browser erscheinen sondern als Response zum Ajax-Skript gehen.
    Um die Debug-Ausgaben dort sichtbar zu machen, kann der Netzwermonitor des Browsers benutzt werden oder das Ajax-Skript mit einem console.log bestückt werden.

    Codeausschnitt:
    Code:
         $.ajax({
            url: 'upload.php',
            data: data,          
            type: 'POST',      
            processData: false,
            contentType: false,
            success: function(data) {
              console.log(data);  
            }
    Das funktioniert ganz gut, sofern das ganze Ajax schon läuft und die Debug-Ausgaben im Response nicht stören.

    Eine Alternative für das Debugging sieht wie folgt aus:

    upload.php
    PHP-Code:
    <?php
    error_reporting
    (-1);
    ini_set('display_errors'1);

    //debug-klasse einbinden
    require __DIR__.'/../../php/class/class.debug.php';  //Pfad anpassen!

    //debugausgaben in html logdatei inklusive Fehlermeldungen
    debug::log("debug.html",true);

    //arrays $_POST und $_FILES ausgeben
    debug::write('POST,FILES',$_POST,$_FILE);

    //Response
    echo 'Ok';
    Als erster Test wird die Datei upload.php direkt im Browser aufgerufen. Ausgabe:
    Notice: Undefined variable: _FILE in C:\XAMPP\htdocs\js\jquery\upload.php on line 12
    Ok

    Wir rufen jetzt debug.html in einen neuen Browsertab auf um die grundlegende Funktionalität der Debugausgabe zu überprüfen:

    [01-Aug-2019 10:36:59] PHP Notice: Undefined variable: _FILE in C:\XAMPP\htdocs\js\jquery\upload.php on line 12
    [01.08.2019 10:36:59,938][+652 μs](519k/580k) Debug::write "upload.php" Line 12
    0 string(10) ASCII "POST,FILES"
    1 array(0) array ( )
    2 NULL NULL
    Wir korrigieren nun den hier zu Demozwecken absichtlich gemachten Schreibfehler $_FILE in $_FILES, starten unsere Ajax-Appikation,
    wechseln zu debug.html und aktualisieren das Fenster:
    .
    [01.08.2019 10:43:04,625][+35 μs](520k/581k) Debug::write "upload.php" Line 12
    0 string(10) ASCII "POST,FILES"
    1 array(0) array ( )
    2 array(1) array ( 'file' => array ( 'name' => "12.png", 'type' => "image/png", 'tmp_name' => "C:\\XAMPP\\tmp\\php14A.tmp", 'error' => 0, 'size' => 1333, ), )
    Das Array wird hier im Forum nicht richtig wiedergegeben, in echt ist es so formatiert:
    PHP-Code:
    array (
      
    'file' =>
      array (
        
    'name' => "12.png",
        
    'type' => "image/png",
        
    'tmp_name' => "C:\\XAMPP\\tmp\\php14A.tmp",
        
    'error' => 0,
        
    'size' => 1333,
      ),

    Die Vorteile der PHP-Debug-Variante liegen auf der Hand. Um nur einige zu nennen:
    - kein Verfälschen des Ajax-Responses
    - Anzeige der Zeilennummer der Ausgabe
    - Zeitstempel
    - einfache Datenübernahme für isolierte Tests

    Neben dem hier geschilderten Fall kann die Ausgabe von Debug-Informationen in eine HTML-Datei noch ganz nützlich sein
    für Skripte die per Cron gestartet werden oder Skripte die Grafiken per GD-Funktionen erzeugen.
    ---------------------------------------------------------------------------------

    - Ist der Beitrag hilfreich?
    - Wird die Problematik verständlich rübergebracht ?
    - Sind die Beispiele ausreichend ?

    LG jspit

  • #2
    Man sieht AJAX-Requests und -Responses auch direkt im Netzwerkmonitor des Browsers. Man kann auch danach filtern (XHR).

    Firefox: https://developer.mozilla.org/de/doc...etzwerkanalyse
    Chrome: https://developers.google.com/web/to...tools/network/

    Kommentar


    • #3
      Ja ok, um sich die Requests und -Responses anzuschauen. Nur Debugausgaben haben m:E. im Normalfall nichts in einem Response zu suchen und stören, wenn ich als Beispiel ein Response auswerten muss. Schadet aber nicht, wenn die in der Einführung mit erwähnt wird.
      Edit: Hab es ergänzt. Danke.

      Kommentar


      • #4
        Meiner Meinung nach ist "Debugging" ein bereits sehr gut gelöstes Problem. Zum einen hat man mit Tools wie Postman (und etliche weitere) sehr gute Möglichkeiten Web-Schnittstellen während der Entwicklung zu testen. Zum anderen liefern alle gängigen Browser sehr fähige Entwickler-Werkzeuge (bspw. Chrome DevTools) und auch PHP bietet mit XDebug einen sehr ausgereiften Debugger. Ich empfehle grundsätzlich sich zunächst mit diesen Werkzeugen zu beschäftigen.

        Zitat von jspit Beitrag anzeigen
        Ja ok, um sich die Requests und -Responses anzuschauen. Nur Debugausgaben haben m:E. im Normalfall nichts in einem Response zu suchen und stören, wenn ich als Beispiel ein Response auswerten muss. Schadet aber nicht, wenn die in der Einführung mit erwähnt wird.
        Edit: Hab es ergänzt. Danke.
        Das gehört meiner Meinung nach in Log-Files, sofern es denn tatsächlich notwendig ist diese Ausgaben überhaupt zu erzeugen. Idealerweise hängt man sich mit einem Debugger rein und inspiziert die Daten live. Oder man schreibt Tests.
        [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

        Kommentar


        • #5
          Zitat von jspit Beitrag anzeigen
          Eine Alternative für das Debugging sieht wie folgt aus:
          Jetzt hat man eben noch eine zusätzliche Debug-Komponente, muss man ja nicht nutzen wenn man nicht mag.

          Kommentar


          • #6
            Zitat von protestix Beitrag anzeigen
            Jetzt hat man eben noch eine zusätzliche Debug-Komponente
            Dazu eine die extrem einfach zu nutzen ist und nur einer Voraussetzung bedarf: PHP muss verfügbar sein

            Zitat von lottikarotti Beitrag anzeigen
            Meiner Meinung nach ist "Debugging" ein bereits sehr gut gelöstes Problem.
            Ok, ist eben deine Meinung dazu. So was wie oben als Alternative beschrieben also total überflüssg?

            Dazu mal folgendes Szenario:
            Eine PHP-Applikation, lokal ausgetestet, bringt auf dem Remote-Server (Webspace mit PHP7 bei Hoster XY) einen Fehler, so das dort Debugging betrieben werden muss.
            Vom Grundsatz kein Problem für XDebug, funktioniert ja auch Remote. (s.a. Debugging mit Xdebug und PhpStorm auf Uberspace)
            Nur XDebug ist auf unseren Webspace nicht verfügbar, und der Hoster erlaubt mir keine eigenen Installationen!
            Was nun? Tipps?
            (Die oft hier im Forum bei ähnlichen Problemen gelesenen Empfehlungen wie "Dann wechsel den Hoster" oder "Setz deinen eigenen Server auf" bitte mal
            außen vor lassen.)

            LG jspit

            Kommentar


            • #7
              Zitat von jspit Beitrag anzeigen
              Ok, ist eben deine Meinung dazu. So was wie oben als Alternative beschrieben also total überflüssg?
              Aus meiner Sicht überflüssig, ja. Und in 99% der Fälle tut es auch ein spontanes var_dump (auch bei Web-Services). Postman stellt das perfekt dar.

              Hinweis: du solltest deine Klasse wenigstens verlinken.

              Zitat von jspit Beitrag anzeigen
              Dazu mal folgendes Szenario:
              Eine PHP-Applikation, lokal ausgetestet, bringt auf dem Remote-Server (Webspace mit PHP7 bei Hoster XY) einen Fehler, so das dort Debugging betrieben werden muss.
              Was ja nur dann wirklich notwendig ist, wenn sich das Problem in einer lokalen Umgebung überhaupt nicht nachvollziehen lässt. Was ich grundsätzlich kritisch finde.

              Zitat von jspit Beitrag anzeigen
              Vom Grundsatz kein Problem für XDebug, funktioniert ja auch Remote. (s.a. Debugging mit Xdebug und PhpStorm auf Uberspace)
              Wir betreiben einen separaten Webserver mit aktiviertem XDebug für das Remote-Debugging auf unserem Staging-System. Verwendet wird das aber wirklich sehr selten.

              Zitat von jspit Beitrag anzeigen
              Nur XDebug ist auf unseren Webspace nicht verfügbar, und der Hoster erlaubt mir keine eigenen Installationen!
              Was nun? Tipps?
              Logging.

              Debug-Ausgaben haben meiner Meinung nach auf einem Produktivsystem nichts im Response zu suchen. Und Spielereien am Code schon gar nicht.
              [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

              Kommentar


              • #8
                Hinweis: du solltest deine Klasse wenigstens verlinken.
                Ist dauerhaft in der Signatur verlinkt.

                Zitat von lottikarotti Beitrag anzeigen
                Logging.
                Debug-Ausgaben haben meiner Meinung nach auf einem Produktivsystem nichts im Response zu suchen. Und Spielereien am Code schon gar nicht.
                Im Grunde kann man die Debug-Ausgaben in eine (spezielle)HTML-Datei auch als spezielles Logging betrachten. Im normalen Response weder intern (Ajax) noch zum Nutzer hin tauchen dort irgendwelche Debug-Ausgaben auf.

                Kommentar


                • #9
                  Zitat von jspit Beitrag anzeigen
                  Ist dauerhaft in der Signatur verlinkt.
                  Ich sehe keine Signaturen. Und einige andere Nutzer möglicherweise auch nicht.

                  Im Grunde kann man die Debug-Ausgaben in eine (spezielle)HTML-Datei auch als spezielles Logging betrachten. Im normalen Response weder intern (Ajax) noch zum Nutzer hin tauchen dort irgendwelche Debug-Ausgaben auf.
                  Oh, sorry. Mein Fehler. Ich glaube ich habe dein Post falsch interpretiert, deshalb frage ich lieber nochmal: dein Vorschlag ist Debug-Ausgaben in eine HTML-Datei zu loggen? Dann wäre das natürlich vom Ansatz her vollkommen ok und fällt für mich unter "Logging".
                  [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                  Kommentar


                  • #10
                    Ja, die Debug-Ausgaben landen für das Beispiel hier in einer Html-Datei und können einfach per Browser angezeigt werden.
                    Thema Signatur:
                    PHP-Klassen auf github steht unter jeden Beitrag von mir und das erscheint bei dir nicht?

                    Kommentar


                    • #11
                      Zitat von jspit Beitrag anzeigen
                      Thema Signatur:
                      PHP-Klassen auf github steht unter jeden Beitrag von mir und das erscheint bei dir nicht?
                      Die Anzeige der Signatur kann man abschalten, lottikarotti hat das vermutlich (wie ich auch) gemacht.

                      Kommentar


                      • #12
                        OK, war mir nicht bekannt. Zumal es im ausgeloggten Zustand auch zu sehen ist.
                        Hier geht es zu den Klassen: github.com/jspit-de.

                        Kommentar


                        • #13
                          Eine andere Möglichkeit die Logs direkt im Browser auszugeben ist: http://www.chromephp.com/ hatte ich vor Jahren mal verwendet, funktioniert in Chrome und Firefox soweit ich weiß.
                          Die Logs werden so direkt in der Entwickler-Console angezeigt, was eigentlich recht praktisch ist.

                          PS: Von Loggern wie z.B. MonoLog wird dies so weit ich es im Kopf habe sogar nativ unterstützt, also ohne separate PHP Lib.

                          Kommentar


                          • #14
                            In der Tat ist das Debuggen von Ajax Anwendungen etwas problematisch.

                            Bei Ajax Anwendungen arbeite ich grundsätzlich mit JSON. Das erleichtert es etwas.


                            PHP-Code:
                            <?php
                            function JsonOut($myMessage){
                                
                            header('Content-Type: application/json');
                                echo 
                            json_encode($myMessage);
                            }

                            function 
                            myError($code$txt$file$row){
                              
                            JsonOut([
                                
                            'status' => 'ERROR',
                                
                            'message' => "Errorcode: {$code} - Message: {$txt} Row: {$row} file: {$file}"
                              
                            ]);
                              exit;
                            }
                            set_error_handler('myError');


                            $action $_POST['action'] ?? null;


                            if (
                            $action=='sendmail'){

                              
                            $kuchen $_POST['kuchen'];

                              
                            //prüfe Variablen, sende die Mail
                              //checke ob Sie gesendet wurde dann OK / falls nicht gib status Error zurück
                              
                            echo JsonOut(['status' => 'OK','message' => 'erfolgreich versendet']);
                              exit;
                            }
                            ?>
                            <!DOCTYPE html>
                            <html lang=de>
                            <meta charset=UTF-8>
                            <title>Document</title>
                            <input id=myName>
                            <input id=myOrt>
                            <button id=mySend>Abschicken</button>
                            <script>
                            mySend.onclick=() => {
                              let myFormData = {
                                action: 'sendmail',
                                name: myName.value,
                                ort: myOrt.value
                              }
                              postFormData("", myFormData).then(function(data) {
                                data.status === 'ERROR' && console.log(data.message)
                                data.status === 'OK' && alert(data.message) //oder schreibs woanders hin
                              }).catch(error => console.log(error))
                            }
                            function postFormData(url, data) {
                                return fetch(url, {
                                  method: 'POST',
                                  body: new URLSearchParams(data),
                                  headers: new Headers({
                                    'Content-type': 'application/x-www-form-urlencoded; charset=UTF-8'
                                  })
                                }).then((response) => {
                                  if (response.status >= 200 && response.status <= 299) {
                                    return response.json();
                                  }  else {
                                  throw Error(response.statusText);
                                  }
                                })
                            }
                            </script>

                            Kommentar


                            • #15
                              Zitat von kaminbausatz Beitrag anzeigen
                              In der Tat ist das Debuggen von Ajax Anwendungen etwas problematisch.
                              Was genau?
                              [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                              Kommentar

                              Lädt...
                              X