TYPO3 Formhandler Double-Opt-In

Als Wiesbadener TYPO3-Agentur stehen wir oftmals vor den unterschiedlichsten Aufgaben. Manchmal sind es die banalsten Dinge, die einen TYPO3-Entwickler Sorgen bereiten. Der TYPO3 Formhandler ist noch State-of-the-Art in Sachen Formularmanagement und Export der Datensätze. Insbesondere, wenn es sich hierbei um größere Datenmengen als auf einer privaten Homepage handelt und die Daten anschließend von anderen Abteilungen weiterverarbeitet werden müssen. Leider hat aber auch der Formhandler immer mal wieder seine Eigenarten, sodass wir eine Auffälligkeit hier im Blog festhalten möchten.

Double-Opt-In-Formulare zur Anmeldung bei Newslettern wie bspw. der direct_mail-Extension ist in Deutschland Pflicht und wird von der TYPO3 Extension Formhandler auch unterstützt, jedoch muss man beachten, dass für das Anmeldeformular und das “Bestätigungs”-Formular, dass in dem authCode verlinkt wird, jeweils ein eigenes Formhandler-Formular erstellt werden muss, um sicherzustellen, dass der Benutzer auch wirklich bestätigt ist, nachdem er auf den Link geklickt hat.

Nachfolgend erklären wir in einer kurzen Anleitung, wie so ein Double-Opt-In-Formular im Formhandler aussehen könnte.

UPDATE: Hier geht´s zur Anleitung für Double-Opt-In für die aktuelle TYPO3 Form-Extension.

Nach dem Anlegen der Ordnerstruktur für die beiden Formulare (form-double-opt-in und form-double-opt-in2 in unserem Falle) wird das Formular, wie jedes andere Formhandler-Formular, konfiguriert gestylt und mit beliebigen Validatoren bestückt. Unter den “Finishers” startet dann die erste Besonderheit bei double-opt-in Formularen. Der Formhandler-Finisher “Finisher_DB” steuert eine beliebige TYPO3-Tabelle an.

Hier bietet sich die Tabelle tt_address an, da diese Einträge auch später für ein Mailing über die Extension directmail genutzt werden können. In diesem Fall haben wir die Felder aus dem Formular “gemappt”, um unsere Newsletter-Empfänger später persönlich ansprechen zu können. Die Zeile “pid=267” gibt nur den Speicherort der Adress-Listen-Daten an und ist für die Funktionalität des Double-Opt-In-Formulars egal.
Unser zweiter Finisher “Finisher_GenerateAuthCode” zeigt wiederrum auf die Tabelle tt_address und gibt eine “authCodePage” an. Diese Auth-Code-Page muss den zweiten Teil des Formulars beinhalten, also die Validierung der E-Mail-Adresse (form-double-opt-in2). Damit die URL des Auth-Code-Links schön kurz bleibt, sollten alle unnötigen Parameter ausgeschlossen werden. Das ausschließen von Parametern setzt voraus, dass die Formulare, aber entsprechend gleich konfiguriert wurden (table,key).
Der dritte Finisher “Finisher_Mail” kann dann zum einen den Admin über eine neue Anmeldung benachrichtigen und gleichzeitig den Benutzer, der das Formular ausgefüllt hat. Hier ist zu beachten, dass noch der Marker “value_authCodeUrl” gesetzt wird.

