2 checkboxen mit foreach in PHP auswerten

[slante]

Hallo liebe Spezialisten habe folgende Auswertung schon gemacht und die funktioniert:

    foreach ($_POST as $key => $value) {

        if (isset($fields[$key])) {
            $emailText .= "$fields[$key]: $value\n";
        }
    }

Wenn ich danach noch folgende zweite Checkbox-Auswertung setze:

foreach ($wahl as $elem) {
 
 echo "$elem<br>";
 
 } 

wird diese nicht abgearbeitet und erscheint nicht in der Emailauswertung. Kann man zwei "foreach" nicht im PHP verarbeiten? Wie mache ich das? Merci für eine Antwort! Gruss Slante

[dedlfix]

Tach!

Kann man zwei "foreach" nicht im PHP verarbeiten? Wie mache ich das?

Doch man kann. Warum das bei dir nicht geht, kann ich dir nicht sagen. Da musst du jetzt mal Debugging betreiben. Welche Werte stehen in den Variablen? var_dump() zeigt sie an. Du wirst dann vielleicht sehen, dass sie sich von deinen Vorstellungen unterscheiden, und dann solltest du rückwärts bis zur Quelle verfolgen, wo die Ungereimtheiten enstehen.

dedlfix.

[Gunnar Bittersmann]

@@slante

