PhpRiot
Become Zend Certified

Prepare for the ZCE exam using our quizzes (web or iPad/iPhone). More info...


When you're ready get 7.5% off your exam voucher using voucher CJQNOV23 at the Zend Store

Creating Multi-Step Forms And Wizards In PHP

Multi-page Form Considerations

There are several aspects of multi-page forms that need to be considered in the building process, including passing of form values between steps, preparing form data (e.g. dropdown box options on a particular step) and jumping between steps. Here I will cover each of these and suggest they can be dealt with.

Form values

Generally speaking, each step of the form will generate a set of values. These values will be used for different things. For example, at the completion of the form all values may be saved into your database. Or maybe a certain value determines which step is shown to the user next. Either way, we need to track the values somehow between each page.

There are basically two ways to achieve this. The first is to save every value as a hidden HTML input element. This way every submitted value is submitted on each subsequent form step and then reprocessed each time. For example:

Listing 1 listing-1.php
<input type="hidden" 
       name="some_earlier_value" 
       value="<?= htmlSpecialChars($wizard->values['some_earlier_value']) ?>" />

The easiest way to implement this would be to simply loop over all the previously submitted values and echo them in an input element such as above.

Personally though, I would store all previously submitted values in the PHP session. There are many advantages to doing this, including:

  • Don’t have to worry about transporting all data between each step as this will be implicitly handled
  • Can implement a page refreshing prevention (see below)
  • Makes it easier to jump between arbitrary steps (see below)
  • Not as much processing required, as with session we can assume previously validated values are still valid, whereas when resubmitting all values, all values should be reprocessed regardless of which step they came from.

So as you can see, implementing your wizard so form values are stored in session is probably the way to go.

Knowing the current step

The next consideration is knowing the current step that is being displayed, or the step that is being processed. This is generally as simple as passing a parameter as to which step the submitted data is for.

However, there is an extra consideration for this to be made. That is, we must ensure that the step that is being processed (based on what the form says) is actually allowed to be processed. For example, if step 2 of the wizard requires a person’s name to have been entered in step 1, then when we try to process step 2 we must ensure that step 1 has previously been successfully processed.

Normally there isn’t much issue here, as if people use your form correctly they would only proceed to step 2 if step 1 was correct, however, if somebody was trying to forge your form and submit step 2 directly, we need to ensure they have first completed step 1.

Additionally, there may be forms where a certain step doesn’t rely on another step. For example, a user may want to go directly to step 3 rather than filling out step 1. Or they may want to jump backwards from step 2 to change a value in step 1. Somehow we need to handle these step changes.

Different paths

Closely related to the previous issue of knowing the current step, is the is issue of having multiple paths in your form. In other words, the sequence of form steps to be displayed depends on the data the user enters.

For example, let’s say the user is filling out a questionnaire, and there is a different set of questions for males and females. On the first step, there is question that asks the user’s gender. Now, if the user chooses male, then the step which male questions should be shown, and likewise for females. Let’s say the gender question step is step, the male questions are step 2 and the female questions are step 3. In this case, step 2 and step 3 rely on step 1 being completed, however, step 3 does not rely on step 2.

Put logically, if gender is male, jump to step 2, else (if gender is female), jump to step 3.

Confirmation page step

Often you will want the ability to show the user confirmation of what they have entered. This is simply a form step that has no inputs (other than to confirm the data is correct).

You could even consider a one page form that also has a confirmation form to be a multi-page form. This is commonly used in order forms to confirm the person’s billing and shipping addresses, as well as the option to change them.

Final processing

Once the form is complete (or in the context of the previous paragraph, the user has confirmed the form is correct), you will likely need to do extra processing. For example, submitting the details into the database.

In fact, you could once again do something like the confirmation page step. It would be the same thing, but just to say the form has completed (or the order has been finalized, etc.).

For example:

  • Step 1: Enter billing and shipping details
  • Step 2: Confirm details are correct
  • [ process form, ship the item and send the user an email]
  • Step 3: Show confirmation the order has completed

In This Article


Additional Files