Initial Value & Persistence

If you have experience of working with Concrete CMS edit dialogues and dashboard pages, you will likely have noticed that the data you entered is often persisted when a form is refreshed following submission or after an error is shown.

Form Reform takes this further. Most form block edit dialogues provide an Initial Value tab. The main input here is a list of checkboxes for persistence. A form input can have an Initial Value that rather than just being sticky with the immediate page or dialogue request, can be persisted over a much wider scope.

This can be used to help maintain form data across states when an input is hidden, or to do the opposite and ensure a field is not maintained when you don't want it.


The basic level of persistence Default is identical to what you will have seen in Concrete CMS block edit and dashboard dialogues. Our extended levels of initial value provide persistence from previously submitted and saved forms.

Persistence in detail

Input Persistence

Beyond the default level of persistence, the behaviour can be modified to be weaker:

  • Default, persist value while entering form
  • Persist value only after and error or warning - hence after a successful submission or between states of a multi-state form, the input would revert to one of the above.
  • No persistence - the input always reverts to one of the above.

Or it can be modified to persist or pre-fill an input from a wider scope:

  • From the most recent submission of this form name on this page
  • From the most recent submission of any form on this page
  • From the most recent submission of any form with the same name, on any page, site-wide
  • From the most recent submission of any form on any page, site-wide
  • From this form name on this page
  • From any form on this page
  • From any form with the same name, on any page, site-wide
  • From any form on any page, site-wide

These options fill and persist the form value according to previous submissions of the form or similarly named input fields in progressively wider scope. Sources are scoped by input name, then by page ID and form name.

For example. If you have many forms requiring a user to enter their name and email address, setting a wide scope for the persistence can be used to save them from needing to re-enter the same data across each different form.

On the other hand, for a password or an acceptance of terms and conditions input, you may want absolutely no persistence.

Persistence Sources

When data is persisted from a previous submission, Form Reform searches out through all the available storage mechanisms, not just where the current form handler pipeline saves data. 

The section Persistence Sources can be used to restrict what gets searched for persisting data from previous submissions. If no sources are selected, all are searched.

Searching for a previously saved value is made is in a priority order:

  1. Session store - because it is secure for the user and is fast to search or eliminate
  2. Cookie store - because it is specific to a user and is also fast to search or delaminate, but could also be hacked by a user.
  3. Database - this is also secure because it will be tied to a session or Concrete CMS user ID, but is not as fast as data already in the session or a cookie.
  4. From a user's Textarea attribute. (requires Form Reform Attributes, Express and Users)

Working through the above in sequence, the first matching item found will be used to fill the initial value of the input field. Each of the above can be individually enabled for each form control.

The underlaying mechanism supports further sources of persisted data, such as from a user text attribute provided by Form Reform Save to Attributes.

Starting Value

This starting value is not validated, it is up to you to ensure what you configure here is valid for the input!

Lower down on the same tab is a section for Starting Value. In general, you don't need to be concerned with providing a starting value. Persistence can be configured to automatically insert a visitor specific starting value based on their previous form submissions.

A starting value is an optional text input in the Initial Value tab of a block edit dialogue. Any value entered here will be overridden by the persistence set above.

Any {{place_holders}} in the starting value will be evaluated and filled.

For example, suppose you have a form with an email input field. A staring value of {{user:email|}} will pre-fill that form field with the email address of a logged in user. Note the "|" which sets a default of nothing, so when no user is logged in the starting value of the email field remains empty.

Not all {{place_holders}} are available when setting a starting value. For example {{form_input_name}} placeholders are only available within the form submit pipeline.

For text inputs this is easy. For things like select inputs, radiosets and checkboxes, you should probably use the Selection or Choice mechanism unless you need to derive the input from a {{place_holder}}.  

Selection or Choices

In any form input block that involves configuring a selection of values, such as a Checkbox, a Checkbox List, a Radioset, a Select input and any of the Continent / Country / State inputs, the initial selection or initial choice can be set when configuring the selection or choices.

For Continent / Country / State inputs this could also be set by geolocation of the browser IP address.

This initial value is used if none of the other mechanisms apply.

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.

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

List and display form submissions from Form Reform.

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.


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. The Table Picker Input is preconfigured to connect to Universal Content Puller table display widgets. Advanced settings allow the Table Picker Input to be configured to pick data from other HTML tables.

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.