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
PHP-Neuling
Gunnar Bittersmann
Rolf B
Matthias Apsel