plugin.Tx_Formhandler.settings.predef.bw-double-opt-in-form{
debug=0
# This is the title of the predefined form shown in the dropdown box in the plugin options.
name = DoubleOptIn-Formular-Registrierung

# All form fields are prefixed with this values (e.g. contact[name])
formValuesPrefix = subscription

langFile.1 = TEXT
langFile.1.value = {$bw-double-opt-in-form.rootPath}/lang/lang.xml

templateFile = TEXT
templateFile.value = {$bw-double-opt-in-form.rootPath}/html/multistep.html

# The master template is a file containing the markup for specific field types or other sub
# templates (e.g. for emails). You can use these predefined markups in your HTML template for a specific form.
masterTemplateFile = TEXT
masterTemplateFile.value = {$bw-double-opt-in-form.rootPath}/html/mastertemplate.html

# CSS files
cssFile {
10 = TEXT
10.value = {$bw-double-opt-in-form.rootPath}/skin/css/bootstrap.min.css
10.if.isTrue = {$bw-double-opt-in-form.includeBootstrapCSS}
20 = TEXT
20.value = {$bw-double-opt-in-form.rootPath}/skin/css/special.css
}

# In case an error occurred, all markers ###is_error_[fieldname]### are filled with the configured value of
# the setting “default”.
isErrorMarker {
default = has-error
}

# These wraps define how an error messages looks like. The message itself is set in the lang file.
singleErrorTemplate {
totalWrap =

|

}

# This block defines the error checks performed when the user hits submit.
1.validators {
1.class = Validator_Default
1.config.fieldConf {
anrede.errorCheck.1 = required
nachname.errorCheck.1 = required
vorname.errorCheck.1 = required
email.errorCheck.1 = required
email.errorCheck.2 = email
telefon.errorCheck.1 = required
uwg.errorCheck.1 = required
}
}

1 {
if {
1.conditions.OR1.AND1 = uwgemail=1
1.isTrue.1.validators.1.config.fieldConf.uwg.errorCheck.1=
2.conditions.OR1.AND1 = uwgmobil=1
2.isTrue.1.validators.1.config.fieldConf.uwg.errorCheck.1=
3.conditions.OR1.AND1 = uwgtelefon=1
3.isTrue.1.validators.1.config.fieldConf.uwg.errorCheck.1=
}
}

# ajax {
# class = AjaxHandler_JQuery
# config {
# ajaxSubmit = 0
# submitButtonSelector = .Tx-Formhandler BUTTON[type=\’submit\’] # }
# }

#PreProcessors
preProcessors {
5.class = PreProcessor_LoadGetPost

}

# Finishers are called after the form was submitted successfully (without errors).
finishers {
1.class = Finisher_DB
1.config {
table = tt_address
key = uid
fields {
gender.mapping = anrede
email.mapping = email
first_name.mapping = vorname
last_name.mapping = nachname
hidden.ifIsEmpty = 1
pid=267
}

}
2.class = Finisher_GenerateAuthCode
2.config {
table = tt_address
authCodePage = 269
#selectFields = uid,email
excludeParams = table,uidField
}

# Finisher_Mail sends emails to an admin and/or the user.
3.class = Finisher_Mail
3.config {
checkBinaryCrLf = message
admin {
templateFile = TEXT
templateFile.value = {$bw-double-opt-in-form.rootPath}/html/email-admin.html
sender_email = {$bw-double-opt-in-form.email.admin.sender_email}
to_email = {$bw-double-opt-in-form.email.admin.to_email}
subject = TEXT
subject.data = LLL:{$bw-double-opt-in-form.rootPath}/lang/lang.xml:email_admin_subject
}
user {
templateFile = TEXT
templateFile.value = {$bw-double-opt-in-form.rootPath}/html/email-user.html
}
}

# Finisher_Redirect will redirect the user to another page after the form was submitted successfully.
4.class = Finisher_SubmittedOK
4.config {
templateFile = TEXT
templateFile.value = {$bw-double-opt-in-form.rootPath}/html/multistep.html
returns = 1
}

}

}

Das zweite Form, das auf der authCodePage eingebunden wird ist schnell erledigt, da wir hier weder Templates noch Styles benötigen und den Benutzer auf jedenfall auf eine “Success”- oder “Error”-Page weiterleiten.
Lediglich die preProcessors müssen konfiguriert werden. Die Variable “redirectPage” erwartet die “Success”-Page-ID und die “errorRedirectPage” die entsprechende Fehlerseite. Durch die Angabe der Parameter “uidField” und “table” sparen wir uns in der URL diese 2 Parameter, die andernfalls automatisch angehängt werden. Das “hiddenField” wird vom Formhandler dann automatisch auf “false” gesetzt und der Double-Opt-In ist fast fertig.

Im letzten Schritt sollten wir noch realurl bzw. coolurl anpassen, um unschöne Auth-Code-Urls zu vermeiden. Dazu konfigurieren wir ein neues postVarSets-Element z.B. “anmeldung” und weisen diesem Element die beiden Parameter uid und authCode, natürlich mit Form-Prefix, von unserem Formular zu.