nicht angemeldet
echo $begrüßung;
» $name = $_POST['name'];
Halte ich für durchaus legitim, wenn die Daten danach sofort validiert werden. Anscheinend tust du das ja. Aber damit sind wir schon bei
Was spricht dagegen, den Wert aus dem $_POST-Array zum Validieren direkt zu lesen? Wenn die Werte die Prüfung nicht überstehen, findet ja keine weitere Verarbeitung statt. Ein anschließendes Affenformular kann man dann auch mit den ge-htmlspecialchar-ten $_POST-Werten erstellen. Wenn die Prüfung erfolgreich war, gibt es Werte, die direkt verwendet weren sollen, bei denen ich keinen Grund sehe, sie umzulagern. Und es gibt welche, mit deinen eine Berechnung stattfinden soll. Das Ergebnis davon kann in eine neue Variable.
» if (!$error_msg_1 &&!$error_msg_2 &&!$error_msg_3 &&!$error_msg_4 &&!$error_msg_5 &&!$error_msg_6 &&!$error_msg_7)
Hier empfiehlt sich ein Array.
nutze mysql_real_escape_string()! [...] Den Claim "All userdata is evil." solltest du beim Programmieren nicht nur im Hinterkopf haben.
An dieser Stelle haben wir eine Ausgabe. Dass die in das SQL-Statement einzufügenden Daten direkt oder indirekt aus einer Benutzereingabe kommen ist nicht relevant. Jegliche Daten müssen kontextgerecht behandelt werden, wenn sie in einen neuen Kontext gebracht werden. Das betrifft Eingaben genauso wie sonstwo abgefragte oder erzeugte Daten.
Je nachdem welche Codierung du auf deinen Seite verwendest, kann es auch sinnvoll sein htmlentities() zu verwenden. Außerdem solltest du dich im Formular noch mit http://de.selfhtml.org/html/formulare/definieren.htm#zeichenkodierung@title=accept-charset auf einen Zeichensatz festlegen (am besten den, den du auch für den Rest der Seite verwendest).
Das accept-charset-Attribut für das Formular kann man sich schenken, weil es in manchen Browsern nicht richtig arbeitet. Am besten ist es, sich für eine Kodierung zu entscheiden und diese in beiden Kommunikationsrichtungen zwischen Browser und Server gleichermaßen zu verwenden.
Außerdem ist htmlentities() relativ nutzlos. Wenn man UTF-8 verwendet, kann man bis auf die HTML-eigenen Zeichen jedes andere direkt kodiert verwenden. Wenn man ISO-8859-1 oder eine andere eingeschränkte Kodierung verwendet, hat man ein generelles Problem mit nicht darstellbaren Zeichen. Manch ein Browser kodiert solch ein Zeichen in ein NCR um, andere nehmen ein Fragezeichen oder einen anderen Ersatz. In beiden Fälle ist es quasi verloren, denn man kann die Ersatzdarstellung nicht von einer so gewollten Darstellung unterscheiden.
Soweit alles, das mir aufgefallen ist.
Mir fiel noch mehr auf:
mysql_... or die()
wird gern genommen, ist aber außer zu Debug-Zwecken meist keine akzeptable Reaktion auf einen Fehler. Der Anwender kann nichts dafür, dass das DBMS grad nicht will. Der will eine Bestellung aufgeben oder sonstwas. Stattdessen bekommt er eine halbe Seite präsentiert und einen (oftmals technisch detaillierten) Text, mit dem er nichts anfangen kann. Ein Vorschlag, wie er doch noch zu seinem Ziel kommen kann, und diesen ordentlich in das Seitenlayout eingefügt, wäre hilfreicher.
Einen großen Block mit echo-Ausgaben kann man mit der Heredoc-Syntax auch effektiver schreiben. (Besonders dann, wenn man aus Tippfaulheit $_POST-Einträge umkopiert.)
echo "$verabschiedung $name";
MudGuard
Auge