Magnolia 6.1 reached end of life on March 31, 2021. This branch is no longer supported, see End-of-life policy.
This page describes how to create a new GDPR-compliant form as well as how to adapt an existing form (containing a field where users may enter personal data) to comply with GDPR requirements.
The examples on this page make use of the Privacy module and the Travel Demo.
In an ordinary form, the data entered in the input field is usually processed directly upon hitting the submit button on the form.
A GDPR-compliant form needs to follow a more complex procedure called double opt-in:
In the example below, we assume that we have a text input form field called
fullname that must be handled in compliance with GDPR.
In the Magnolia DX Core Travel Demo, the
contacts workspace is registered in the configuration of the Privacy module for demonstration purposes of dealing with personal data. This means the Visitors app interacts not only with the
visitors workspace but also with the
contacts workspace, which is otherwise primarily used by the Contacts app.
The record of consent for form-based data in the
visitors workspace is created on the public Magnolia instance, never on the author instance. This is also true for referenced content, for instance in the
You must synchronize the consent records stored if you use several public instances. The instances, or in our sample implementation at least the
contacts workspaces, must be clustered in order to share accounts between the different instances. Alternatively, implement observation-based synchronization to replicate visitor and contact data across instances.
In this section, you create a new GDPR-compliant form. You need the knowledge gained here in the second section where you already have a form and want to adapt it for GDPR.
The Magnolia Travel Demo bundle comes with a sample form component template called (GDPR) Store data form, which is provided by the
privacy-sample submodule and designed for the purposes of GDPR.
This component template is preconfigured to:
fullname(this becomes the value of the internal JCR
Configure the option in which the user chooses consent duration in the Expiration options field. Use the following format
<label> represents the label shown for the option.
<timeUnit> defines the time unit. Use
1 for year,
2 for month or
10 for hour.
<timeQuantifier> defines the actual length of consent for the time unit specified.
For example, if you want to allow the user to choose from consent durations of 24 hours, 72 hours and 1 month, you need enter the following in the field:
24 hours:10__24 72 hours:10__72 1 month:2__1
Since this step is done in the Configuration app, you need the
superuser role to access the app and change the configuration.
fullname field, added to the form's field set, must be database names registered in the system for GDPR-compliant data processing. This is done in the configuration of the Privacy module.
visitor-manager module configuration at
Add the newly added
fullname field name as a property (which is in fact arbitrary) and value under the
name/fieldNames node, which is already present in the configuration:
At this point, the newly created form is GDPR-compliant. The user is asked to give consent to process the data entered:
In this section, we assume that we already have a form with a text input field labeled Full Name, internally
fullname, and we want to adapt to comply with GDPR:
First you need to change the form's template to use one that is designed for GDPR. In this example, we use the template called (GDPR) Store data form again.
Select the form and change its template to (GDPR) Store data form:
In the next step, switch to the Opt-in Email tab and configure the parts of the opt-in email:
After saving the changes the form contains two field sets:
Now you have to make the Full Name field in the first field set a member of the other field set. With
superuser role you can do that in the JCR Browser app:
After this operation, the Full Name field is located next to the Email field:
fullname field, added to the form's field set, must be a database name registered in the system for GDPR-compliant data processing. Ask your system administrator to do this for you if don't have access to the Configuration app.
visitor-manager module configuration at
Make sure that the relocated field's
name is a property and value under the
node , which is already present in the configuration. If it isn't there yet, add it there. The relocated field is now also subject to the logic of the (GDPR) Store data form template and hence the GDPR requirements. When submitting the page, the user is asked to give consent for both text input fields in the form, Full Name and Email: