Download the PHP package madj2k/t3-fe-register without Composer

fe_register

Features

• Registration-Process with Double-Opt-In
• Login for normal users
• Login as guest via link
• Self-sign-up to defined usergroups, including approval by admin
• Extensive Consent-Management for GDPR
• Encryption and anonymization of deleted records (GDPR)
• Automatic cleanup of deleted records (GDPR)
• Easy to integrate into your own extensions

Usage in your own extension

Opt-In

1. Generate Opt-In in your controller

For a registration with opt-in simple use the example-code below in your controller. Please ensure to always load FrontendUserRegistration via ObjectManager Explanation:

• setData: set the object you want to create after successful opt-in only. In case of a shop this may be an order
• setParentData: refers to the parent object of the opt-in-object. This is relevant for the documentation of the consents given by the user. In case of a shop this may be the product that is part of the order.
• setCategory: this way you can use your own SignalSlots in your extension that interact with the opt-in process
• setRequest: simply the current Request-option. This is relevant for the documentation of the consents given by the user.

If you want to be able to update the data of the frontendUser after the successful opt-in you can use the method setFrontendUserUpdate. This will update the frontendUser-object as soon as the user accepts the opt-in. This way you can be sure that changes to the frontendUser-object only happen if authorized.

2. Define MailService for Opt-In-Mail

No you need a MailService class with a defined action for Opt-Ins

3. Set Signal-Slot

Now we need a signal-slot that refers to the defined method for sending mails (ext_localconf.php)

4. Set Template for Opt-In-Mail

The opt-in-email may look like this:

5. Check Opt-In

To check the opt-in you can use the following example-code in your contoller:

6. Signal-Slot for extension specific action after opt-in

We need a second signal-slot in order to do whatever we need to do after the opt-in

7. Method for the specific action

Then we need to define the corresponding method:

Another use-cases

• You can also: Send a confirmation-email after the opt-in was successful (Using SIGNAL_AFTER_ALERT_CREATED-Signal-Slot) Delete all extension-specific data if the frontendUser is deleted (Using SIGNAL_AFTER_REGISTRATION_ENDED-Signal-Slot) ** ... do many other fancy stuff ;-)

Consent (Privacy, Terms, Marketing)

The extension has a ViewHelper and validators to obtain consent to privacy, terms of use and advanced marketing. In order to obtain the consents, only the corresponding ViewHelper must be used in the own extension. As soon as an opt-in is carried out, the corresponding consents are automatically documented and stored in the database. The consents granted are recorded accordingly with the associated data (IP address, browser, etc.). In addition, the consent to the terms of use and to marketing is stored in the FrontendUser, as these consents are usually page-wide and independent of the respective context of the consent.

1. In Fluid

The following code can be used to obtain the appropriate consent. It is important that the ViewHelper is used within a form and that the FormErrors are also returned via Fluid.

You can also use a dummy, if you have no real object to send

2. In the controller

Only the corresponding validators are included here. They always refer to the form object.

Or when using a dummy:

An opt-in procedure is usually not carried out for logged-in frontend users. If you still want to record the time of consent for a registration, you can achieve this with the following code:

When migrating from rkw_registration to fe_register

Execute the following MySQL-queries BEFORE install!

Execute the following MySQL-queries AFTER install!