Gravity Forms: eigenen Platzhalter für „andere Auswahl“ bei Radio Buttons angeben

Die Vorteile und Nachteile von Radio Buttons

Optionsfelder oder Radio Buttons sind ein Element, um in Formularen vorher festgelegte Informationen abzufragen. Im Gegensatz zu klassischen Auswahl- oder Checklisten kann bei Radio Buttons keine Mehrfachauswahl stattfinden. Zum Beispiel kann die Frage Was ist deine Lieblingsfarbe? bei zwei Antwortmöglichkeiten wie zum Beispiel „Rot“ und „Blau“ nur mit „Rot“ ODER „Blau“ beantwortet werden. Aber was passiert, wenn meine bevorzugte Antwort durch die möglichen Antworten gar nicht abgedeckt wird? Was wenn meine Lieblingsfarbe „Grün“ ist?
Einen etwas größeren Abriss eines strukturellen „Nachteils“ beschreibe ich am Ende dieses Artikels.

Wie reagiere ich auf Unvorhergesehenes?

In diesem Fall gibt es zwei Möglichkeiten, sich zu behelfen:

1. Erweiterung der Antwortmöglichkeiten um eine Antwortoption „weder noch“
2. Erweiterung der Antwortmöglichkeiten um eine individuelle Antwortoption

Bei der ersten Variante erhält der Fragende immerhin die Information, dass die Lieblingsfarbe weder „Blau“ noch „Rot“ ist. Leider erfahren wir aber dann nicht, was denn jetzt die Lieblingsfarbe des Antwortenden ist. In einem weiteren Schritt könnte man jetzt mit einer zusätzlichen Abfrage arbeiten, bei der die abweichende Lieblingsfarbe angegeben werden kann. Die meisten WordPress Formularplugins bieten mittlerweile diese conditional logic an, um solche Probleme zu lösen.

Die „Andere Auswahl“ Abkürzung

Beim Gravity Forms Plugin kann man auch mit der zweiten Variante arbeiten. Die individuelle Antwortoption kann gleich im Radio Button Feld integriert werden. Dafür muss das „Andere Auswahl aktivieren“ Häkchen gesetzt sein. Dann erscheint im Formular unter den vorgegebenen Optionen wie „Rot“ und „Blau“ eine einfache Textzeile, wo ich stattdessen „Grün“ eintragen könnte. Ich erspare mir also den Weg über ein zusätzliches Feld und eine conditional logic.

Nun arbeite ich gern mit Platzhaltern, weil diese als nützlicher Hinweis im Eingabefeld direkt auffallen. Ein standardmäßig ausgegebener Platzhalter wie „sonstiges“ ist in vielen Fällen zu allgemein formuliert. In meinem Beispiel mit der Lieblingsfarbe wäre ein Platzhalter wie „andere Lieblingsfarbe“ individueller, treffender und damit besser geeignet.

Nur wie ändert man den Platzhalter bei Radio Buttons in Gravity Forms ab?

Und wieder mal ein Code Snippet als Lösung

Das Gravity Forms Plugin wird immer weiter ausgebaut und mittlerweile gibt es für viele Anwendungsfälle ein Code Snippet. So auch hier:

add_filter( 'gform_other_choice_value', 'set_placeholder', 10, 2 );
function set_placeholder( $placeholder, $field ) {
	global $post;
    if ( is_object( $field ) && 123 === $field->id && 1 === $field->formId ){
        $placeholder = 'andere Lieblingsfarbe';
    }
    return $placeholder;
}

Keine Angst, ich erkläre alles.

Erst einmal müsst ihr herausfinden, wie die Formular ID des Formulares lautet (im Beispielcode lautet die ID „1“). Im Gravity Forms Bereich des WordPress Backends könnt ihr euch die existierenden Formulare auflisten lassen und in der Spalte den ID Wert bestimmen.
Ebenso muss die ID des Radio Button Formularfeldes angegeben werden (hier „123“). Im Formular Bearbeitungsmodus wird die Feld ID immer angezeigt, sobald man die Einstellungen eines bestimmten Formularfeldes bearbeitet.
Der Eintrag unter $placeholder dürfte selbsterklärend sein.

Wo kommen solche Code-Schnipsel überhaupt hin?

