PHP-Neuling: Jetzt gehts um Formularüberprüfungen

hallöchen mal wieder :)

Da es immer noch um meine eigene Unfähigkeit geht wollte ich nicht unbedingt einen neuen thread aufmachen. Sollte dies aber aufgrund der Thematik gewünscht sein hole ich das immediat nach

Nun bin ich leider nicht in der Lage mein Formular (um das es hier die ganze zeit geht) gewinnbringend zu überprüfen. Es funktioniert zwar, zerschiesst mir aber teile meines css

also ... ich habe ein formular

<form action="" method="post">
ein haufen tabellen und datenbankkram der soweit gut funktioniert, nicht zuletzt dank den mehr als fähigen Köpfen von SelfHTML :)

<input type="hidden" name="aktion" value="speichern">
<input id="savebutton" type="submit" value="Speichern" onclick="submit">
</form>


Weiters habe ich im php bereich der Seite folgende Überprüfung mit anschliessender Variablen-Zuweisung

 if (isset($_POST['aktion']) and $_POST['aktion']=='speichern') {

$Variable1 = isset($_POST['Feld1'];
....
;

Nun wollte ich zusätzlich eine messagebox (per js oder auch sehr gerne ohne js) ausgeben, sollten bestimmte Felder nicht gefüllt sein

if(!$Variable1) {
	
	echo 'du bist ein vollhorst';
} 

	$aktualisieren = $db->prepare("UPDATE TABLESET $ColSet WHERE ID = $ID1");
	
	$aktualisieren->bind_param('sssssssssssssssssssssissssssssssiiiiiiiiiiiiiiiiiiisiiisisiiisssssss',$Variable1, $Variable2, xxx);
 $aktualisieren->execute() or die($db->error);
}

Das echo funktioniert beim Absenden des Formulars. Es wird auch kein execute ausgeführt. So weit so prima

Aber nach dem neu laden der Seite (Sofern "Feld1" leer gelassen wurde) werden meine per css gestylten Checkboxen nicht mehr dargestellt, und auch Feldgrößen (input width) passen nicht mehr Sende ich das Formular korrekt ab, was auch funktioniert, habe ich keinerlei Darstellungsprobleme. Meine ganze Seite ist mit CSS bearbeitet. Ich verstehe auch nicht warum das CSS nur teilweise zerschossen ist, das grós aber vorhanden bleibt :-S

Ist das grundlegend der Falsche weg? Ich wollte das HTML nicht zwangsweise komplett ins PHP hauen, sondern habe es lieber getrennt (zumindest soweit möglich)

<?PHP
ein haufen scriptzeug das meist eh nicht funktioniert
und datenbankkram auch
und kommentare
?>

<html>
</html>

So ist das für mich einfach Übersichtlicher. Sonst hätte ich auch ein Affenformular bauen können.

Hat da jemand einen Tipp für mich ("schon wieder...")

Grüße

  1. @@PHP-Neuling

    hallöchen mal wieder :)

    Da es immer noch um meine eigene Unfähigkeit geht wollte ich nicht unbedingt einen neuen thread aufmachen.

    Wenn sich jene noch länger hinzieht, ist es wohl nicht ratsam, den alten Thread ewig weiterzuführen – zumal dieser schon recht verzweigt und gedriftet ist.

    Sollte dies aber aufgrund der Thematik gewünscht sein hole ich das immediat nach

    Hab ich mal gemacht.

    🖖 Stay hard! Stay hungry! Stay alive! Stay home!

    --
    Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
    1. vielen Dank Herr Bittersmann

  2. Lieber PHP-Neuling,

     if (isset($_POST['aktion']) and $_POST['aktion']=='speichern') {
    
    $Variable1 = isset($_POST['Feld1'];
    ....
    ;
    

    das Umkopieren von $_POST['Feld1'] in eine Variable hat so keinen Sinn und ist deswegen eher gefährlich.

    $aktualisieren = $db->prepare(
      "UPDATE TABLESET $ColSet WHERE ID = $ID1"
    );
    

    Autsch! Hier sieht man nicht mehr, woher der Inhalt in $ID1 her ist. Außerdem wirfst Du diesen Wert direkt in Deinen SQL-Code, ohne ihn über statement->execute kontext-behandelt hineinzugeben. Das könnte im schlimmsten Fall so aussehen:

    $ID1 = $_POST['ID1'];
    // was wäre, wenn das der übertragene Inhalt wäre?
    $ID1 = 'null; DROP DATABASE db_name; --';
    
    $aktualisieren = $db->prepare(
      "UPDATE TABLESET $ColSet WHERE ID = $ID1"
    );
    

    Hier sieht man nur noch den Variablennamen $ID1 im SQL-Statement, ohne seine Herkunft. Vergleiche:

    // was wäre, wenn das der übertragene Inhalt wäre?
    $_POST['ID1'] = 'null; DROP DATABASE db_name; --';
    
    $aktualisieren = $db->prepare(
      "UPDATE TABLESET $ColSet WHERE ID = '"
      .$_POST['ID1']
      ."'"
    );
    

    Hier sieht man sehr schnell, dass da möglicherweise gefährlicher Code entsteht. Daher willst Du immer(!!!) Parameter binden:

    // was wäre, wenn das der übertragene Inhalt wäre?
    $_POST['ID1'] = 'null; DROP DATABASE db_name; --';
    
    $aktualisieren = $db->prepare(
      "UPDATE TABLESET $ColSet WHERE ID = :id1'
    );
    
    $aktualisieren->execute(
      array(':id1' => $_POST['ID1'])
    );
    

    Aber nach dem neu laden der Seite (Sofern "Feld1" leer gelassen wurde) werden meine per css gestylten Checkboxen nicht mehr dargestellt, und auch Feldgrößen (input width) passen nicht mehr

    Warum? Was ist bei dem HTML im Browser anders?

    Meine ganze Seite ist mit CSS bearbeitet. Ich verstehe auch nicht warum das CSS nur teilweise zerschossen ist, das grós aber vorhanden bleibt :-S

    Wenn der HTML-Code Fehler enthält, muss der Browser raten, was Du wohl gemeint haben könntest. Dabei kann eine leicht andere Dokumentstruktur entstehen, die zu den von Dir beobachteten Darstellungsschwierigkeiten führen.

    Ist das grundlegend der Falsche weg? Ich wollte das HTML nicht zwangsweise komplett ins PHP hauen, sondern habe es lieber getrennt (zumindest soweit möglich)

    Aus Deinem ursprünglichen Thread heraus habe ich diese Erweiterung zum DOMDocument-Tutorial geschrieben. Vielleicht hilft sie Dir?

    Liebe Grüße

    Felix Riesterer

    1. Hi Felix, und danke für deine Hilfe

      ich fang mal oben an ... Aus welchem Grund macht das Kopieren des Feldinhaltes in eine Variable keinen Sinn, wenn ich doch für den UPDATE Befehl die Variablen brauche? Oder kann ich auch direkt die Felder ansprechen? Ich habe gar keinen anderen Weg gesehen und das deswegen genau so gemacht

      Nun zur $ID1. Diese Variable wird übergeben von der vorherigen Seite. Es gibt also einen Index, indem etwaige Datenbankeinträge in verkürzter Form zu sehen sind. Mit Klick darauf wird dann auf eine Detailseite (EDIT-Seite) geführt. Um diese zu füttern benötige ich die ID des Objektes, welche ich per _GET übermittle

      Nun, deine Ausführungen kann ich aber durchaus nachvollziehen. Daher werde ich die ID lieber in eine Session Variable legen. Ich gehe nicht davon aus, dass jemand absichtlich (betriebsinterne Verwendung) solchen Unfug anstellen sollte, aber theoretisch müsste ja lediglich der Link abgeändert werden, und schwupps ... Ich werde das überarbeiten. Danke

      Deinen Hinweis bzgl der Parameter und :id1 habe ich jetzt tatsächlich nicht verstanden. Da muss ich wohl nochmal welzen ...

      Nun zum CSS .. Tja .. ich versteh's ja auch nicht. Es ist genau so wie ich versucht habe es zu beschreiben.

      Lasse ich das entsprechende Feld leer, und sende das Formular ab, erhalte ich meine Message, die Seite läd neu und es wurde nichts gespeichert. Meine Checkboxen bspw. aber sind weg. Fülle ich dann das Feld und sende das Formular ab, läd die Seite neu, der Eintrag steht drin, und die Seite ist in Ordnung

      Gerade fiel mir noch was zusätzliches auf ... natürlich ...

      Manchmal kommt es mir so vor, als würde der Aufbau einer Seite ungewöhnlich lange dauern. Klar kann auch der Server gerade mal schwächeln,ich weiß nicht wie viele Seiten dort evtl im Betriebsmodus liegen.

      Aber dennoch möchte ich gerne sicher gehen, was das beenden von Verbindungen ans SQL angeht. Alle meine DB-Befehlen laufen über die variable $db, welche über eine db.php festgelegt wird

      $db = new mysqli(yyy);

      Am Ende jeder Seite, also unter dem </html> sitzt immer ein

      <?php $db->close(); ?>

      Zudem werden auch variablen wieder befreit

      <?php $DATA->free(); $Datensatz->free(); usw ?>

      Ist damit wirklich jede Verbindung gekappt, die durch meine Page geöffnet wurde?

      1. Lieber PHP-Neuling,

        warum habe ich jetzt den Verdacht, dass Du meine Antwort nur flüchtig überflogen hast?

        ich fang mal oben an ... Aus welchem Grund macht das Kopieren des Feldinhaltes in eine Variable keinen Sinn, wenn ich doch für den UPDATE Befehl die Variablen brauche?

        Das hatte ich versucht sehr genau darzustellen. Wenn Du Deinen Code liest, ist es für Dich (nicht für den Server) ein Unterschied, ob da $ID1 steht, oder $_POST['ID1']. Sucht man nach Fehlern oder Sicherheitslücken, ist das von Bedeutung. Es ist eine handwerkliche Sache.

        Wenn Du den Inhalt in $ID1 verändert hast (z.B. alles in Kleinschreibweise umgewandelt), dann ist es natürlich besser, dieses nicht am Inhalt von $_POST['ID1'] selbst zu tun, sondern die ursprünglichen Userdaten in $_POST unverändert zu lassen und veränderte Daten in neuen Variablen vorzuhalten.

        Oder kann ich auch direkt die Felder ansprechen?

        Genau das habe ich Dir in meinem letzten Code-Beispiel doch gezeigt! Schau es Dir noch einmal an.

        Ich habe gar keinen anderen Weg gesehen und das deswegen genau so gemacht

        Du scheinst mir betriebsblind zu werden. Das kenne ich sehr gut. Mach mal einen Tag etwas völlig anderes. Das hilft, den Blick wieder klar zu bekommen.

        Nun zur $ID1. Diese Variable wird übergeben von der vorherigen Seite.

        Nein, wird sie nicht. Diese Variable gibt es nur in Deinem Script. "Von der vorherigen Seite" kommt ein Wert, der im $_POST-Array unter einem bestimmten Schlüssel übermittelt wird. Auch das ist ein wesentlicher Unterschied. Das darf man gedanklich nicht in die selbe Kiste schmeißen.

        Es gibt also einen Index, indem etwaige Datenbankeinträge in verkürzter Form zu sehen sind.

        Es gibt also einen Index in $_POST, in dem etwaige Schlüssel zu Indices in der Datenbank passen könnten. Bleibe skeptisch! Vertraue den vom Browser übertragenen Daten niemals! Das ist das schlimmste, was man tun kann! Daher kommt auch der Rat, dass Du die Schlüssel aus $_POST gezielt auf Vorhandensein überprüfst, anstatt immer davon auszugehen, dass sie da sind und auch das enthalten, wovon Du ausgehst.

        Denke immer daran, dass man auch zwei Browserfenster oder -tabs geöffnet haben kann. Was man im einen tut, kann Auswirkungen auf die Datenbank haben, wovon das andere aber nichts mitbekommt.

        Mit Klick darauf wird dann auf eine Detailseite (EDIT-Seite) geführt. Um diese zu füttern benötige ich die ID des Objektes, welche ich per _GET übermittle

        Das ist OK und erwartungsgemäß. Jedoch muss die Detail-Seite prüfen, ob es einen passenden Datensatz gibt, der zum Index und Wert in $_GET passt, um im Fehlerfall eine entsprechende Meldung auszugeben.

        Nun, deine Ausführungen kann ich aber durchaus nachvollziehen. Daher werde ich die ID lieber in eine Session Variable legen.

        So ein Unfug! Bitte ändere Deine Sichtweise und nicht Deine Vorgehensweise! Die Idee ist, dass man die Herkunft der Daten im Script nicht unnötig verschleiert.

        Ich gehe nicht davon aus, dass jemand absichtlich (betriebsinterne Verwendung) solchen Unfug anstellen sollte,

        Manchmal ist es auch ein Zurückbutton, der eine Seite wieder aufruft, oder eine andere Bedienung, die zu ungewolltem Verhalten des Scripts führen kann. Das kann man alles als Fehlbedienung abtun, aber das verlagert nur die Verantwortung für eine korrekte Funktionsweise vom Programmierer auf den Bediener.

        Deinen Hinweis bzgl der Parameter und :id1 habe ich jetzt tatsächlich nicht verstanden. Da muss ich wohl nochmal welzen ...

        Der Wert, der in den SQL-Code der DB-Anfrage geschrieben werden soll, darf die Syntax des SQL-Codes nicht zerstören. Deswegen muss potenziell bösartiger Inhalt (wir erinnern uns: traue keinen vom Browser versandten Daten!) kontextgerecht behandelt werden. Dafür gibt es die execute-Methode eines Statement-Objektes. Die tut das für uns. Damit sie aber genau weiß, an welcher Stelle welche Inhalte eingepasst werden sollen, ist es sinnvoll, die Platzhalter mit Namen anstelle von Fragezeichen zu versehen.

        Nun zum CSS .. Tja .. ich versteh's ja auch nicht. Es ist genau so wie ich versucht habe es zu beschreiben.

        Nimm den HTML-Code der fehlerhaft angezeigten Seite und wirf ihn in einen Validator. Dann kannst Du sehen, ob er fehlerfrei ist. Hast Du schon einmal mit einem Validator gearbeitet?

        Lasse ich das entsprechende Feld leer, [undsoweiter]

        Nicht mutmaßen! Prüfen! Nimm einen Validator!

        Manchmal kommt es mir so vor, als würde der Aufbau einer Seite ungewöhnlich lange dauern.

        Das kann an einer ungünstig formulierten Anfrage liegen. Das ist mir auch schon passiert.

        Am Ende jeder Seite, also unter dem </html> sitzt immer ein

        <?php $db->close(); ?>

        Zudem werden auch variablen wieder befreit

        <?php $DATA->free(); $Datensatz->free(); usw ?>

        Du vermischst also noch HTML-Markup und PHP-Code in ein und demselben Dokument? Schau mal in das oben verlinkte Tutorial! Dort steht, wie man das anders machen kann. Stichwort: Template (Vorlage)

        Ist damit wirklich jede Verbindung gekappt, die durch meine Page geöffnet wurde?

        Es wird jede Verbindung gekappt, egal welche, wenn Dein Script beendet wird. Egal ob es korrekt bis zum Ende gelaufen ist, oder ob es unterwegs aufgrund eines Fehlers abgebrochen werden musste.

        Falls Du willst, kann ich Dir ein Beispielprojekt als ZIP-Datei zukommen lassen, in dem ich HTML, CSS und PHP verwende, um einen Datenbestand in einer SQL-Datenbank zu verwalten. Dieses Beispielprojekt verwendet Templates. @Matthias Apsel hatte mich in Deinem ursprünglichen Thread dazu angeregt, um vielleicht ein Tutorial zu basteln, das Deine Fragen behandelt. Aber ich fürchte, dass das Beispielprojekt zu umfangreich und komplex geworden ist, um als Tutorial noch geeignet zu sein. Immerhin konnte ich aber zwei Methoden daraus in das DOMDocument-Tutorial übernehmen.

        Liebe Grüße

        Felix Riesterer

        1. Hi Felix,

          wow, danke ... Es ist nicht so, als würde ich deine Antworten "nur überfliegen". Vielmehr haben wir noch eine vollkommen andere Sichtweise auf all die Dinger, da ich gerade erst angefangen habe mit PHP. Meinen Nick werde ich entsprechend die nächsten Monate nicht ändern, mich aber wohl dauerhaft mit PHP beschäftigen (weil das einfach irgendwie toll ist :D )

          Dein Angebot der ZIP Datei würde ich sehr, sehr gerne annehmen. Visualisiert werden einige Sachen immer deutlich verständlicher

          Vielen Dank !

    2. Tach!

      $Variable1 = isset($_POST['Feld1'];
      

      das Umkopieren von $_POST['Feld1'] in eine Variable hat so keinen Sinn und ist deswegen eher gefährlich.

      Beachte, da steht ein isset(), welches einen booleschen Wert entsprechend der Feldexistenz liefert. Das ist kein einfaches Umkopieren.

      Die Frage ist hier, ob es sich lohnt, dafür eine Variable anzulegen, oder ob man nicht einfach auch das isset()-Konstrukt anstelle der Verwendung der Variable nehmen kann. Eine grundlegend Gefährlichkeit sehe ich in dem Fall erstmal nicht. Es kann aber verständlicher sein, statt der indirekten Variable das direkte isset() zu verwenden.

      dedlfix.

      1. hi dedlfix,

        es würde also auch im UPDATE befehl funktionieren, direkt das Feld auszuloten ?

        ergo

        UPDATE TABLE SET FELD1 WHERE blah; bind_param('s', isset($_POST['Feld1'] );

        Ursprünglich war die Notwendigkeit von Variablen gegeben, da ich SESSION Variablen nutzen wollte. Das System wird später evtl von mehreren Personen gleichzeitig genutzt, und da schienen mir SESSIONS der sichererste Weg.

        Es gab aber Probleme mit den Sessions auf unserem Server, weshalb ich zum weiterarbeiten einfach erstmal normale Variablen draus gemacht habe

        1. Lieber PHP-Neuling,

          UPDATE TABLE SET FELD1 WHERE blah; bind_param('s', isset($_POST['Feld1'] );

          ja, so ähnlich:

          $st = $db->prepare(
              'UPDATE TABLE `warengruppe`'.PHP_EOL
              . 'SET `spalte`=:wert'.PHP_EOL
              . 'WHERE `anderespalte` LIKE :andererwert'.PHP_EOL
          );
          
          $st->execute(array(
              // anstelle von null könnte da auch 0 stehen - je nach DB-Design
              ':wert' => isset($_POST['Feld1']) ? 1 : null,
              ':andererwert' => 'xyz'
          ));
          

          Liebe Grüße

          Felix Riesterer

          1. na das sieht ja nur beinahe anders aus ... :D

            das .PHP_EOL, wobei EOL sicher für END OF LINE steht. Sehe ich jetzt so zum ersten mal. Muss das immer kommen wenn ich im PHP Code einen Umbruch haben möchte ? Für die Lesbarkeit wäre das natürlich enorm obercool

            Nur versehe ich immer noch nicht die Parameterangabe mit dem ":", bspw. :wert, oder auch im von mir gebrachten Problem deine ":id1"

            Was hat der ":" zu bedeuten? Was wird da anders gemacht? Mich verwirrt das alles :P

            1. Lieber PHP-Neuling,

              Was hat der ":" zu bedeuten? Was wird da anders gemacht? Mich verwirrt das alles :P

              Dein $db steht ja für ein PDO-Objekt. Das bedeutet, dass Du SQL-Abfragen mit diesem umsetzt. Die PDO-Klasse kann mit benannten Platzhaltern arbeiten. Vergleiche:

              $s1 = $db->prepare(
                'SELECT * FROM `data` WHERE `col1`=? AND `col2`=?'
              );
              
              $s2 = $db->prepare(
                'SELECT * FROM `data` WHERE `col1`=:wert1 AND `col2`=:wert2'
              );
              

              In beiden Statements stehen zwei Platzhalter. Sie sind im ersten durch Fragezeichen dargestellt, im zweiten haben sie so etwas wie Variablennamen. Schauen wir uns nun an, wie sie ausgeführt werden:

              $s1->execute('Welt', 'Hallo');
              
              $s2->execute(
                ':wert2' => 'Welt',
                'wert1' => 'Hallo' // Doppelpunkt darf sogar fehlen
              );
              

              Im ersten execute-Aufruf werden die Werte irrtümlicherweise in der falschen Reihenfolge notiert. Das wird im Ernstfall Fehler verursachen, die man bei der Fehlersuche vielleicht nicht so leicht findet. Im zweiten Aufruf sind die Werte an die im Statement verwendeten Namen gebunden. Sie können also schwerer verwechselt werden.

              Die PDO-Klasse "versteht" solche "Variablennamen", wenn man einen Doppelpunkt voranstellt. Das Array mit den zuzuordnenden Werten muss dann in seinen Schlüsseln die entsprechenden Namen haben, im Zweifelsfalle sogar ohne den vorangestellten Doppelpunkt.

              Liebe Grüße

              Felix Riesterer

              1. Hallo Felix,

                ich glaube, du hast Dich verguckt. Der Neuling (den ich gern anders nennen würde, das ständige "Neuling" klingt so abwertend) verwendet bind_param, nicht bindParam - und das ist mysqli, nicht PDO.

                Rolf

                --
                sumpsi - posui - obstruxi
                1. korrekt, PHP PDO habe ich bislang nicht verwendet

                  Ist das ein Fehler? Sollte ich da umdenken ?

                  prepare funktioniert ja auch unter mysqli, und/oder wie oder was? :-O

                  1. Ich habe mir jetzt anders beholfen.

                    Ich hole mir die Variable $ID1 über die vorangegangene Seite per link

                    <a href="editseite.php?ID1=<?php echo $DATA->ID ?> Editseite </a>

                    Auf der editseite.php hole ich mir diese ID per get

                    $ID1 = (int)$_GET['ID'];

                    Ich habe dem GET nun ein (int) vorangestellt, da die ID immer nur ein integer sein kann, und niemals etwas anderes.

                    Sollte nun ein Unhold dort

                    ' ichbineinblödmann droptable trallalla

                    reinklimpern, wird das einfach nicht umgesetzt.

                    Soweit meine Theorie. Finde ich total Gut. Bin gespannt, wie lange ... :-D

                    1. ich hatte jetzt noch eine fixe idee zum Abfangen von Schabernack Immerhin könnte man den link ja per Hand ändern und somit die DB ärgern Aber irgendwie komme ich mit dem is_int nicht zurecht

                      $IDtemp = $_GET['ID']; 
                      IF (is_int($IDtemp)) {
                      	$ID1 = $IDtemp; // Hole querystring der index.php (?ID=X)
                      } else {
                      		$ID1=6;
                      }
                      

                      GET 'ID' überträgt jetzt die ID aus dem Index

                      In meinem Verständnis wird durch IF (is_int($IDtemp)) geprüft, ob die Variable $IDtemp ein integer ist.

                      In der DB wird die ID (pk) als mediumint(9) gespeichert

                      meine Bedingung ist aber nie wahr :-/

                      $ID1 ist immer 6. Ich habe auch versucht über den link mit (int)$ID zum integer zu zwingen, aber dennoch wird das einfach nicht wahr 🤔

                      1. Hallo PHP-Neuling,

                        das $_GET Array enthält immer Strings.

                        is_int(123) liefert TRUE, aber is_int("123") liefert FALSE.

                        Manche Dinge kann man ganz einfach im Sandkasten ausprobieren - ok, $_GET hast Du dort nicht.

                        Für deinen Zweck gibt es bessere Funktionen (-> Handbuch)

                        $ID1 = filter_input(INPUT_GET, 'ID', FILTER_VALIDATE_INT);
                        if ($ID1 === FALSE)
                           $ID1 = 6;
                        

                        Das dreifach-Gleich ist wichtig, es verbietet PHP Typanpassungen. Andernfalls würde ID=0 im Query-String ebenfalls auf 6 umgebogen.

                        Rolf

                        --
                        sumpsi - posui - obstruxi
                        1. wow, und sowas schüttelst du einfach aus dem Ärmel :)

                          Vielen Dank, so funktioniert das einwandfrei

                          1. Hallo PHP-Neuling,

                            der Ärmel hat LANGE über den Schreibtisch gescheuert, damit so viel drin steckt 😉

                            Rolf

                            --
                            sumpsi - posui - obstruxi
                            1. cool, habe nun nochmal nachgerüstet und im FALSE Fall einfach zurück auf den index geleitet

                              if ($ID1 === FALSE) { header("Location: index.php");

                              Das ist eigentlich das Beste was ich mir so hätte vorstellen können (:

                              Danke nochmal : )

                              Auch an Felix. Ich knabbere noch an der DOM Geschichte ...

                              1. Hallo PHP-Neuling,

                                cool, habe nun nochmal nachgerüstet und im FALSE Fall einfach zurück auf den index geleitet

                                if ($ID1 === FALSE) { header("Location: index.php");

                                Das freut mich, dass du offenbar gut vorankommst. Jetzt könntest du noch hinsichtlich der Formatierung deiner Beiträge nachrüsten. Bestimmt hast du dich gefragt, wie die anderen es hinbekommen, dass der Code so hübsch aussieht. Oberhalb des Textfeldes zur Bearbeitung des Beitrages solltest du eine Icon-Leiste finden. Sei neugierig!

                                Die Auszeichnung von Code als Code macht die Beiträge in aller Regel besser lesbar.

                                if ($ID1 === FALSE) {
                                   header("Location: index.php");
                                }
                                

                                Bis demnächst
                                Matthias

                                --
                                Du kannst das Projekt SELFHTML unterstützen,
                                indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
                                1. du hast vollkommen recht, sorry, war nur bequemlichkeit

                  2. Hallo PHP-Neuling,

                    das ist deine Entscheidung. MYSQLI kann nur die Fragezeichen-Marker, PDO kann auch benannte Parameter. Es ist eine Abstraktionsschicht, die über der nativen DB-Anbindung liegt, und damit auch ein bisschen (ein kleines bisschen) Laufzeit kostet.

                    Ein paar Methoden heißen in PDO anders, d.h. wenn Du umstellst hast Du etwas Anpassungsarbeit.

                    Vorteil von PDO ist die Austauschbarkeit der Datenbankschicht - zumindest vom Prinzip her. Da es Unterschiede in den SQL Dialekten gibt, ist das Austauschen nicht immer schmerzfrei, aber immerhin muss man nur das SQL anpassen und nicht auch noch alle Funktionsaufrufe.

                    Rolf

                    --
                    sumpsi - posui - obstruxi
                    1. Vorteil von PDO ist die Austauschbarkeit der Datenbankschicht - zumindest vom Prinzip her. Da es Unterschiede in den SQL Dialekten gibt, ist das Austauschen nicht immer schmerzfrei, aber immerhin muss man nur das SQL anpassen und nicht auch noch alle Funktionsaufrufe.

                      Austauschbarkeit der Datenbankschicht. Das klingt schon wieder komisch

                      Wäre ich jetzt hier in Helmut's PC-Freunde Forum würde ich einfach fragen

                      Hä? Brauch ich das ?

                      Aber auch ich lerne ja dazu, und selfhtml hilft keinem der sich nicht selber hilft

                      Bislang habe ich nichts entdeckt was mir bei mysqli fehlt. Allerdings ist das auch kaum wunderlich, da ja momentan noch alles neue für mich neu ist

                      okay, die "variablen" für das Execute wären sicher ein Vorteil. Aber groß genug um wieder zu erneuern und noch mehr durcheinander zu kommen? Momentan muss ich das verneinen.

                      Ich habe natürlich auch bereits das php.net und die startpage nach PDO befragt. In vielen Stellen wird das tatsächlich ausschließlich benutzt. Aber so eine Killer-Feature-Übersicht fehlt mir noch.

                      Vielleicht brauche ich noch ein weiteres Buch über PDO :-P

                      1. Hallo PHP-Neuling,

                        Austauschbarkeit meint, dass Du mit PDO jede Datenbank mit einheitlicher Technik ansprichst. mysql, ms sql server, oracle, whatever. Für Dich dürfte das irrelevant sein.

                        Ob PDO für Dich echte Vorteile bringt, kann ich Dir nicht sagen. Was kann es, das mysqli nicht kann?

                        • Benannte Parameter
                        • Übergabe benannter Parameter an execute (erspart das Binden der Query-Parameter)
                        • Query-Parameter können auch an Konstanten gebunden werden (bindValue)
                        • Einlesen von LOBs über das stream-API statt sie komplett in den Speicher zu saugen (LOBs sind große Datenblöcke in der Datenbank, z.B. Bilder)

                        Ein Buch braucht Du nicht unbedingt. Lies Dir einfach den Einführungsteil von PDO im PHP Handbuch durch. Es gibt auch reichlich PDO Tutorials im Netz.

                        Rolf

                        --
                        sumpsi - posui - obstruxi
                        1. hmm, dass mit den querys und bind_params klingt jetzt schon wieder gut

                          ich lese mal rein. Kommt direkt neben die DOM Geschichte, die auch ein großes Projekt wird ;-D

                      2. Lieber PHP-Neuling,

                        Vielleicht brauche ich noch ein weiteres Buch über PDO :-P

                        Du hast mein Beispielprojekt. Dort verwende ich PDO. Du kannst Dir ja anschauen, wie ich das dort tue. Es ist schnell in Deinem Projekt eingerichtet und lässt sich bequem benutzen. Außerdem gehört es mittlerweile zur Grundausstattung einer PHP-Installation, so dass man sich darauf verlassen kann, dass die PDO-Klasse verfügbar ist.

                        Liebe Grüße

                        Felix Riesterer

          2. Hallo Felix,

            warum zum grundgütigen Geier sollte man das so umständlich machen. Das ruft doch nach HEREDOC.

            $st = $db->prepare(<<<SQL
            UPDATE TABLE `warengruppe`
            SET `spalte`=:wert
            WHERE `anderespalte` LIKE :andererwert
            SQL
            );
            

            Die Zeilenumbrüche des Sourcecodes sind Teil des Heredoc-Strings. Wichtig für Neulinge ist hier, dass das Abschluss-Symbol (hier: SQL) ganz links stehen muss und maximal ein Semikolon dahinter stehen darf. Kein Space. Da der Heredoc-String als Parameter verwendet wird, darf im konkreten Fall natürlich auch kein Semikolon stehen.

            Ab PHP 7.3 wurde Heredoc ein bisschen schlauer. Das steht aber nicht im Handbuch, sondern nur in den Releasenotes. Das Endesymbol darf eingerückt werden und man darf auch dahinter weiterschreiben. Die Einrückung des Endesymbols wird dabei auf alle Zeilen des Heredoc-Strings übertragen, d.h. alle Zeilen des Heredoc-Strings müssen mindestens so weit eingerückt sein wie das Ende-Symbol, und die Einrückung ist nicht Teil des Strings.

            // Erst ab PHP 7.3 erlaubt:
            $st = $db->prepare(<<<SQL
                UPDATE TABLE `warengruppe`
                SET `spalte`=:wert
                WHERE `anderespalte` LIKE :andererwert
                SQL);
            

            Rolf

            --
            sumpsi - posui - obstruxi
            1. okay, das HEREDOC Zeugs scheint recht interessant zu sein. Da hätte ich mir schon das ein oder andere "' sparen können Aber gut, dazu dann später :-D

  3. Hallo PHP-Neuling,

    echo 'du bist ein vollhorst';

    führt vermutlich zu Problemen, wenn Du das vor deiner Webseite ausgibst. Dein HTML Datenstrom beginnt dann nicht mehr mit <!DOCTYPE html>, und das mag den Browser in den Quirks-Mode versetzen.

    Es ist absolut sinnvoll, zuerst via PHP die komplette Verarbeitung zu machen und dann, als Abschluss, die HTML Seite basierend auf den Ergebnissen auszugeben. Aber dann muss man auch Fehlermeldungen speichern und passend in die Seitenaufbereitung einfügen.

    Auf einer Seite, die ich mal gebaut habe, hatte ich ein Array mit Protokoll-Infos. Im Falle eines Fatal Error habe ich es stumpf rausgehauen. Im Falle einer normalen Verarbeitung habe ich es als Table unter die Seite gesetzt. Und über einen Schalter konnte ich die Ausgabe unterbinden.

    Rolf

    --
    sumpsi - posui - obstruxi
    1. hallo Rolf, okay das kann gut sein. Zumindest kann ich das nachvollziehen

      Wie oder wo aber könnte ich eine solche Abfrage aber sonst positionieren? Ich fände es auch super günstig, wenn das Formular gar nicht gänzlichst abgeschickt werden würde, sondern die Felder vorher geprüft werden könnten.

      Aber bis auf ein verschachteltes affenformular komme ich da auf keine Lösung.

      Kann HTML selbst nicht sowas? just per msgbox eine Meldung ausschmeissen, und dann die Seite lassen wie sie ist ?

      1. ... okay ich habe das goldene stichwort "required" gefunden

        <input type="text" value"xxx" required>

        Das macht genau das, was ich möchte :)

        1. Hallo PHP-Neuling,

          Red Alert!

          Client-seitige Prüfungen müssen immer am Server wiederholt werden, weil Du dem Client prinzipbedingt nicht vertrauen darfst. Paranoia ist beim Verarbeiten eines Client-Requests Grundbedingung.

          Wie oder wo aber könnte ich eine solche Abfrage aber sonst positionieren?

          Die Abfrage? Da, wo sie jetzt schon ist.

          Die Fehlerausgabe: Da, wo Du das HTML ausgibst, an passender Stelle.

          Rolf

          --
          sumpsi - posui - obstruxi
          1. Ich habe es jetzt so geregelt, dass das IF(!$VAR1) {} Konstrukt weiters vor dem UPDATE Befehl steht. Da das HTML aber keinen Befehl weiter durchlässt, wird dieser nie ausgeführt.

            Und sollte es doch passieren (wie auch immer) greift das IF und die Funktionen werden korrekt, aber mit (noch) beschädigten CSS ausgeführt.

            1. Lieber PHP-Neuling,

              Da das HTML aber keinen Befehl weiter durchlässt, wird dieser nie ausgeführt.

              das klingt nach Missverständnis.

              Liebe Grüße

              Felix Riesterer

              1. ähm, nein, eventuell habe ich mich jetzt nur schlecht ausgedrückt.

                durch den schalter "required" im input Feld wird das Formular im Normalfall nicht abgeschickt. Entsprechend ist die bedingung IF(!$VAR) niemals wahr. Ergo wird sie nie erfüllt und meine angeschlossene Ausgabe (mit fehlerhaftem css) wird nie ausgeführt

                Sollte es nun doch einen Fall geben, indem die required inputs "ausgetrickst" werden oder Fehlerhaft arbeiten, greift dann als Serverseitige Lösung das IF Konstrukt

                Entsprechend bin ich serverseitig auch abgesichert. Müsste aber noch Rolfs Vorschlag beherzigen, die Ausgabe aus dem PHP zu kicken und ins HTML zu schieben um zu sehen, ob dann die Ausgabe im HTML tatsächlich korrekt ist

                1. @@PHP-Neuling

                  Sollte es nun doch einen Fall geben, indem die required inputs "ausgetrickst" werden oder Fehlerhaft arbeiten, greift dann als Serverseitige Lösung das IF Konstrukt

                  Dazu braucht ein Nutzer keine Tricks, sondern nur einen alten Browser, der required nicht versteht, also ignoriert. Und das ist kein Fehler, sondern Robustheit, progressive enhancement.

                  Auch deshalb ist die serverseitige Prüfung notwendig.

                  🖖 Stay hard! Stay hungry! Stay alive! Stay home!

                  --
                  Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
                  1. okay, danke für den Hinweis :)