Ein Formular, bitte!

Michael Sebel

formeditor-featuredimage

Für die WordPress-Installationen unserer Kunden haben wir eine eigene Formular-Applikation erstellt. Einfach zu handhaben, aber flexibel in der Anwendung.

In unseren ersten Monaten haben wir uns mehrmals gefragt: Welche Lösung können wir unseren Kunden anbieten, damit sie einfach eigene Formulare erstellen können? Die Lösung sollte flexibel sein und für anspruchsvolle Lösungen taugen. Wir könnten dafür ein bestehendes Plugin einsetzen – würden damit aber Flexibilität verlieren. Wir haben uns deshalb entschieden, eine eigene Lösung zu entwickeln. In diesem Beitrag erklären wir, warum wir uns für den Eigenbau entschieden haben.

Gegen den Plugin-Wildwuchs

Wir kümmern uns um WordPress-Installationen von rund neunzig Kunden. Für die meisten Websites setzen wir unser eigenes Framework und ein geprüftes Set an Plugins ein. Für uns ist es sehr wichtig, bei allen Kunden die gleiche Software zu betreiben. So stellen wir sicher, dass wir in jedem Falle schnell reagieren oder weiterentwickeln können. In der Vergangenheit hatte ich gerade im Zusammenhang mit WordPress oft Installationen (von Agenturen umgesetzt) gesehen, in denen ein Wildwuchs an gekauften oder kostenlosen Plugins entstanden war. Hat man zehn, zwanzig oder mehr solcher Installationen, kann mir keiner sagen, dass die Support- und Test-Aufwände bei Updates oder bei der Entwicklung von Erweiterungen gering sind.

Unser Ziel war also, eine Lösung zum Erstellen von Formularen zu bieten. Aus meiner Sicht ein wichtiger strategischer Entscheid, da wir bei jedem Kunden die gleiche Software einsetzen wollen. Auch ist der Entscheid wichtig, weil Formulare praktisch auf jeder Webseite eingesetzt werden. Flexibel sollte die Lösung sein, um auch komplexe Anwendungen umzusetzen.

Der Plugin-Markt

Weshalb sind bekannte Plugins bei uns durchgefallen?

  • Contact Form 7: Marktführer mit weltweit den meisten Installationen. Jedoch für die meisten Menschen, die keine oder wenig Erfahrung mit Shortcodes und/oder HTML haben eher schwierig zu bedienen. Weiterhin kann man damit nur E-Mails generieren, aber z.B. keine Workflows starten und damit die Daten weiterverarbeiten. Ein Anwendungsfall, der bei uns fast an der Tagesordnung ist, zumindest, um die Daten in einer Tabelle zu speichern und später zu exportieren.
  • Gravity Forms: Gleich vorweg – Gravity Forms ist sein Geld wert. Das Plugin ist sehr flexibel und bietet Entwicklern verschiedene Möglichkeiten, die Funktionen zu erweitern. Damit haben wir auch schon die ein oder andere Individual-Lösung mit WooCommerce-Integration gemacht. Doch hier haben wir das Gegenteil von Contact Form 7: Ein Feldtest mit einigen freiwilligen Kunden hat gezeigt: zu schwierig.
  • QuForm: Hier dachten wir für einen Moment, den goldenen Mittelweg gefunden zu haben. Daten können in einer Tabelle gespeichert, oder via Filter weiter verarbeitet werden. Letzteres geht vielleicht auch mit Contact Form 7, soweit habe ich mich da nicht reingekniet. QuForm hatten wir ebenfalls bei ein paar freiwilligen Testern im Einsatz und dabei festgestellt: Die deutschen Übersetzungen sind jeweils nur halb korrekt (Strings in den PO Files stimmten zu gefühlt 50% nicht mit dem Code überein), die Software ist teilweise sehr langsam, lässt PHP-Prozesse hängen, und bei einem Update wurden gar alle Formulare gelöscht. Ach. Dann lassen wir das halt auch lieber sein.

Formular Editor Marke Eigenbau

Mit hohen Ansprüchen etwas eigenes bauen ist auch nicht immer einfach: Es sollte alles können. Aber jede Zeile Code zu viel rächt sich in der Wartung und Weiterentwicklung. In unserem Framework haben wir – das behaupte ich jetzt einfach mal – im Grunde eine gute Architektur, welche auch PHP7-kompatibel ist (99.9% OOP, Namespace, Unit-Tests, ausser im Plugin File, wo uns WordPress zu ein bisschen prozeduralem Code zwingt).

