Example - Signing Forms

Jump past navigation
If you need a legally binding signature, consider using a cryptographic signing service.

With a Signature input block the visitor can draw a signature with their mouse or touch device. This is uploaded with the form data as a base64 encoded image.

Whilst the the Initial Value can be set to persist a previously entered signature, for security we recommend a signature is not persisted beyond the current form submission. When persisted a signature may not be edited, but may be cleared and re-entered if a clear button is enabled.

To use an entered signature in an email or message, insert an html image <img src="{{form:my_signature_field}}">.

Here we have added a Signature block to our simple contact form.

Feel free to submit the form as often as you want. The form is saved to your session, but the data is not saved or logged anywhere else. All it does is validate the inputs and return a success or error message. The session data facilitates persistence of some inputs, so you only need to enter your name and email once. You can also see your most recent form submission presented using Form Reform Display.

Draw your signature here

Submit

The submit processing is the same as for our Example - AJAX Forms.

We have made a couple of small modifications to the processing pipeline.

Message

To display the signature, in the message handler we add an <img> element with a source of {{form:signature}}. A trick is to add any image from your file manager, then in the <html> view replace the content of the src="path/to/image" with src="{{form:signature}}".

<img alt="Your signature" src="{{form:signature}}" style="max-width:66%;height:auto" />

Save

In the save handler, we redact the signature field, so it is not saved into your session. Redacting and not persisting the signature field is generally a good security practice. The signature can be embedded in a notification email in the same way we have embedded into the message above. This will provide confirmation without keeping an actual signature on the web server.

Handler pipeline for: Submit

Handlers in the pipeline will be applied in sequence when a form is submitted.

Spam Detect

Configure multiple spam detection strategies. Each spam detection strategy can be separately enabled to either fail silently or to provide an error message that can then be managed through the On Error handlder.
Edit heading note
Check for spam using the core Anti-Spam service.
Check using the core Banned Words service. Use this with caution on multilingual sites. A banned word in one language could be perfectly acceptable in another language.
Require the client browser to provide an IP address. This check is strongly recommended if checking the core IP Deny list is enabled.
Check using the core IP Deny list. The IP Deny service maintains a dynamic blacklist and whitelist of IP addresses. If an IP address is not in the whitelist it is checked against the blacklist.
Check if the submission contains URLs. URL inputs are exempt from this check.
Check if the submission contains <html> tags. Rich Text inputs are exempt from this check.
Check if the submission contains <script> tags. This should normally be enabled.
Some blocks such as the Honeypot and Captcha also detect spam. Their detection response can be managed by the normal form validation error handling , or by direct integration with this Spam Detect handler.

Validate Input Fields

Validate form input fields. Validate the form input fields provided by each block in the form. Provides a list of errors as {{errors:list}} if validation fails.
Edit heading note
 
An input which is empty in the submitted form data and does not pass validation rules will normally fail validation, even if it is not required. A skip empty option allows empty inputs which are not required inputs to not be validated.
 
 
An input which is completely missing from the submitted form data will normally fail validation, even if it is not required. skip missing options allow inputs completely missing from the submitted form data to not be validated. This can be useful where inputs are hidden/disabled by Visibility Rules.
 
A required input which is in an empty repeatable group, so completely missing from the submitted form data, will normally fail validation. A skip empty group option allows inputs completely missing from the submitted form data which are in a repeatable group to not be validated. This can be useful where repeatable groups have no required minimum.
Where skipping automated validation, consider adding conditional form handling to provide your own application specific validation. For example, using Condition If > ... Set Error > ... Condition End or Set Error Conditional handlers followed by an On Success handler.

On Success

Denotes success processing (no errors). On Error and On Success should always be used in together to denote processing for errors and processing for no errors. Either may be used first.
Edit heading note

Save to Session

Save form submission to session data. Data extracted from form fields is saved to the visitor/user session data. This is transient data that lasts for the duration of the Concrete CMS session. The primary reason for saving to a session is to enable values to be recovered and inserted into the same or other forms.
Edit heading note
A form can be saved to the name configured by the form blocks or to a different (alias) name. This can be convenient when you take advantage of the default name "form_reform" when adding a single form to a page, but would like a more specific name for the saved form data.
A form submission may optionally update an existing response by matching one or more criteria of the response.
When a user is completing multiple forms, to keep the data from growing, old submissions may be cleared.
Name
Form items may optionally be redacted from the data that is saved. For example, to remove a password from the saved data. Redacted items are listed by input_name.
Where suggestions are offered, these are only suggestions. Other input names/handles may exist in the form and may be entered.

Comment

Insert a comment. Make a comment or note within the pipeline. This handler has no effect on pipeline processing.
Edit heading note 
The condition below is purely for demonstrating UTM tags. If you don't use UTM, you can ignore this condition.

Condition If

Check a condition and either proceed or move forwards to an alternative. The handlers ConditionIf, ConditionElseIf, ConditionElse and ConditionEnd manage a single level of conditional processing in form handling.
Edit heading note
     
     
     
     

Message

Create a form response message to be displayed to the user. Build boilerplate for a response message, fill the boilerplate with form and site parameters and select a level to emphasize the message display. All text fields can use {{place_holders}} to be filled with system or entered form values.
Edit heading note
The level of a message will also affect the Hide/Do-not-render state of subsequent form controls
   

Condition End

Denotes end of condition processing. The handlers ConditionIf, ConditionElseIf, ConditionElse and ConditionEnd manage a single level of conditional processing in form handling.
Edit heading note

