Feldwert SQL-Statement in Feldtyp text und hidden führt zum Fehler

Hallo Aicha, hallo Ingmar,
hier eine weitere Fehlermeldung bei folgenden Voraussetzungen:
Joomla 6.2.1, PHP 8.3, Visforms+Subscription 6.2, Testformular "Alle Felder", Felder vom Typ Text oder Versteckt:  SQL-Feld = JA
Feldwert SQL-Statement:

Beim Speichern des Formulars im Frontend führt das zum Fehler:
Ihre Eingabe im Feld "Versteckt" / "Text"  ist nicht gültig.
In der Konsole kann ich sehen, dass das Feld außerdem nicht mit dem Namen des eingeloggten Users gefüllt wird.
Hat sich die Syntax der Platzhalter geändert oder ist das ein Fehler? Mal abgesehen davon, dass ich das heute nicht mehr mit einem SQL-Feld, sondern mit der Option Startwert = "Konto: Name" lösen würde (was auch funktioniert).

LG Heinz

Hallo Heinz,

die Verwendung von SQL Statements in textähnlichen Feldern und die Syntax der SQL Statements/Platzhalter hat sich zwischen Visforms für Joomla 5 und Visforms für Joomla 6 nicht geändert.

Du musst unterscheiden zwischen dem Defaultwert und dem Feldwert.

Das Defaultwert SQL Statement wird einmalig ausgeführt, wenn das Formular geladen wird.
Es wird verwendet wenn das Formularfeld bei der Anzeige des Formular mit einem Wert zu füllen, der durch eines SQL Statements ermittelt wird.
Wenn du dort dein SQL Statement einträgst und ein angemeldeter Benutzer das Formular öffnet, wird korrekt immer sein Name in des Feld eingetragen.

Das Feldwert SQL Statement wird nur ausgeführt, wenn ein Nachladen des Formularfeldes getriggered wird.
D.h. damit tatsächlich ein Feldwert durch dieses SQL Statement gesetzt wird, wird es in Verbindung mit der Option 'Nachladen bei Änderung von' verwendet.
Das Feldwert SQL Statement ist interessant, wenn du den Wert in einem Feld abhängig von Benutzereingaben ändern willst.
Wenn ein Feldwet-SQL Statement hinterlegt ist, werden übermittelte Benuztereingaben immer dahingehend validiert, dass sie diesem SQL Statement entsprechen.

D.h.
Du musst dein statisches SQL Statement an erster Stelle beim Defaultwert SQL Statement eintagen.
Dann wird der Wert automatisch in das Formularfeld eingetragen.

Wenn du verhindern willst, dass der Benutzer den Wert ändern kann hast du verschieden Möglichkeiten.
Du kannst das Feld 'Readonly' machen.
Du kannst den Feldtyp 'versteckt' verwenden.
Du kannst das Feld mit Hilfe von CSS verstecken.

Du kannst zusätzlich dasselbe SQL Statement beim Feldwert SQL (ohne Reload trigger) eintragen.
Damit erreichst du, dass die Benutzereingabe im Formular serverseitig gegen dieses SQL Statement validiert wird.
D.h. selbst wenn jemand durch Manipulation einen anderen Wert übermittelt, wird dieser nicht akzeptiert.

Es gibt mittlerweise ein sehr umfassende Dokumentation zu den SQL-Felder, auch eine eigene Seite zu den textähnlichen SQL Feldern
[url] docs.joomla-6.visforms.vi-solutions.de/d...s-text-typed-fields/ [/url]

Und es gibt einen ganzen Abschnitt in der Dokumentation zu Platzhaltern
[url] docs.joomla-6.visforms.vi-solutions.de/d...isforms-placeholder/ [/url]

Liebe Grüße,
Aicha

Du kannst zusätzlich dasselbe SQL Statement beim Feldwert SQL (ohne Reload trigger) eintragen.
erreichst du, dass die Benutzereingabe im Formular serverseitig gegen dieses SQL Statement validiert wird.

