The best way to avoid uncertainty in users of our form is to give them explicit feedback that we have successfully received and processed their submitted data. By default, Webform displays a simple thank you message when a completed submission has been received. This message is displayed on a new page and contains a link to allow our users to return to a new blank form.
However, we will often be required to give a more verbose confirmation message. This is also an excellent opportunity to supply additional information to our form users, or we could merely let them know that an e-mail is en route to them confirming their submission.
Let's customize the confirmation message.
Expand the SUBMISSION SETTINGS fieldset by clicking on the header. Enter the following text in the textarea entitled Confirmation message and click on the Save configuration button at the bottom of the page:
Thank you for registering! An email confirming your registration has been sent to the supplied email address. We look forward to hosting you should the content committee accept your proposed presentation. Further information regarding the success of your proposal will follow in a few days. The Fictitious Conference Organizing Team.
When we previously submitted information via our form, we saw the default Webform confirmation message. By entering text into the Confirmation message textarea we effectively override the default text with our specified text. As with the default message, this text will display on a new page after we submit data to our form.
Webform is utilized in many different ways, so we may not always wish for the confirmation message to be displayed the same way. Let's look at some alternatives.
The default method for displaying the confirmation message is seen under the heading Redirection location on our Form settings page, where the Confirmation page option is preselected. This causes the confirmation message to be displayed on a separate web page as we saw previously.
If we select the No redirect (reload current page) option then Webform will not redirect our users to a confirmation page, but will rather redisplay the Webform with the confirmation message above the form body as a Drupal system message.
We also have the option of redirecting our users to a specially created piece of content that will act as our confirmation page outside the scope of Webform. Such a page would be created by adding new content and making a note of its URL. This URL is entered in the text field adjacent to the Custom URL option on the Form settings page and would take the standard form of node/xx, or whatever URL alias we may have specified for that page. When necessary, we may even redirect our users to a different website altogether by entering a fully-qualified URL (for example, http://www.example.com/confirmation.php).
One of the benefits of using redirects for confirmations is that we may send submitted form values as arguments in the URL and thus include these dynamic values in the content of the custom page. With the aid of a token filter module, or even a custom module of our own, we are able to directly express submitted form values in the confirmation page content.
Intuitively, we may be surprised that Webform token replacements are not available for use on the confirmation page. After all, we are telling the form users that their submission has been accepted, so why can we not directly display information that they have just recently entered? Well, the issue goes around data security.
If we take a look at our browser address bar after completing and submitting a form, we notice that the Webform confirmation page URL contains the numeric submission identifier. This identifier, called sid, is used to locate the data pertaining to each submission and would be used to effect the token replacements. Assuming we have a mischievous and observant user who alters sid in the URL, how could Webform, with 100 percent certainty, prevent this user from seeing someone else's information?
Without radical changes to the internal plumbing of Webform, there is currently no way to prevent this kind of potential abuse, hence the confirmation message text remains static.