Message

Create a form response message to be displayed to the user. Build boilerplate for a response message, fill the boilerplate with form and site parameters and select a level to emphasize the message display. All text fields can use {{place_holders}} to be filled with system or entered form values.
Edit heading note
The level of a message will also affect the Hide/Do-not-render state of subsequent form controls
   

On Error

Denotes error processing. On Error and On Success should always be used in together to denote processing for errors and processing for no errors. Either may be used first.
Edit heading note

Message

Create a form response message to be displayed to the user. Build boilerplate for a response message, fill the boilerplate with form and site parameters and select a level to emphasize the message display. All text fields can use {{place_holders}} to be filled with system or entered form values.
Edit heading note
The level of a message will also affect the Hide/Do-not-render state of subsequent form controls
   

In Edit Mode

In edit mode, the blocks for the form are extended from those in Example - AJAX Forms. The only changes necessary for this form is to add and configure a Signature input block.

Form Reform blocks used

Source Page / Stack Form Name Block Type Input Name
Example - Signing Forms form_reform Email Input email
Example - Signing Forms form_reform Text Input first_name
Example - Signing Forms form_reform Text Input last_name
Example - Signing Forms form_reform Select Input pronoun
Example - Signing Forms form_reform Message Display
Example - Signing Forms form_reform Spinner
Example - Signing Forms form_reform Radioset Input subject
Example - Signing Forms form_reform Text Area Input message
Example - Signing Forms form_reform Signature Input signature
Example - Signing Forms form_reform Honeypot more
Example - Signing Forms form_reform Captcha
Example - Signing Forms form_reform Submit Button submit
Developer Analysis

Additional Pages

Reform the way you add new input controls

If you need a specialized template or a custom input element, you can design new templates  or new block types for form elements as you would any block type.

Blocks are easy for third party addition or extension. Block templates and are the first thing any Concrete CMS developer learns to code. They are one of the easiest things to code. The underlying mechanisms are well established and reliable.

Reform what you can do with form data

Form handlers are built about the same extensible plugin system as many of my other addons (Universal Content Puller, Omni Gallery, Extreme Clean ...).

The whole system is aimed at easy extension within Form Reform, by third party addons, by agencies and by site building developers.

Handlers can be easily added to do whatever you want with the form data.

Reform where you can save form data

Saving form data with Form Reform is simply a handler in the processing pipeline. You can save to multiple locations or just one location.

If you need to save data elsewhere, such as to a dedicated table, a table provided through another addon, to another database, send it to an API, forward it to another server, or anywhere you can imagine, you can adapt or develop a form handler to do so.

The complexity of the code depends on where you are saving or sending the data, but wrapping that into a form handler plugin for Form Reform is straight forward.

The Form Reform handler plugin system is designed for easy extension.

Why not Express forms?

Express is the built in object data system built in to Concrete CMS. Form Reform is way more powerful for forms. Express supports basic object relationships, but is not robust.

Form Reform

Reform the way forms are built. Build a form out of blocks. Take control of how form submissions are processed and how the submitted data is stored. Easy to extend. Easy to reconfigure. Tangible data. Easy to add your own integrations.

Form Reform Display

Provides blocks and dashboard utilities to List, display, summarize, generate reports and analyze form submissions from Form Reform. Additionally supports integration with Universal Content Puller.

Form Reform UTM

Not just Form Reform and not just UTM! Capture and hold incoming UTM (or other) tags and make the tag values available to Form Reform and/or Conditional Redirect as {{place_holders}}. You don't need Form Reform to use this.

Form Reform Dynamics

Form handlers for querying Microsoft Dynamics, forwarding and updating form data to Microsoft Dynamics.

Snapshot

A suite of advanced image capture and upload tools. Enhanced drag and drop file uploading. Make screengrabs from within Concrete CMS. Capture images directly from device webcams. Edit images before uploading.

Form Reform Attributes, Express and Users

Save submitted forms to Express objects and user attributes. Add and remove users from groups.

Form Reform Image Picker

Form Reform Image Picker provides an image picking input block for Form Reform. The Image Picker Input is preconfigured to connect to most Omni Gallery gallery and slider display widgets, the core gallery block, and thumbnail showing templates for the core page list block. Advanced settings allow the Image Picker Input to be configured to pick images from other galleries and sliders.

Form Reform Data Picker

Form Reform Data Picker provides data picking input blocks for Form Reform. Create pickers and selectors from tables or JSON data sources including HTML tables, Calendars, Page Lists, Universal Content Puller and previously submitted form results.

Form Reform Macros

Extends Form Reform with form handler macros. Provides a new dashboard page at System & Settings > Form Reform > Form Reform Macros to manage macros, and form handlers to run macros.

Form Reform Developer

A growing suite of resources to assist those developing blocks, handlers and more complex forms for Form Reform.

Learn with a simple form

While you may have plans to implement some much more complex forms using Form Reform, we strongly recommend you start with a simple form such as our contact form example in order to review the basic principles of using Form Reform before you move onto anything bigger.

  1. Start by submitting the form at Getting Started - Your First Form a few times, even making some deliberate mistakes.
  2. Watch our Getting Started with Form Reform video to see how the form is built.
  3. Read through the rest of Getting Started - Your First Form for more details of how this form is built.
  4. Create a test page on your site to build your own version of Getting Started - Your First Form and experiment.
  5. Develop your test page with some of the concepts introduced by our further examples and experiment with some of the other form inputs.