Version 1.5.2 introduced the ability to create forms spread across multiple pages. Each page of the form is a separate submission, each with it’s own submit button which submits the data and takes the user to the next page.
The way multiple-page forms work is each page submits the information to the database, then goes to another form on another page with a different set of fields. The whole series of forms all save their data to the same record. This is accomplished using a session cookie, so the application knows which record the user is filling out.
In Participants Database, each form page is going to have it’s own shortcode which determines which fields are shown on that page. By defining the “action” attribute in each shortcode, the user is taken to the next form page after the form is submitted. Each page shows a different part of the form by setting the fields or group to show in the shortcode on that page.
You may find it convenient to group your fields according to the page they are on. For long, complex forms, it helps orient the user if each section has a title defining the subject the form fields on that page are related to.
Building Your Multi-Page Form
Here is a step-by-step breakdown of how that is done.
- In this example, the form fields are set up so that they are organized into groups with each group corresponding to a page.
- On the first page, add a signup shortcode that defines the group of fields to show on that page. Put the name (slug) of the next page in the action attribute:
[pdb_signup groups="main" action="signup-page-2" submit_button="Next"]
- On page “signup-page-2” put in a record shortcode showing the second page of form controls. Don’t use another “signup” shortcode here, it must be a “record” shortcode:
[pdb_record groups="address" action="signup-page-3" submit_button="Next"]
- On the third form page, add another record shortcode with the action attribute set to the “thank you” page where the [pdb_signup_thanks] shortcode is:
[pdb_record groups="personal" action="thanks" submit_button="Complete the Signup"]
- There must be a “thank you” page at the end of the series to complete the submission. Place the “thanks” shortcode on this page:
The “thanks” shortcode completes the form submission, and any notification emails are sent when that page is loaded.
The user can go forward or back through the form pages (using the browser back or forward buttons) as long as they don’t hit the final submit that takes them to the thanks page. They can even leave the site completely and come back to the form and the fields that were submitted will be filled in (because of the session cookie). The submission can then be completed from that point. If a form is abandoned partway through, the submitted fields will be in the database, but no notifications will be sent.
You can have as many pages as you want, just add more pages with a “record” shortcode.
When organizing your form fields, you can put more than one group per page by specifying the set of groups for that page in the shortcode:
groups="main,address". You can also simply list the fields to include on each page using the “fields” attribute in the shortcode.
The “action” attribute can take a relative or absolute path, page slug or post ID.
Allowing the User to Complete the Form in Multiple Sessions
Since each page of a multi-page form is submitted separately, the user can leave the form while it is in progress and return to complete it later.
It is very important the user understand they must submit the form on each page in order to keep what they have entered so far.
If the multi-page form is a signup form, and the plugin is configured to do this, the user willl recieve an email with their private link when they submit the initial page (which has the
[pdb_signup] shortcode) and this gives them a way to return to the form to complete it.
The difficulty arises when you want to make it possible for the user to return to a specific page. When the signup reciept email is sent to the user, the page the private link goes to will be set in the plugin configuration (Participant Record Page) so it is possible to set that to the second page of the multi-page form. When the user uses the private link provided in the email, it will then take them to the second page of the form.
If the user completes one or more of the pages after the initial page, they may want to go to the next page they need to complete. It is possible to do this with custom code in a custom record shortcode template, but without custom code, they will need to submit each page again to get to the unfinished page.
Any page of a multi-page form can be reached by the user if the URL has the private ID in it.
A Few Things to Know about Multi-Page Forms in Participants Database
Duplicate Record Preference
All multi-page forms use the “Show Validation Error” preference, no matter what setting is selected for that preference. This is for security reasons and to prevent accidental duplicate submissions.
The security consideration is because if an “update” preference was allowed, it would be possible to expose another record if you knew which value to use. For instance, if the duplicate field was “email” and a malicious user wanted to see another user’s data, they could do so if they knew the person’s email.
The duplicate submission problem could happen if someone left the form and came back to it to complete it. A new record would be created for the second session, even though the user intended for the record created in the first form to be completed.