Double-Opt-In Form Browserwerk
15 Januar 2018

Form Framework Double-Opt-In TYPO3 v8

Die aktuelle TYPO3 Version 8 bringt das umstrittene neue „Forms“ Framework mit. Während die Pflege und das Anlegen von Formularen und Formularfeldern nun auch für Redakteure über das Backend möglich ist, sind gewisse Features leider noch nicht Teil des Form-Frameworks.

EXT:Form Double-Opt-In

Wir wollen uns heute mit der Erweiterung um einen Double-Opt-In kümmern.
Dazu benötigen wir eine eigene Extension, in diesem Zusammenhang möchten wir auch noch auf einige Best-Practices im Zusammenhang mit der Erweiterung des EXT: Form Frameworks verweisen.

Nachfolgend die Agenda des folgenden How-To’s:

  • Funktionsprinzip Double-Opt-In
  • Erweiterungen im Form Framework
  • Eigene Finisher
  • Hooks
  • Best Practices
  • Fazit

Funktionsprinzip:

Beim Double-Opt-In Anmeldeverfahren muss der Empfänger des Newsletters den Empfang des Newsletters bestätigen. Dies Dient dem Schutz vor ungewollten Emails.

Nehmen wir als Beispiel eine simple Newsletter-Anmeldung.

Füllt der User die Anmeldung aus, erhält er im Anschluss eine Email mit einem Bestätigungslink.
Erst wenn dieser Link aufgerufen wurde ist die Anmeldung abgeschlossen und der User wird in den Verteiler aufgenommen.

Erweiterungen im Form Framework:

Leider ist das Erweitern des neuen EXT:Form Frameworks nicht so trivial wie wir es uns anfangs vorstellten, dies ist hauptsächlich der Konfiguration über yaml Dateien zuzuschreiben. Hierzu empfiehlt es sich einen Blick in die Dokumentation von Form zu werfen:

https://docs.typo3.org/typo3cms/extensions/form/

Doch wir wollen in diesem Tutorial ganz von vorne beginnen.
Es fängt alles schon vor dem Erstellen des ersten Formulares an.

Um überhaupt ansatzweise erweiterte Konfigurationen vornehmen zu können müssen wir TYPO3 via TypoScript anweisen unsere CustomFormSetup.yaml zu laden, dies erfolgt über folgendes TypoScript Snippet:

Die dazugehörige CustomFormSetup.yaml erstellen wir ebenso, und füllen diese mit folgendem Inhalt:

Nachfolgend die wichtigsten Optionen erklärt:

  • allowedExtensionPaths: Der/Die Verzeichnis/e in denen die Forms abgelegt oder geladen werden können
  • allowSavetoExtensionPaths: Erlaubt das Speichern in diesen Pfad via den Form Editor

Des Weiteren können wir sogennante Prototypes definieren.

Den Prototypes können wir anschließend eigene Templates und in unserem Fall auch eigene Finisher zuweisen.

Haben wir die Dateien angelegt und das TypoScript eingebunden müsste uns nun beim Erstellen eines neuen Formulares die Option „Form Storage“ zur Verfügung stehen.

In unserem Fall soll uns ein Formular mit einem „E-Mail“ Feld reichen.

Nach dem Anlegen des Formular erscheint auch in unserem definiertem Pfad die double-Opt-In.form.yaml

Als erstes wollen wir das Attribut prototypeName von ‚standard‘ zu unserem vorher definierten prototype ‚contactform‘ ändern.

Nun greift also für unser simples Kontaktformular die in der CustomFormSetup.yaml definierte Konfiguration.

Für das weitere Vorgehen greifen wir auf die double-Opt-In.form.yaml zu. Das Form Framework bringt eine Vielzahl nützlicher Finisher mit sich, doch nicht jeder Finisher lässt sich über das Backend konfigurieren. Dies gilt auch für den SaveToDatabase Finisher den wir für einen Double-Opt-In sogar zwei mal brauchen werden.

Davor erstellen wir aber noch ein verstecktes „uniquehash“ Feld welches wir später via Hook befüllen werden, sowie die Felder „confirmurl“ und „verifypid“. Wozu das sehen wir später. Dazu passen wir auch noch den identifier des E-Mail Feldes an:

Die Konfiguration des Finishers ist leicht verständlich und geht schnell von der Hand.

Wir können nun den SaveToDatabase Finisher konfigurieren:

Natürlich muss die Tabelle tx_form_leads noch erstellt werden, dies geschieht bekanntlich über die ext_tables.sql

In der ext_localconf registrieren wir folgende Hooks:

Die Hooks schauen wie folgt aus:

Schauen wir uns die Klasse setBaseUrl an wird uns klar warum wir die Felder confirmurl und verifypidbrauchen.

Der Integrator/ Editor kann in „verifypid“ die ID der Seite eintragen auf der der User validiert wird.
Wir erstellen anschließend via typoLink eine URL, diese wird dem User in der Email zum verifizieren mitgegeben.

Füllen wir nun unser Form aus, erreichen wir schonmal dass wir einen Eintrag mit einer ID, E-Mail einem Hash und enabled = 0 in die Datenbank bekommen.

Selbstverständlich braucht der User noch eine Email mit der er seine Anmeldung bestätigen kann.

In der angegebenen HTML Datei können wir dann unser E-Mail Template erstellen. Über {form.formstate.formValues} sind wir in der Lage auf die Felder im Form zuzugreifen.

Ein einfaches Template könnte wie folgt aussehen:

Damit das funktioniert müssen wir aber noch eine Seite anlegen auf welcher der Hash validiert wird.

In diesem Fall hat diese Seite die PID 6, also tragen wir diese in das Feld „verfiypid“ im Form ein:

Füllen wir das Formular aus erhalten wir auch schon folgende Email:

Wir haben nun also einen Datenbankeintrag, eine Email und einen Link welcher uns schon auf die richtige Seite führt.

Auf dieser Seite ist allerdings noch nichts zu sehen, und es gibt auch noch keine Art der Validierung.

Bekanntlich führen ja viele Wege nach Rom, und gerade für den nächsten Schritt gibt es eine Vielzahl von Möglichkeiten. Ich werde hier eine Möglichkeit präsentieren welche wie ich finde eine saubere und einfache Lösung darstellt den Hash zu validieren und den Eintrag in der Datenbank zu aktualisieren.

Wir werden ein weiteres Formular auf der Validierungsseite erstellen welches beim Abschicken in der Datenbank den übermittelten Hash sucht und den dazugehörigen Eintrag „enabled“ auf 1 setzt.

Um das Tutorial etwas kompakt zu halten gibt es hier meine komplette Form Definition des Bestätigungsformulars:

Wir brauchen aber einen weiteren Hook damit „gethash“ auch gefüllt wird.
Dieser wird wie gewohnt in der ext_localconf registriert:

Der dazugehörige Hook:

Der Hook sucht nach der Post Variable uniquehash, setzt diese in das Feld ‚gethash‘ und führt anschließend ein Autosubmit Script aus.
Die eigentliche Magie geschieht nun im Finisher des Validierungsformulars:

Als Abschluss empfehle ich noch den Redirect Finisher auf eine Dankeseite zu legen, so hat der User als Abschluss ein Feedback, dass alles geklappt hat.
Und ein Blick in die Datenbank bestätigt uns auch dass alles funktioniert hat:

Zurück
get in touch

Contact Us Now

Office Wiesbaden

Borsigstraße 3
65205 Wiesbaden

Rufen Sie uns an:

Telefon: +49 611 34 11 95 72