foreach ($wahl as $elem) {

Wo kommt den $wahl her?

 echo "$elem<br>";

Hier muss es mit ziemlicher Sicherheit echo htmlspecialchars($elem) . '<br>'; heißen.

Wobei das <br> fraglich ist. Wenn es sich um eine Liste handelt, sollte das als solche ausgezeichnet werden, nicht mit Zeilenumbrüchen gefaket werden.

LLAP 🖖

[slante]

Das "wahl" kommt von der Checkbox:

<label class="lead_weiss"><input type="checkbox" name="wahl[]" value="FIGUREN - 3D"> &nbsp;FIGUREN - 3D&nbsp;&nbsp;</label>
 <label class="lead_weiss"><input type="checkbox" name="wahl[]" value="FIRMEN"> &nbsp;FIRMEN&nbsp;&nbsp;</label>

[dedlfix]

Tach!

Das "wahl" kommt von der Checkbox:

Nein, nicht ohne weiteres. PHP legt schon seit langem keine Variablen außerhalb von $_POST und $_GET für Formulardaten an. Wenn du es nicht aus irgendeinem Grunde umkopiert hast, ist $wahl nicht vorhanden.

Du kannst das error_reporting auf E_ALL stellen und display_errors auf on, dann werden Zugriffe auf nicht vorhandene Dinge auch angezeigt.

dedlfix.

[pl]

Statt

> name="wahl[]" value="FIGUREN - 3D"
> name="wahl[]" value="FIRMEN"

ändere die Namen in name="wahl[FIGUREN]" und name="wahl[FIRMEN]" so hast Du die dazugehörigen Values mit PHP serverseitig gleich in einer passenden Datenstruktur. MfG

[dedlfix]

Tach!

> name="wahl[]" value="FIGUREN - 3D"
> name="wahl[]" value="FIRMEN"

ändere die Namen in name="wahl[FIGUREN]" und name="wahl[FIRMEN]" so hast Du die dazugehörigen Values mit PHP serverseitig gleich in einer passenden Datenstruktur.

Das sehe ich noch nicht so. Ob die Struktur passend ist, vermag ich ohne Kenntnis des konkreten Anwendungsfalls nicht beurteilen.

Mit seiner Schreibweise kann man jedenfalls mit

    foreach ($_POST['wahl'] as $value)

über die ausgewählten Einträge laufen. (Die nicht ausgewählten bleiben generell außen vor, die werden ja vom Browser nicht mit übermittelt.)

Nach deinem Vorschlag hat man die Values nun stattdessen in den Keys.

    foreach ($_POST['wahl'] as $name => $value)

Wenn man das value-Attribut weglässt, enthält die Variable $value enthält stets den Wert 'on', ist also nicht weiter sinnvoll verwendbar, muss aber aus syntaktischen Gründen angegeben werden. Bleibt das value-Attribut wie es ist, hat er den Wert nun doppelt, im Key und als Value. Mit und ohne value-Attribut sehe ich hier noch keinen Vorteil.

Auch wenn man konkret auf einzelne Werte prüfen möchte, ist mit

    in_array('FIRMEN', $_POST['wahl'])

oder

    isset($_POST['wahl']['FIRMEN'])

weder das eine noch das andere "passender" als die andere.

Und wenn ich mir das $_POST-Array so ansehe, sieht statt des bisherigen

$_POST['wahl' => [
   'FIRMEN',
   'FIGUREN - 3D'
]]

ein

$_POST['wahl' => [
    'FIRMEN' => 'FIRMEN',
    'FIGUREN - 3D' => 'FIGUREN - 3D'
]]

beziehungsweise

$_POST['wahl' => [
    'FIRMEN' => 'on',
    'FIGUREN - 3D' => 'on'
]]

auch irgendwie nicht "passender" aus.

dedlfix.

[pl]

Du musst natürlich auch sinnvolle Values setzen wenn Du mehr als ein 'on' haben willst.

[dedlfix]

Tach!

Du musst natürlich auch sinnvolle Values setzen wenn Du mehr als ein 'on' haben willst.

Ja, diese Variante habe ich berücksichtigt. Wird dadurch aber nicht besser.

dedlfix.

[Auge]

Hallo

Wenn ich danach noch folgende zweite Checkbox-Auswertung setze:

foreach ($wahl as $elem) {
 echo "$elem<br>";
 }

wird diese nicht abgearbeitet und erscheint nicht in der Emailauswertung. Kann man zwei "foreach" nicht im PHP verarbeiten?

Doch, kann man, sogar beliebig viele.

Wie mache ich das?

Grundsätzlich so, wie du es zeigst, auch wenn die Konstruktion deines echo nicht so prall ist. Einerseits vermischst du String und Variable, auch wenn das von der Sprache erlaubt ist, andererseits hast du (auch wegen dieser Vermischung) keine kontextgerechte Behandlung der Eingabewerte in $elem. Die müssen für die Ausgabe in HTML durch htmlspecialchars gejagt werden, damit nicht unerwartete Zeichen die Ausgabe im Browser (zer)stören. Besser echo htmlspecialchars($elem) . "<br>";.

Davon abgesehen stellt sich die Frage, was die Variable $wahl vor der Schleife enthält. Mit var_dump($wahl) kannst du dir Struktur und Inhalt der Variablen anzeigen lassen. Siehe dazu auch var_dump in der PHP-Doku.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Die müssen für die Ausgabe in HTML durch htmlspecialchars gejagt werden, damit nicht unerwartete Zeichen die Ausgabe im Browser (zer)stören.

Unerwartete Zeichen sind das geringste Problem. Sicherheitslöcher sind das Problem.

Besser echo htmlspecialchars($elem) . "<br>";.

Ersetze „besser“ besser duch „unbedingt“.

Rekursiv. 😉

Wenn String und Variable nicht mehr vermischt sind, muss in <br> nicht mehr nach Variablen geparst werden. Also einfache Anführungszeichen drumrum, nicht doppelte. Das spart Rechenleistung und leistet damit einen kleinen Beitrag gegen die globale Erwärmung.

LLAP 🖖

[Auge]

Hallo

Die müssen für die Ausgabe in HTML durch htmlspecialchars gejagt werden, damit nicht unerwartete Zeichen die Ausgabe im Browser (zer)stören.

Unerwartete Zeichen sind das geringste Problem. Sicherheitslöcher sind das Problem.

Ja, aber nein.

Unerwartete Zeichen sind im Gegensatz zu Sicherheitslöchern das nachvollziehbarere Argument. Bei „Achtung, könnte Sicherheitslöcher enthalten!“ kommt — auch hier — immer wieder die Entgegnung, dass die Daten ja von einem selbst stammen (aus der eigenen Datenbank oder Datei oder …) und daher sicher seien. Das Bewusstsein, dass sich dort Fehler eingeschlichen haben könnten oder die Dateien oder Datenbankdaten von dritter Seite manipuliert worden sein könnten, existiert bei vielen Fragenden einfach nicht.

Mit „unerwarteten Zeichen“ kann, aufgrund der Allgemeinheit des Begriffs, alles Mögliche gemeint sein. Das schließt Zeichen, die „nur“ den HTML-Quelltext zerstören (< oder &) genauso ein wie ganze Blöcke von eingeschmuggeltem JS-Code, die unmaskiert im Browser zur Ausführung kämen. Also Sicherheitslöcher ebenso wie Unschönheiten, die sich auschließlich in der Darstellung niederschlügen. Zudem ist nach meiner Erfahrung die Reaktion wohlwollender „Wie jetzt? Das will ich nicht, dagegen mach ich auch was!“.

Die bei weitem gravierenderen Auswirkungen — für den Betreiber eines Angebots genauso wie für seine Besucher und/oder Benutzer — haben natürlich Sicherheitslöcher. Die sind bloß oft nicht so einfach vermittelbar, gerade gegenüber Anfängern, denen das Gefühl für die möglichen Bösartigkeiten dieser Welt fehlt.

Tschö, Auge

[Auge]

Hallo

Nur, um das klarzustellen:

Die müssen für die Ausgabe in HTML durch htmlspecialchars gejagt werden, damit nicht unerwartete Zeichen die Ausgabe im Browser (zer)stören.

Unerwartete Zeichen sind das geringste Problem. Sicherheitslöcher sind das Problem.

Ja, aber nein.

Mit meinem Vorposting wollte ich Gunnar nicht widersprechen, sondern klarmachen, dass ich die Formulierung „unerwartete Zeichen“ bewusst gewählt habe und warum ich das tat.

Tschö, Auge

[Felix Riesterer]

Liebe(r) slante,

Lesetipp hier im Wiki: Formulardaten serverseitig auswerten

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

Liebe(r) slante,

Mit r sollte passen: „Lieber ‚Sláinte‘ als gar kein Bier.“ 🍻

LLAP 🖖