Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.
The Form module allows you to create Web forms that visitors can fill in. The module provides pre-configured form templates for easy creation of standard forms, such as a contact form, and allows customization. Multiple form elements that belong together, such as address fields, can be grouped visually. Form data can be validated using configurable validators. By default, data is sent via email in HTML or plain text or logged to the file system. Form data is processed using pluggable data processors which allow customization without changing the Magnolia core system. For information on working with components to create forms, see Form components.
Download the Form module from Magnolia Store or Nexus repository.
Form is a community module included in the Standard Templating Kit bundle, and typically already installed. Go to Magnolia Store > Installed modules in AdminCentral to check. To install the module individually, please see the general module installation instructions. In order to use this module, the STK needs to be installed.
See the general module uninstalling instructions and advice.
The Form module uses the Mail module to send form data in email. See Configure SMTP protocol to enable sending of mail.
Validators are used to ensure that form data is entered in correct format and length. For example, an email address should adhere to an established syntax where a local part is followed by the @ character and a domain: john.smith@example.com
. Validators are configured in /modules/form/config/validators/
. The validation is performed by a Java class referenced in the class
node.
The Form module provides the following validators out-of-the-box:
none
: No validation is performed. Any value entered into the field is accepted.empty
: No validation. Used for Honey pot field only.
email
: Value needs to be a valid email address. Validity is checked with regular expression ^\S+@\S+$
. This validator uses the ValidateExpression
class which evaluates a regular expression configured in the expression
property.number
: Value needs to be a number, specifically an integer. No decimals separated with period or comma or fractions are accepted. Validity is checked with regular expression [0-9]*
noHTML
: Value cannot any have HTML markup. This ensures that users can enter only plain text. Creating links and formatting text is prevented. Validity is checked with the custom NoHTMLValidator
class which checks for the presence of angle brackets (<
>
).password
: Validates that a password typed into the user profile update form matches the one typed into the confirmation field. Used to eliminate typos.username
: Verifies that the entered username does not exists in the system. The Java class for this validator is in the Public User Registration (PUR) module.Configured validators are displayed as options in a the Field dialog when fields are added to the form.
When field validation passes, the value is submitted.
When field validation fails, a message is displayed to the user identifying the problem field.
The easiest way to create a custom field validator is to use the ValidateExpression
class and write a regular expression.
For example, to validate a U.S. ZIP code:
/modules/form/config/validators
.zip
under validators
.zip
:class
: Set the value to info.magnolia.module.form.validators.ValidateExpression
.expression
: Set the value to ^\d{5}(-\d{4})?$
. This regular expression validates ZIP codes of type ZIP+4.Assign the validator to a field:
/demo-project/service/contact
.zip
from the Validation dropdown.Test the validation:
4321A
.The form tells you that the ZIP code was invalid and highlights the problematic field. This is the expected outcome.
To validate field values against an external source you need a custom Java class. Look at the API documentation:
Form processors are responsible for sending the submitted form data in email or storing it in the repository. Processors are configured in /modules/form/templates/components/form/formProcessors
and executed when the corresponding form is submitted.
The following configurable processors are provided out-of-the-box:
enabled
data node under the processor and set its value to true
.magnolia-form.log
file if the Track Mail checkbox is checked. By default, this processor is not enabled. This is the case even if the Track Mail checkbox is checked in form settings. To enable it, add an enabled
data node under the processor and set its value to true
. APIThe three example form processors above send the form data in email. If you need to store the data into a database or process it in another way, write your own form processor. See Storing form data in the Data module for an example.
Create a new form component definition for your custom processor. If you simply add the custom processor to the default component definition it will be executed for all forms.
See also these examples:
To log data sent in the contact form:
enabled
under /modules/form/templates/components/form/formProcessors/trackEmail
and set its value to true
.webapps/<webappName>/logs/magnolia-form.log
on the file system.For logging mail errors, see Mail > Error logging .
Multi-step forms were introduced in Magnolia 4.4, meaning that individual form pages and the first page of a multi-step from needed to be excluded from cache to prevent 'session expired' errors. 4.4.6+ Abstract FormModel sets the no-cache header automatically.
The Form module keeps the internal state on the server. It is kept in session using a unique ID for each user interaction and this makes it possible to have simultaneous form interactions in a single session, for example in multiple tabs. A unique ID is rendered within the page as a hidden input field. This is the reason the page needs to be excluded from caching; otherwise different users would be able to use the same ID that was used when the page went into the cache.
Pages can be excluded from the cache in the Cache module in /modules/cache/config/default/cachePolicy/voters/urls/excludes
. The screenshot below shows the exclusion of the first page of the multi-step form in demo-features
.
Form settings define the title and name of the form and where the collected information should be submitted. Settings are configured in the Form Settings dialog. You can access this dialog by clicking the Edit icon on the Form component toolbar.
Form tab
Field | Description |
---|---|
Title | Title displayed above the form. For example "Contact Us". |
Form name | Internal name that allows you to reference the form by name, for example from JavaScript. |
Text | Introductory text displayed below the form title. |
Marker for required fields | Character displayed next to required fields. Asterisk by default. |
Text for required symbol | Text that explains what the required marker means, displayed near the top of the form. For example "Required fields". |
Breadcrumb | When checked will display a breadcrumb after form title and text to navigate through steps of multistep forms. |
Submit settings tab
Field | Description |
---|---|
Error title | Title displayed when an error occurs. |
Success title | Title displayed when the form is submitted successfully, for example "Thank you!" |
Text | Text displayed when form is submitted successfully, for example "Your details have been submitted." |
Page displayed after submission | Select a page to display after submission. If no page is selected, the user stays on the current page and the success title and text are displayed instead. |
Track mail | Logs the information submitted in the form to |
Email tab
Field | Description |
---|---|
From | Email address displayed in the From field of the outgoing message. Typically you would ask the submitting user for their email address on the form and repeat it here with a Freemarker tag such as |
To | Email address the data is sent to. You can use form field names with Freemarker tags. |
Subject | Email subject line. You can use form field names with Freemarker tags such as |
Available fields for Freemarker syntax | Form field names that can be used in Freemarker tags. |
Type | Radio button to select the message type for the email body. |
text | Opens a text field to compose the email template. You can use form field names with Freemarker tags such as |
html | Opens a fckEdit field to compose the email template. You can use markup that will be escaped. |
Confirmation email tab
Field | Description |
---|---|
Send confirmation | Sends a confirmation mail to the submitting user. |
From | Email address displayed in the From field of the outgoing message. You might want to use a customer support address here in case the user has further questions or a no-reply address. You can use form field names with Freemarker tags. |
To | Email address the data is sent to. You can use form field names with Freemarker tags such as |
Subject | Email subject line such as "We have received your feedback". You can use form field names with Freemarker tags such as |
Available fields for Freemarker syntax | Form field names that can be used in Freemarker tags. |
Type | Radio button to select the message type. For code and text you can use form field names with Freemarker tags such as |
code | Opens an editCode field (includes syntax highlighting) to compose the email template. |
text | Opens a text field to compose the email template. |
page | A page in the site that the user is sent to after successful submission. |
The purpose of a field set is to group fields that logically belong together.
Before you can add any fields on the form you need to add at least one field set:
See Form module components for fields that you can add into a field set.