Tach!
Ein alter Trick ist, vor die Checkbox ein
<input type="hidden">
mit dem Wert für eine nicht angehakte Checkbox imvalue
zu notieren und dafür auch denselbenname
wie die Checkbox zu geben. Im Unausgewählt-Fall wird dieser Hidden-Input-Wert übertragen, wenn ausgewählt jedoch beide. PHP ignoriert aber den ersten Wert vom Hidden-Input und überschreibt ihn mit demvalue
der Checkbox.Übel! Weil dieser fragwürdige Trick nur deswegen so funktioniert, weil der Parser in PHP nicht RFC gerecht arbeitet. Es ist eine ganz schlechte Empfehlung es so zu machen!
Ist die RFC das einzige Argument zu dieser Empfehlung? Gibt es wenigstens berechtigte Gründe, warum man dieses Verhalten nicht nutzen sollte? Das Formular hat als Ziel lediglich dieses eine PHP-Script und damit keine anderen Ziele, die mit dem doppelten Feld umgehen müssten. Browserseitig irgendwas? Assistive Techniken und Hidden-Inputs? Vermutlich belanglos.
Man kann natürlich auch im PHP-Script etwas tun. Zum einen wäre das, das $_POST-Array auf die fehlenden Elemente für die nicht gesetzten Checkboxen zu untersuchen und sie bei Nichtvorhandensein mit dem gewünschten Wert (vermutlich 0) nachzutragen. Achtung, Regenschirm aufspannen, an der Stelle kommen einige Aufreger aus allen Wolken gefallen. Warum eigentlich? Nur weil man da das $_POST-Array an seine Bedürfnisse anpasst und das aus irgendeinem Grunde Frevel wäre?
Ein alternatives Vorgehen ist, sich eine eigene Datenstruktur zu schaffen, am besten wohl ein Array, aber eine Handvoll lose Variablen tut es im Grunde genommen auch. Diese(s) befüllt man mit den vorhandenen Werten aus dem $_POST-Array, oder mit Default-Werten bei Abwesenheit. Danach ignoriert man das $_POST-Array und arbeitet mit den eigenen Daten weiter. Kann man machen, muss man aber nicht. So ein Vorgehen führt in kleinen Scripten nur neue Variablen ein, ohne dass die Vorteile daraus großartig spürbar sind. Mehr Nutzen ergibt sich erst wenn die Angelegenheit größer wird und ein komplexes Programm entstehen soll, bei dem eigenständige Komponenten erstellt werden zum Zwecke des TDD, und um das Chaos der Komplexität organisatorisch in die Schranken zu weisen, sprich: möglichst wenig Abhängigkeiten zu anderen Komponenten und am besten gar keine zu globalen Dingen, wie eben dem $_POST-Array. Eine Komponente ist dann schön übersichtlich, wenn man oben Parameter einfüllt, unten das Ergebnis entgegennimmt, und sie nicht seitwärts auf irgendwelche Dinge zugreift, für deren Anwesenheit man auch noch sorgen muss, dies aber nicht aus der Parameterliste beim Aufruf erkennen kann.
Das und noch mehr Prinzipien, die zusammengefasst den Namen SOLID bekamen, sind zwar erstrebenswert - je größer die Projekte desto mehr -, und man kann sich ja auch im Kleinen daran orientieren, um es später die großen mit diesbezüglicher Erfahrung anzugehen, doch das muss der Probleminhaber für sich entscheiden. Schönheit kostet auch ihren Preis, vor allem Zeit.
dedlfix.