Bestätigungsmail TYPO3 Double-Opt-In Browserwerk
20 Mai 2016

TYPO3 form handler double-opt-in

As a Wiesbaden TYPO3 agency we are often faced with a wide variety of tasks. Sometimes it's the most banal things that worry a TYPO3 developer. The TYPO3 form handler is still state-of-the-art in terms of form management and data file export. In particular, if this involves larger amounts of data than on a private homepage and then the data must be further processed by other departments. Unfortunately, the shape handler has its peculiarities every now and then, so we want to capture a conspicuousness here in the blog.

Double opt-in forms for subscribing to newsletters such as the direct_mail extension is mandatory in Germany and is also supported by the TYPO3 extension form handler, however, note that for the registration form and the "confirmation" form that in the authCode is linked, each has its own form handler form must be created to ensure that the user is really confirmed after clicking on the link.

Below is a quick guide to explain what a double opt-in form might look like in the form handler.

UPDATE: Here's the instructions for Double-Opt-In for the current TYPO3 form extension.

  

After creating the folder structure for the two forms (form-double-opt-in and form-double-opt-in2 in our case), the form, like any other form handler form, is styled and populated with any validators. The first special feature of double-opt-in forms then starts among the "finishers". The form handler finisher "Finisher_DB" controls any TYPO3 table.

Here is the table tt_address, since these entries can also be used later for a mailing via the directmail extension. In this case, we have "mapped" the fields from the form to be able to personally address our newsletter recipients later. The line "pid = 267" specifies only the location of the address list data and does not matter for the functionality of the double opt-in form.
Our second finisher "Finisher_GenerateAuthCode" again points to the table tt_address and specifies an "authCodePage". This auth code page must contain the second part of the form, ie the validation of the e-mail address (form-double-opt-in2). To keep the URL of the auth code link nicely short, all unnecessary parameters should be excluded. The exclusion of parameters assumes that the forms have been configured the same (table, key).
The third finisher "Finisher_Mail" can then not only notify the admin about a new login and at the same time the user who completed the form. Please note that the marker "value_authCodeUrl" is still set.

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
}

}

}

The second form, which is integrated on the authCodePage, is done quickly, because here we need neither templates nor styles and in any case forward the user to a "success" or "error" page.
Only the preProcessors have to be configured. The variable "redirectPage" expects the "Success" page ID and the "errorRedirectPage" the corresponding error page. By specifying the parameters "uidField" and "table" we save in the URL these 2 parameters, which are otherwise appended automatically. The "hiddenField" is automatically set to "false" by the form handler and the double opt-in is almost done.

In the last step, we should still realurl or coolurl adapt to avoid ugly Auth code Urls. For this we configure a new postVarSets element, e.g. "Login" and assign this element the two parameters uid and authCode, of course with form prefix, from our form.

 

Back

Contact us

Office Wiesbaden

Borsigstraße 3
65205 Wiesbaden