Für eigens gebaute Plugins mit spezifischer Funktion wäge ich immer ab: Machen wir eigene Datenbank-Tabellen, einen Post Type mit Meta-Feldern, oder doch was anderes? Hier haben wir uns am Ende für eine Shortcode-in-Shortcode-Architektur entschieden. Damit ist ein Formular technisch gesehen ein Post, dessen Content eine Sammlung an verschachtelten Shortcodes ist. Natürlich, Shortcodes sind nicht das schönste Konstrukt, aber sie lassen sich einfach in ein JSON und zurück umwandeln, was uns erlaubt dafür ein eigenes Interface mit JavaScript umzusetzen.

In unserer Anfangsphase hatten wir also nur die Shortcodes. Wir haben die Konfiguration neuer Formulare für unsere (geduldigen) Kunden im ersten Schritt auf unsere Kappe genommen. In einer zweiten Phase haben wir die «Benutzeroberfläche» dazu gebaut. Diese ersetzt den «Post Content»-Teil im WordPress-Backend mit einem eigenen UI. Ihr seht: Vom originalen UI ist nur noch der Titel sichtbar. Das ganze WordPress Admin Menu und drumherum ist vorhanden, habe ich im Screenshot aber abgeschnitten.

formeditor-formular

Formulare und Aktionen

Nun folgen wir einem simplen Prinzip: Man klickt sich im ersten Register die Formular-Felder zusammen. Danach entscheidet man, was mit den eingegebenen Daten geschehen soll. Hierbei ist jedes Feld und jede Aktion ein eigener (generischer) Shortcode, was uns erlaubt, individuelle oder komplexe Formularfelder und Aktionen für eine Kunden-Umsetzung zu definieren. Was muss man sich unter einer Aktion nun vorstellen?

formeditor-aktionen

Zu den üblichen Aktionen gehören: Eine (oder mehrere) E-Mail(s) verschicken, Daten in einer Tabelle sammeln, Anmeldung direkt an einer Newsletter API (z.B. MailChimp oder Emarsys) senden. Technisch interessant ist, dass eine Aktion auch auf das Verhalten des Formulars Einfluss nehmen kann. Es kann z.B. seine Basis-Klasse-Methoden überschreiben um z.B. wie bei der Aktion «Zeitgesteuert Schliessen», das Formular auszublenden und einen Hinweis-Text darzustellen. Interessant ist die Aktion «Formular-Daten speichern». Sie erlaubt es, die gesendeten Formular-Daten in einer Tabelle zu sammeln und später zu exportieren. Für Event-Anmeldungen kann man die Aktion so konfigurieren, dass Sie das Formular nach 40 Anmeldungen schliesst.

Einstellungen dürfen nicht fehlen

formeditor-aktionenAls letztes muss man ein paar Entscheidungen treffen: Was geschieht, wenn das Formular abgeschickt wird? Hier haben wir ein bisschen bei Contact Form 7 und ein bisschen bei Gravity Forms abgeschaut. Weiterleitung auf eine Folgeseite, aber auch eine direkte Rückmeldung oberhalb des Formulars sind möglich.

Fazit

In die Benutzer-Oberfläche haben wir einige Zeit investiert. Die Rückmeldungen waren dafür durchweg positiv, insbesondere von den freiwilligen Testern, denen wir erst Quform und Gravity Forms serviert hatten. Für unsere Kunden wollen wir so flexibel wie möglich sein. Die Eigenentwicklung ist auch deshalb für uns die richtige Lösung, weil sie nicht nur durch die Shortcodes sehr erweiterbar ist, sondern weil wir das Verhalten der Software auch im Kern ändern können. Bei komplexen Umsetzungen ist es meist nicht möglich, auf das grundlegende Verhalten eines Plugins Einfluss zu nehmen. Man ist an der Stelle leider immer nur so flexibel wie die Software, die man einsetzt.

Übrigens: Die Entwicklung war auch nicht so aufwändig, wie man meinen könnte: Viele Funktionen zur String-Umwandlung, Validierung, UI-Funktionen, aber auch den Shortcode->JSON Konverter hatten wir schon vorher in unserem WordPress-Framework drin. Wir wussten bei unserer Entscheidung also, dass wir sehr viele Werkzeuge bereits an Bord haben.