Das ist wohl neu.
Es geht mir nicht um den Defaultwert, (der ist immer leer, wegen EditOnly), sondern um den Feldwert. 
Bisher hatten wir es so: ein HiddenFeld mit EditOnly und besagtem SQL (ohne Trigger, kein Startwert) trägt beim Editieren eines Datensatzes den Namen des Bearbeiters (Admins) ein, der dann in der Edit-Mail im Betreff mit Platzhalter übermittelt wurde (bearbeitet durch Admin xyz). Funktioniert seit Jahren so. Jetzt kann man den Datensatz nicht mehr editieren, da mit dem SQL serverseitig gegen den alten Wert geprüft wird. Das führt immer zum Fehler, außer: der aktuelle Admin hatte den Datensatz bereits selbst einmal geändert. Bei erstmalig zu ändernden Datensätzen und wenn sich der Bearbeiter ändert, funktioniert das Speichern nicht mehr.
Wenn ich nun neu Triggerfelder aus der ReloadListe auswähle, werden die alten Werte dieser Felder gelöscht. Das kann auch nicht so gewollt sein.
Ziel ist also wieder: der aktuelle Bearbeiter/Editor soll in das Hidden-Feld eingetragen werden und das Formular gespeichert werden können.
Dieses Verhalten lässt sich mit einem neuen Testformular "alle Felder" und 10 befüllten Datensätzen einfach nachstellen, wenn man das HiddenFeld EditOnly macht und als Feldwert SQL ($user:name wie oben) einträgt, wahlweise auch mit allen auswählbaren ReloadFeldern (dann werden bestehende Inhalte gelöscht).
Vielleicht habe ich mich jetzt besser ausgedrückt.
LG Heinz

Hallo Heinz,

danke für die zusätzliche, wichtige Information zum Nachstellen des Fehlers, dass es sich um ein Edit-Only Feld handelt.

Liebe Grüße,
Aicha

Gerne,
übrigens (ich muss das nach weiteren Tests präzisieren):
der Fehler, dass gespeicherte Eingaben bei der Wiedervorlage des Formulars gelöscht werden, lässt sich auch ohne Edit-Feld nachbilden. Es reicht, wenn ein beliebiges Triggerfeld "Bei Änderung von nachladen" ausgewählt wird. Es werden dann alle Formulareingaben aller Felder gelöscht.
Das war in der 5er Version auch nicht. Macht ja auch keinen Sinn. Bin mir nicht sicher, ob es ein zweiter anderer Fehler ist. Es kommt jedenfalls zu einem JavaScriptfehler:
visforms.js?bdf0dd:69 TypeError: Cannot read properties of null (reading 'id')
    at Visforms.getUserInputByFieldId (visforms.js?bdf0dd:724:41)
    at visforms.js?bdf0dd:168:36
    at NodeList.forEach (<anonymous>)
    at Visforms.initFields (visforms.js?bdf0dd:166:51)
    at Visforms.initForm (visforms.js?bdf0dd:91:14)
    at visforms.js?bdf0dd:67:18

Hallo Heinz,

danke für dein gründliches Testen und die immer genauere Beschreibung des Problems.
Ich kann das Verhalten (den Validierungsfehler) jetzt reproduzieren und sehe auch den Unterschied zwischen Visforms 5 und Visforms 6.

Wir sehen das als einen Bug in Visforms an und werden das Verhalten anpassen.
Ich habe dazu einen Issue zur Entwicklung in der Bug-Liste angelegt:
Issue [VF-1782]: Setting value with sql in text like fields behaves differently between Visforms 5 and 6

Wenn wir den Bugfix releasen, wirst du explizit über das Release hier im Thema informiert.
Eventuell gibt es für diesen Bug sehr kurzfristig auch einen Datei-basierten Hot-Fix.
Vielen Dank nochmal für deinen Hinweis!

Liebe Grüße,
Aicha