yakamara
choice Feld: select mit json als Wertliste - Auswahl wird nicht in DB gespeichert
{"3,00 €":"3,00 €","4,00 €":"4,00 €","4,50 €":"4,50 €"} Das Feld wird zwar korrekt angezeigt, aber der Wert wird nicht in der Datenbank gesepeichert. Wenn das Komma durch einen Punkt ersetzt wird, klappt es (thx @alexplusde )
Liegt wohl daran, dass beim Parsen ein explode auf die Kommata gemacht wird...
Das Feld wird zwar korrekt angezeigt, aber der Wert wird nicht in der Datenbank gesepeichert. Wenn das Komma durch einen Punkt ersetzt wird, klappt es
So wäre es auch korrekt. Deine Werte würde ich sogar noch ohne das €-Zeichen speichern.
Das war bereits früher schon beim radio Value so. Kommawerte mussten escaped werden.
Die json-Schreibweise legt das nicht nahe. Das Feld wird ja auch korrekt dargestellt, nur der Wert nicht übernommen. Dachte nur vielleicht würde das jemand interessieren.
Ich sehe das auch so, dass die JSON-Schreibweise eine Alternative zum Komma-Explode ist und daher müsste gelten JSON > explode().
Sollte das aktuelle Verhalten so beibehalten werden, wäre es sinnvoll, die Beispiele beim Feld um ein Beispiel mit Escaping zu erweitern - dann kann man im Zweifel direkt erkennen, dass hier escaped werden muss.
Es geht auch nicht ums Escaping, das würde man hinkrigen und ich kann mit dem "." leben.
Ist halt ein blöde Kombination. Feld wird korrekt dargestellt, aber der Wert wird nicht gespeichert. Klar hätte ich genauer Testen können. Aber bei mir haben gerade 40 Leute einen Fragebogen ausgefüllt und die wichtigste Frage nach dem Preis wurde nicht gespeichert...
Es liegt nicht an der Json Schreibweise, sondern am generellen Verarbeiten von multiplen Werten bei YForm.
Aktuell werden mehrere ausgewählte Werte kommasepariert in der Datenbank gespeichert. Diese Werte werden mittels explode in ein Array geschrieben und weiterverarbeitet.
Beim Choice passiert das hier https://github.com/yakamara/redaxo_yform/blob/master/lib/yform/value/choice.php#L28
Beim be_manager_relation hier https://github.com/yakamara/redaxo_yform/blob/master/plugins/manager/lib/yform/value/be_manager_relation.php#L52
Jetzt ist es so, dass ein Wert mit einem Komma, der als Request ankommt, als solches nicht erkannt wird und in
value = ["3", "00 €"]
aufgesplittet wird. Vom Choice werden diese 2 Werte als nicht existent erkannt (proofedValue).
Kurz um, es ist ein generelles Problem mit kommaseparierten Werten und müsste allgemein geklärt werden wie man damit weiter in den Values umgehen sollte. Das Choice selbst hält sich an die derzeitige Vorgehensweise.
ping @dergel
Leider wirklich nicht lösbar, ohne ein Riesenfass aufzumachen.. Ich verschiebe es auf 4.0
Ich nutze yForm 3.4.1 und bin über dieses Problem kürzlich wieder gestolpert: Sobald Kommata in den Choices (genauer: In den Values der Choices) vorhanden sind, funktioniert die weitere Verarbeitung nicht mehr (E-Mail, Datenbank bekommen die Werte nicht).
Was passiert wenn du das Komma für den Wert so
\,notierst?
Es passiert bei mir das gleiche: Keine Werte in der E-Mail, aber Select-Feld wird korrekt angezeigt. Dieses Verhalten betrifft alle Formen (Komma-separiert, JSON).
Als Workaround nutze ich das JSON-Format und ersetze in den Values alle Kommata mit einem anderen Symbol, z.B. Punkt. In meinem Fall können die Punkte dann im E-Mail-Template einfach per str_replace() wieder durch Kommata ersetzt werden:
yForm Forbuilder:
choice|mein_feld|Preis auswählen|{"3,00 €":"3.00 €","4,00 €":"4.00 €","4,50 €":"4.50 €"}
E-Mail-Template:
<?= str_replace(".", ",", REX_YFORM_DATA[field="mein_feld"]); ?>
Wäre schön, wenn die Verarbeitung irgendwann klappen würde, denn insbesondere der Formbuilder wird gerne auch mal von Laien genutzt.
Noch der Vollständigkeit wegen ein Workaround, der für mich funktioniert hat - das UTF-8-Zeichen für ein einfaches Anführungszeichen unten ‚ (zum Vergleich , das Komma)
@tbaddade lässt sich das nicht so lösen:
https://github.com/yakamara/redaxo_yform/blob/186709591fc24230cf671506f221b97343174f08/lib/yform/value/choice.php#L26-L30
stattdessen
if (null === $this->getValue()) {
$this->setValue([]);
} elseif (!is_array($this->getValue())) {
$json= json_decode($this->getValue());
if (json_last_error() === JSON_ERROR_NONE) {
$this->setValue($json);
} else {
$this->setValue(explode(',', $this->getValue()));
}
}
Ich weiß nicht, wie choice mit multidimensionalen Arrays umgeht an der Stelle, aber so ähnlich sollte es doch zu lösen sein?
$this->getValue() ist kein Json sondern der übergebene Wert aus dem Formular oder der gespeicherte Wert aus der DB.
Wenn mehrere Werte (multiple) in die DB kommen, so werden diese von YForm kommasepariert gespeichert.
Bsp.:
1,2,3
Deshalb der explode mit dem ,, um die einzelnen Werte abzuholen.
value wäre jetzt:
["1", "2", "3"]
multiple Bsp. von @tyrant88
3,50 €,4,00 €,4,50 €
value wäre jetzt:
["3", "50 €", "4", "00 €", "4", "50 €"]
Hier ist es jetzt so, dass auch ein single Wert wie 3,50 € ein Komma enthält und somit exploded wird.
value wäre jetzt:
["3", "50 €"]
Und da diese Werte nicht als Choices, egal ob String, Json oder SQL vorliegen (proofValues), werden diese übergangen.
Ich hoffe es wird jetzt etwas klarer.
Die einzige Möglichkeit die ich sehe, dass Choice sich selbst um das Komma kümmert und es mit einem anderen Zeichen maskiert. Das sehe ich aber als falschen Weg, denn es ist eben ein allgemeines Problem in YForm. YForm sollte zumindest vorgeben, wie Kommas in Werte behandelt werden.
Ah, verstehe. die hätten also grundsätzlich schon in YForm bspw. escaped werden müssen und rückwirkend ist das nicht mehr handlebar, ohne entweder abgespeicherte Werte oder die Formulardefinition damit kaputt zu machen.
Okay, das ist blöd und ein Mega-Aufwand auch wenn man es bspw. für die YForm 5.x umsetzen würde.