Klassisch werden solche Code Snippets in die Datei functions.php des aktiven WordPress Themes eingetragen. Wenn es sich um ein Child Theme handelt, ist die functions.php vor Überschreibungen durch Theme Updates sicher. Bei Parent Themes / Eltern Themes ist das was anderes. Bei einigen Premium Themes kann man mittlerweile solche Schnipsel in den Theme-Optionen sicher hinterlegen und abspeichern. Dann kann auch ein Theme Update nicht mehr gefährlich werden.
Der einfachste Weg ist aber die Nutzung eines Plugins wie Code Snippets. Hier werden solche Code Snippets zentral verwaltet und funktionieren auch dann, wenn das Theme mal gewechselt wird.

Nachtrag: Strukturelle Probleme bei Radio Buttons

Radio Buttons lassen sich leicht Informationen abfragen, da die Antwortmöglichkeiten meistens vorgegeben sind. Je eindeutiger die Kriterien, desto exakter die Information. Schwierig wird es, wenn man man mittels solcher Optionsfelder Informationen abfragen will, bei denen keine eindeutige Kategorienbildung möglich ist. Früher war es bei der Abfrage des Geschlechtes einfach: „männlich“ / „weiblich“ (optional vielleicht noch: keine Angabe). Heute behilft man sich (mehr schlecht als recht) mit der Option „divers“. Unter divers wird mittlerweile soviel subsumiert, dass ein einfaches „divers“ vieles an Information verschluckt. Noch schlechter sieht es bei der Frage nach dem sozialen Geschlecht aus.

Aber auch der Trick mit der eigenen Auswahloption kann nach hinten losgehen. Ich frage nach Lieblingsfarben und bei den festen Optionen „Blau“ und „Rot“ erhalte ich Antworten, die innerhalb des zu erwartenden Bereiches liegen. Stelle ich es dem Antwortenden frei, eine eigene Antwort zu formulieren, muss ich damit rechnen, dass die Antwort im nicht definierten Bereich liegt. So zum Beispiel, wenn derjenige mit „salzig“ antwortet, was bei der Frage nach der Lieblingsgeschmacksrichtung wahrscheinliche eine weiterführende Antwort wäre, aber eben nicht bei der Lieblingsfarbe. Das lässt sich auch durch die Technik (noch) nicht verhindern.
Weiterhin können die Antworten leicht verschieden klingen, aber dennoch dasselbe meinen. Betrachtet man alles unter der Prämisse einer exakten Formulierung, dann wären „Grün“, „grün“ und „gruen“ 3 unterschiedliche Antworten. Das kann man durch ein Suchen und Ersetzen noch bereinigen, denn es ist sehr klar, das gemeint war. Aber es wird noch schlimmer: „Grasgrün“ und „Smaradgrün“ sind definitiv 2 unterschiedliche Antworten, auch wenn wir uns nach gesundem Menschenverstand auf den Oberbegriff „Grün“ verständigen könnten. Vielleicht hätten auch die Antwortenden mit der Option „Blau“ vielleicht lieber mit „Kobaltblau“ oder „Preussisch Blau“ geantwortet, wenn sie die Möglichkeit gehabt hätten – wir wissen es nicht. Letztlich haben sie sich dann für den Oberbegriff entschieden. Während wir bei den vorgegebenen Antwortoptionen einen Informationsverlust durch begriffliche Generalisierung akzeptieren müssen, erfahren wir bei den eigenen Antwortoptionen eine differenziertere Information, was den Auswertenden vor Probleme stellt. Entweder man akzeptiert diesen Zustand und muss ihn aber bei der Analyse und vor allem Interpretation berücksichtigen oder man muss in einer nachträglichen Arbeit alle Zustände von „Grün“ und anderen Farben („Feuerrot“, „Karmesinrot“, „Kastanienbraun“, „Sienabraun“ …) vereinfachen und auf die Informationsebene von „Rot“ und „Blau“ bringen. Dies bedeutet bewusst herbeigeführten Informationsverlust und eine potentielle Verfälschung, denn was machen ich bei „Türkis“? Eigene Farbe? Oder doch eher „Blau“ als Oberbegriff? Wieviel spricht für „Grün“.
Und immer muss man den Aufwand der manuellen Nachbearbeitung in Relation zur Bedeutung der dadurch gewonnenen Information setzen. Schließlich sind wir hier nur bei der Frage nach der Lieblingsfarbe und ich gehe davon aus, dass dabei nicht über Leben und Tod entschieden wird (gut, bei den Rittern der Kokosnuss sah das anders aus). Es sind natürlich ganz andere Fragen denkbar, aufgrund deren Ergebnisse nachhaltige Entscheidungen getroffen werden. Da erhält das Design von Fragebögen / Formularen eine ganz andere Bedeutung, aber letztlich decken wir das mit Tips und Tricks zu Gravity Forms Problemen hier nicht mehr ab – nur erwähnt wollte ich das mal haben.