If you make a mistake replicating a form between pages, you need to discover and fix that mistake at the first replication, not after the twentieth replication!
Form Reform's greatest strength is that you can design a form by arranging input blocks and mix these with any Concrete CMS blocks. This could also, if you are not careful, become the source of problems.
Here are some tips for managing the rollout and replication of forms in a way that is easy to set up and easy to maintain.
Form Reform provides many facilities to assist with developing and testing forms. Levels of debug and logging options are configurable on the Options tab of the submit block. Further logging and debug can be added as options in the form handlers and as specialized form handlers provided by the main Form Reform addon and by further extensions such as Form Reform Developer.
For testing captcha handling, consider Radio Captcha.
For many sites, the form handler pipeline will be similar across all forms. The aspects that change are:
Leave the form name as the default 'form_reform' throughout your forms and form blocks. Only change the alias used to save the submitted form data to. The only time you actually need to work with alternate form names in the individual blocks is when there is more than one form on a page.
When a form is used in more than one place, put the entire form into a stack or global area. Then add the stack on any page where you need the form.
Where a form differs slightly between pages, put groups of form input blocks that are used repeatedly with the same settings in a stack. Sometimes an entire form except for just one or two page-specific inputs can be in a stack.
As a rule of thumb, stacks are worthwhile for three or more common blocks. With just two common blocks it very much depends on how many settings need to be configured. It may be simpler to use the Clipboard to copy blocks.
Give stacks a descriptive name such as "Name-Email-Company Form Inputs" and plan a naming convention for stacks to keep your groups of inputs organised.
Big forms are often on pages dedicated to the form with a little boilerplate text. It can be quicker to copy an existing form page and edit the boilerplate than to build a form on an existing page with boilerplate. But, before copying, consider a stack!
As well as using the core Stack display to pull in parts of forms, you can also use Universal Content Puller to pull parts of forms by Page Area or by Stack.
For example, you could use UCP to pull an entire form from another page while filtering out the Submit block. Then add a new Submit block and a few more inputs to your new page.
The clipboard is a standard concrete CMS feature. You can copy any Form Reform block into the clipboard and then paste or drag it from the clipboard to use on another page, just as you would add a block or stack.
The form handler pipeline is configured in the Pipeline tab of the Submit block. The pipeline configuration will usually be be similar for all your forms, so you usually only need to change a few settings between instances of the Submit block. But don't forget to change them or your form will go elsewhere!
Use the the Form Reform Global Settings dashboard page at Dashboard > System & Settings > For Reform > Global Settings to configure a default pipeline and settings. Any new Submit block added to a page will be pre-populated with those settings and you can then make the form and page specific changes.
Where you have similar sequences and configuration of handlers across multiple pipelines, you can use Macros to create re-usable groups of handlers. Think of macros as like stacks of handlers you can insert into multiple pipelines.
Like many of my addons, you can also export settings for the Submit block at Support > Export. Exported settings can consequently be imported into any Submit block or into the global settings.
Whilst you could use Form Reform with stacks, macros and Universal Content Puller to build forms out from multiple levels of sub-components, you really need to think and plan hard before doing so.
When used wisely and fully documented, such a strategy can be incredibly flexible. When used unwisely, you could end up with an unmaintainable knot of indirection.
If in doubt, just build a form directly from input blocks.
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.
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.
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.
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.
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.
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 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.
Save submitted forms to Express objects and user attributes. Add and remove users from groups.
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 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.
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.
A growing suite of resources to assist those developing blocks, handlers and more complex forms for Form Reform.
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.