nicht angemeldet
Meinung über ein Kommentarscript
MudGuard
AugeHi,
bin ansich noch Anfänger in PHP.
Wollte jetzt eine Möglichkeit, damit Benutzer einen Kommentar hinterlassen können. Da ich kein fertiges Script gefunden habe, was mit gefallen hat, hab ich selbst eins geschrieben.
Das Script funktioniert ansich perfekt, so wie ich mir es vorstelle.
Ich wollte nur fragen was daran vielleicht falsch ist oder was ich noch ändern sollte.
Hier mal das Script:
<?php
//Anzahl der Kommentare auslesen
$hostUrl = 'localhost';
$userName = 'xxx';
$password = 'xxx';
$connectID = mysql_connect($hostUrl, $userName, $password)
or die ("Tut mir leid, kann keine Verbindung zur Datenbank aufbauen");
mysql_select_db("xxx", $connectID)
or die ("Auswahl der Datenbank nich Möglich");
$query = "SELECT count(*) FROM comments";
$result = mysql_query($query)
or die ("MySQL-Fehler: " . mysql_error());
$anzahl = mysql_result($result,0);
if(isset($_POST['comm_send']))
{
$name = $_POST['name'];
$email = $_POST['email'];
$website = $_POST['website'];
$kommentar = $_POST['kommentar'];
//Validierung für die Eingaben einfügen
include("komm_vali.php");
//Kommentare schreiben
function writeComment ($id, $name, $datum, $uhrzeit, $website, $email, $kommentar)
{
$datum = date('j. M Y');
$uhrzeit = date('H:i');
$connectID = mysql_connect($hostUrl, $userName, $password)
or die ("Tut mir leid, kann keine Verbindung zur Datenbank aufbauen");
mysql_select_db("xxx", $connectID)
or die ("Auswahl der Datenbank nich Möglich");
mysql_query ("INSERT INTO comments (id, autor, datum, uhrzeit, website, email, kommentar)
VALUES ('$id', '$name', '$datum', '$uhrzeit', '$website', '$email', '$kommentar')", $connectID)
or die ("Schreiben des Eintrags in die Datenbank nicht möglich");
}
if (!$error_msg_1 &&!$error_msg_2 &&!$error_msg_3 &&!$error_msg_4 &&!$error_msg_5 &&!$error_msg_6 &&!$error_msg_7)
{
writeComment($id, $name, $datum, $uhrzeit, $website, $email, $kommentar);
header ("Location: komm.php");
}
}
//Formular Ausgabe
echo "<div id=\"comments\">";
echo "<h2>$anzahl Kommentare bis jetzt</h2>";
//Kommetare auslesen
$connectID = mysql_connect($hostUrl, $userName, $password)
or die ("Tut mir leid, kann keine Verbindung zur Datenbank aufbauen");
mysql_select_db("xxx", $connectID)
or die ("Auswahl der Datenbank nich Möglich");
$query = "SELECT * FROM comments ";
$out = mysql_query($query,$connectID);
while ($row_out = mysql_fetch_array($out))
{
$ausgabe_Autor = $row_out['autor'];
$ausgabe_Datum = $row_out['datum'];
$ausgabe_Uhrzeit = $row_out['uhrzeit'];
$ausgabe_Website = $row_out['website'];
$ausgabe_Email = $row_out['email'];
$ausgabe_Kommentar = nl2br($row_out['kommentar']);
if($ausgabe_Website == "http://")
{
echo "<p>$ausgabe_Autor am $ausgabe_Datum um $ausgabe_Uhrzeit</p>";
}
else
{
echo "<p><a href=\"$ausgabe_Website\">$ausgabe_Autor</a> am $ausgabe_Datum um $ausgabe_Uhrzeit</p>";
}
echo "<div class=\"comm_cont\">";
echo "<p class=\"comment\"><br />";
echo "$ausgabe_Kommentar";
echo "</p>";
echo "</div>";
}
echo "<h2>Hinterlasse einen Kommentar</h2>";
echo "<form action=\"";$_SERVER['PHP_SELF'];echo "\" method=\"post\">";
echo "<input type=\"text\" size=\"20\" id=\"name\" name=\"name\" value=\"$name\" />";
echo "<label for=\"name\">Name</label><br />";
echo "<input type=\"text\" size=\"20\" id=\"email\" name=\"email\" value=\"$email \" />";
echo "<label for=\"email\">E-Mail</label><br />";
echo "<input type=\"text\" size=\"20\" id=\"website\" name=\"website\" value=\""; if(isset($website)){echo $website;} else echo "http://\" />";
echo "<label for=\"website\">Website</label><br />";
echo "<textarea cols=\"45\" rows=\"10\" id=\"kommentar\" name=\"kommentar\" >$kommentar</textarea><br />";
echo "<input type=\"submit\" value=\"Kommentar senden\" id=\"comm_send\" name=\"comm_send\" />";
echo "</form>
</div>";
?>
Mfg
Simon
-
Da ich von PHP keine Ahnung habe widme ich mich deinem Formular.
Visuell möchtest due die Reihenfolge
Input <-> Label
Das ist aber suboptimal. Das Label sollte logisch _vor_ dem Input stehen.Deshalb: Drehe die Reihenfolge um.
Du kannst aber dem <label> dann mittels CSS die Eigenschaft verpassen:label{float:right; }
dadurch erhältst du visuell das gewünschte.Ich habe zudem nicht auf deinen Doctype geachtet.
Falls du strict verwendest, dann solte <form> als Children nur Blockelemente haben.
Also entweder <fieldset> oder <ul> oder wenn du es neutral magst mehrere <div> oder <p> Elemente.PS: Vergiss nicht, dass User-Daten in HTML kontextgerecht behandelt werden müssen.
Stichwort htmlspecialchars()echo "<h2>Hinterlasse einen Kommentar</h2>";
echo "<form action="";$_SERVER['PHP_SELF'];echo "" method="post">";
echo "<input type="text" size="20" id="name" name="name" value="$name" />";
echo "<label for="name">Name</label><br />";
echo "<input type="text" size="20" id="email" name="email" value="$email " />";^ ein Versehen?
echo "<label for="email">E-Mail</label><br />";
echo "<input type="text" size="20" id="website" name="website" value=""; if(isset($website)){echo $website;} else echo "http://" />";
echo "<label for="website">Website</label><br />";
echo "<textarea cols="45" rows="10" id="kommentar" name="kommentar" >$kommentar</textarea><br />";
echo "<input type="submit" value="Kommentar senden" id="comm_send" name="comm_send" />";
echo "</form>
</div>";
?>[/code]mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Input <-> Label
Das ist aber suboptimal. Das Label sollte logisch _vor_ dem Input stehen.Das würde ein Araber oder Israeli wahrscheinlich genauso sehen, aber trotzdem das tun, was Simon tut.
Letztlich ist es doch aber egal, wo ein label steht, solange es per for auf ein Formularfeld verweist. Genau dafür gibt es schließlich labels.
Christian
-
Input <-> Label
Das ist aber suboptimal. Das Label sollte logisch _vor_ dem Input stehen.Das würde ein Araber oder Israeli wahrscheinlich genauso sehen, aber trotzdem das tun, was Simon tut.
Letztlich ist es doch aber egal, wo ein label steht, solange es per for auf ein Formularfeld verweist. Genau dafür gibt es schließlich labels.
Geuan genommen giebt es sogar zwei wichtige konventionelle Ausnahmen.
So hat es sich siet Urzeiten eingebürgert ein radio oder oder checkbox dem label voranzustellen, wobei solche Gruppen meist durch einen Titel eingeleitet sind. Assistive Technik kann natürlich immer den for Mechnanismus zu Hilfe nehmen. Nur bin ich ich leiden Betriebsblind wann genau ein User diese Technik nutzt.Ob rtl oder ltr, das spielt keine Rolle, denn das wird, bei richtigem Markup, automatisch angepasst.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
-
-
-
Hi,
or die ("Auswahl der Datenbank nich Möglich");2 Syntaxfehler im String ;-)
$name = $\_POST['name'];warum verschleierst Du die Herkunft der Daten?
function writeComment ($id, $name, $datum, $uhrzeit, $website, $email, $kommentar) $connectID = mysql\_connect($hostUrl, $userName, $password)Du hast oben doch schon eine Verbindung aufgemacht.
mysql\_query ("INSERT INTO comments (id, autor, datum, uhrzeit, website, email, kommentar) VALUES ('$id', '$name', '$datum', '$uhrzeit', '$website', '$email', '$kommentar')", $connectID)Autsch. Es fehlt mysql_real_escape_string - laß mal jemanden Namens O'Hara einen Kommentar über die O'Reillys schreiben ...
header ("Location: komm.php");Location erfordert eine komplette Url.
$connectID = mysql_connect($hostUrl, $userName, $password)
or die ("Tut mir leid, kann keine Verbindung zur Datenbank aufbauen");Und schon wieder wird eine Verbindung zur Datenbank aufgemacht. Wofür brauchst Du so viele Verbindungen?
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen unaufgefordert per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
-
»» $name = $_POST['name'];
warum verschleierst Du die Herkunft der Daten?
Ich habe jetzt schon öfters hier mitbekommen, dass es nicht gern gesehen ist wenn POST oder GET Variablen, zu beginn des Scriptes, in eine Variable geschrieben werden. Wieso eigentlich?
Falls sich irgendwann die übergebene Variable vom Namen her ändert, oder ein anderes Verfahren zur Übergabe verwendet wird, brauch ich das nur noch an einer Stelle im Code ändern.
Andernfalls hätte ich meine POST Variable im ganzen Script verteilt und müsste das überall anpassen.-
echo $begrüßung;
» »» $name = $_POST['name'];
» warum verschleierst Du die Herkunft der Daten?
Ich habe jetzt schon öfters hier mitbekommen, dass es nicht gern gesehen ist wenn POST oder GET Variablen, zu beginn des Scriptes, in eine Variable geschrieben werden. Wieso eigentlich?Sie stehen bereits in einer Variablen drin. $array['foo'] ist eine genauso perfekte Variable wie $foo. Zusätzlich zu den Einträgen im $_POST noch extra Variablen anzulegen erhöht nur die Komplexität des Scripts und bringt nichts ein außer einem angeblichen Vorteil beim Tippen der Variablennamen.
Falls sich irgendwann die übergebene Variable vom Namen her ändert, oder ein anderes Verfahren zur Übergabe verwendet wird, brauch ich das nur noch an einer Stelle im Code ändern.
Andernfalls hätte ich meine POST Variable im ganzen Script verteilt und müsste das überall anpassen.Wenn der Grund für eine Namensänderung trivial ist, hilft ein triviales Suchen und Ersetzen im Editor. Anderenfalls muss man sowieso den Code durchgehen und Anpassungen vornehmen.
echo "$verabschiedung $name";
-
Zusätzlich zu den Einträgen im $_POST noch extra Variablen anzulegen erhöht nur die Komplexität des Scripts und bringt nichts ein außer einem angeblichen Vorteil beim Tippen der Variablennamen.
Ein weiterer Grund könnte aber auch sein, dass noch ein anderes Skript auf diese Variablen zugreifen möchte und es daher unsinnig wäre die Variablen im $_POST selbst zu verändern, da das nächste Skript sonst keinen Zugriff auf die Originaldaten mehr hätte.
Außerdem erhöhte es meiner Meinung nach die Lesbarkeit des Codes, wenn diesen Variablen einen entsprechend sprechenden Namen bekommen.
Christian
-
echo $begrüßung;
» Zusätzlich zu den Einträgen im $_POST noch extra Variablen anzulegen erhöht nur die Komplexität des Scripts und bringt nichts ein außer einem angeblichen Vorteil beim Tippen der Variablennamen.
Ein weiterer Grund könnte aber auch sein, dass noch ein anderes Skript auf diese Variablen zugreifen möchte und es daher unsinnig wäre die Variablen im $_POST selbst zu verändern, da das nächste Skript sonst keinen Zugriff auf die Originaldaten mehr hätte.Wenn eine verarbeitende Stelle die Werte verändern möchte, um damit weiterzuarbeiten, sollte sie sich lokal Arbeitskopien anlegen. Wenn es generelle Aktionen an anderen Scriptstellen gibt muss man die immer im Auge behalten, was der Übersichtlichkeit und Kapselung von Vorgängen nicht unbedingt dienlich ist.
Außerdem erhöhte es meiner Meinung nach die Lesbarkeit des Codes, wenn diesen Variablen einen entsprechend sprechenden Namen bekommen.
Sie haben doch schon einen sprechenden Namen. Oder was ist an $foo sprechender als an $_POST['foo']?
echo "$verabschiedung $name";
-
echo $begrüßung;
echo $_POST['begrüßung'];
Sie haben doch schon einen sprechenden Namen. Oder was ist an $foo sprechender als an $_POST['foo']?
Bei Formularen wird man wahrscheinlich eher dazu geneigt sein sprechende Namen zu verwenden - muss man ja aber nicht. Bei urls werden Parameternamen doch ganz gern abgekürzt und da halte ich ein $searchterm für sinnvoller als ein $_GET['s'] .
echo "$verabschiedung $name";
echo $_POST['verabschiedung'].' '.$_POST['name'];
-
-
Hello,
Zusätzlich zu den Einträgen im $_POST noch extra Variablen anzulegen erhöht nur die Komplexität des Scripts und bringt nichts ein außer einem angeblichen Vorteil beim Tippen der Variablennamen.
Außerdem verhindert es die elegante Weitergabe der Werte an Funktionen.
Die Bindung von Variablen in einem "Array" ist gerade eine der Stärken von PHP. Warum sollte man die durch unsinnige Umkopieraktionen wieder zerstören.Ein weiterer Grund könnte aber auch sein, dass noch ein anderes Skript auf diese Variablen zugreifen möchte und es daher unsinnig wäre die Variablen im $_POST selbst zu verändern, da das nächste Skript sonst keinen Zugriff auf die Originaldaten mehr hätte.
Es gibt kein anderes Script, was auf die Elemente von $_POST zugreifen könnte. Zu jedem Script gehört immer nur genau ein $_POST-Array und umgekehrt!
Außerdem erhöhte es meiner Meinung nach die Lesbarkeit des Codes, wenn diesen Variablen einen entsprechend sprechenden Namen bekommen.
Den sprechenden Namen können sie bereits im $_POST-Array haben.
Und wenn man unbedingt eine Transformation benötigt, geht das auch mit einem Teilarray von $_POST und den neuen Namen sowie der Funktion array_combine() ganz bequem.Sinnvoll ist es z.B. im HTML bereits eine Differenzierung zwischen Daten, Controls und Buttons zu wählen.
<input name="formname[data][vorname]">
<input name="formname[data][nachname]"><select multiple name="formname[ctrl][beruf]">
<option value="0" selected>== bitte wählen ==</option>
<option value="11">Tischler</option>
<option value="12">Zimmermann</option>
<option value="21">Maurer</option>
<option value="22">Fliesenleger</option>
<option value="31">Koch</option>
</select><input type="submit" name="formname[btn][apply]" value="bestätigen">
lass Dir das $_POST-Array mal anzeigen.
Warum sollte ich nun diese in $_POST wohlsortiert ankommenden Parameter erst wieder zerreissen, obwohl ich doch so mit einer vereinheitlichten und immer wieder verwendbaen Überprüfungsfunktion (mit passender Transformationstabelle gefüttert) die Plausibilität der Parameter und ihrer Werte überprüfen kann.
Es kann nur einen [btn] geben
[data]-Inputs haben direkte Datenkopplung
[ctrl]-Inputs müssen übersetzt werden und ggf. ergänzt durch nicht übertragene Checkboxes, ...usw.
Ein Umkopieren in atomarisierte Variablen würde die ganze schöne Polimorphie, die einem PHP auch schon ohne explizite Verwendung der OOP förmlich aufdrängt, zerstört werden.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo
»» Zusätzlich zu den Einträgen im $_POST noch extra Variablen anzulegen erhöht nur die Komplexität des Scripts und bringt nichts ein außer einem angeblichen Vorteil beim Tippen der Variablennamen.
Ein weiterer Grund könnte aber auch sein, dass noch ein anderes Skript auf diese Variablen zugreifen möchte und es daher unsinnig wäre die Variablen im $_POST selbst zu verändern, da das nächste Skript sonst keinen Zugriff auf die Originaldaten mehr hätte.
Welches andere Skript soll das bitte sein? Wenn *dieses* Skript beeendet ist, gibt es kein
$_POST["foo"], aber auch kein$foomehr. Für den Fall der Wiederverwendung des Werts der Variable muss der Wert ansich gespeichert werden, ob als Text in einer Datei, in einer Datenbank oder in $_SESSION ist dabei egal. Welcher Name dann an diesen Stellen verwandt wird (wenn einer verwandt wird), ist eine ganz andere Sache.Tschö, Auge
-
-
Zusätzlich zu den Einträgen im $_POST noch extra Variablen anzulegen erhöht nur die Komplexität des Scripts
Finde ich nicht, ich finde eher das das zur Übersicht des Scriptes beiträgt.
Wenn der Grund für eine Namensänderung trivial ist, hilft ein triviales Suchen und Ersetzen im Editor.
Ok, in einer Zeit in der mittlerweile fast jeder Editor "Suchen und Ersetzen" anbietet, scheint das kein sehr gutes Argument mehr zu sein.
Aber nichtsdestotrotz würde man sich das sparen.Anderenfalls muss man sowieso den Code durchgehen und Anpassungen vornehmen
Nicht unbedingt. Wenn beispielsweise mein Wert plötzlich aus einer Textdatei oder einer Datenbank kommen würde, wäre es mit der "falschen" Vorgehensweise ein leichtes, dies im Script zu ändern.
Natürlich könne man auch $_POST['wert'] = Textdatei-Wert anwenden, aber...
Gruß
-
echo $begrüßung;
» Zusätzlich zu den Einträgen im $_POST noch extra Variablen anzulegen erhöht nur die Komplexität des Scripts
Finde ich nicht, ich finde eher das das zur Übersicht des Scriptes beiträgt.Was ist daran übersichtlicher, sich merken zu müssen, wo $foo herkommt?
» Anderenfalls muss man sowieso den Code durchgehen und Anpassungen vornehmen
Nicht unbedingt. Wenn beispielsweise mein Wert plötzlich aus einer Textdatei oder einer Datenbank kommen würde, wäre es mit der "falschen" Vorgehensweise ein leichtes, dies im Script zu ändern.
Ich halte ich nicht für sehr wahrscheinlich, dass ein Parameter plötzlich aus einer Datei kommen soll. Besonders unwahrscheinlich finde ich, dass damit dafür keine grundsätzliche Umgestaltung des Scripts notwendig ist.
echo "$verabschiedung $name";
-
-
-
-
-
Hallo.
MudGuard hat ja schon einiges zum Code geschrieben - dem kann ich soweit beipflichten, bis auf den zweiten Punkt.
$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
include("komm_vali.php");
1. Die Qualität deines Skriptes hängt sehr stark davon ab, was in diesem eingefügten File tatsächlich getan wird. Vielleicht kannst du den Inhalt hier mal posten. Auf alle Fälle solltest du es mit require() einbinden, da du sicher nicht möchtest, dass das Skript weiterläuft, wenn die Daten nicht validiert werden konnten. Das ist gerade darum notwendig, weil die Validierung anscheinend false zurückliefert, wenn die Daten nicht zu beanstanden sind.
if (!$error\_msg\_1 &&!$error\_msg\_2 &&!$error\_msg\_3 &&!$error\_msg\_4 &&!$error\_msg\_5 &&!$error\_msg\_6 &&!$error\_msg\_7) { writeComment(...Um ganz sicher zu gehen solltest du mit === testen ob die Variablen tatsächlich false sind und nicht etwa '0'.
2. Ich kann nur nochmal betonen, was MudGuard schrieb: nutze mysql_real_escape_string()! Wenn jemand einen Namen mit Apostroph besitzt mag die Fehlermeldung zwar ärgerlich sein, der richtige Schaden entsteht aber, wenn jemand gezielt falschen mysql-Code eingibt (SQL-Injektion). Solche Fehler sollte man sich garnicht erst angewöhnen! Den Claim "All userdata is evil." solltest du beim Programmieren nicht nur im Hinterkopf haben.
mysql_query ("INSERT INTO comments (id, autor, datum, uhrzeit, website, email, kommentar)
3. Hier würde ich für Datum und Uhrzeit den MySQL-Typ DATETIME verwenden. Das hat auch den Vorteil, dass du hier
$query = "SELECT * FROM comments ";
die Kommentare nach Datum sortiert ausgeben kannst.
$ausgabe_Autor = $row_out['autor'];
4. Ein weiterer großer Sicherheitsfehler! Da muss auf alle Fälle irgendwo ein htmlspecialchars() rein, sonst gebe ich dir als böser Mensch, der ich nun mal bin, soetwas wie
<script>alert('Ich bin böse.');</script>in dein Formular ein, oder zeige damit jedem deiner Besucher meine Layer-Ads an, lese ihre Cookies aus, setze mein eigenes Cookie und tue noch so einige andere böse Sachen. Mehr Informationen zum Cross-Site-Scripting gibt es hier.
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).
$_SERVER['PHP_SELF'];
5. Das Statement tut nichts. Sicher hast du das echo davor vergessen, aber genaugenommen ist das überflüssig. Wenn action leer ist wird automatisch auf die gleiche Seite verwiesen.
if($ausgabe_Website == "http://")
6. Nicht gut. Erstens würde ich keinen sinnlosen String speichern und zweitens spuckt die das else alles aus, was nicht 'http://' ist. Aber hier sind wir auch wieder bei der Blackbox namens 'include("komm_vali.php")'. Auf alle Fälle solltest du einen besseren Test wählen oder sichergehen, dass sonst nur zulässige URLs in der Datenbank gespeichert werden.
Soweit alles, das mir aufgefallen ist.
Christian
-
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 beiWas 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";
-