Redirect URL and confirmation message should be two different fields [#520524]

From a pratical point of view, these two webform setting are completly unrelated and orthogonal.

From an usability point of view, it's much more intuitive (and sane) to input the (optional) message and the (also optional) URL redirect on two separate inputs.

The current scheme has even the potential to lead the user to make mistakes: what about cutting and pasting text with "message:" on then? What if pasted text happens to have URLs on the first column? What if you hit "Del" accidentally on the end of a line and you "internal:" redirect are now part of your message (and redirect doesn't work anymore)?

I'm also pretty sure that such change will greatly simplify and increase readability of the module source code. There's no need to do any parsing, regexp maching etc. The code would resume to something like:


if ( $form['message'] )
   drupal_set_message($form['message']);

if ( $form['redirect'] )
   drupal_goto($form['redirect']);

Not to say that the current UI is confusing and misleading. Being a newcomer to the webform module (though a old Drupal user), I spent an half hour trying to realize how on earth such kick*ss module didn't have separate settings from message/URL redirect, because all I wanted to do was display a message and do a redirect.

I had to search Drupal.org for the "solution" (which is using "internal:" and "message:") to discover the special syntax to use on the field that is labelled "Confirmation message or redirect URL".

(Yes, I know it's cleanly explained on the field description -- which I didn't read initially -- but IMHO thats not what description fields are for. I usually look at fields descriptions only as additional documentation about what they do, not to discover theirs purposes.)

Comment	File	Size	Author
#17	webform_external_message_fix.patch	1.12 KB	quicksketch
#17
#14	webform_redirect_url.patch	12.9 KB	quicksketch
#14
#6	webform-520524-6.patch	9.56 KB	djalloway
#6

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

flaviovs CreditAttribution: flaviovs commented 15 July 2009 at 22:47

Category:	feature	» support
Priority:	Minor	» Normal

Well, it looks like I spoke... err.. typed too soon.

After another half hour of struggling with webform node settings and more searching, it's becoming clear to me that it's not possible to setup a confirmation message and URL redirect simply using the UI. Can anyone confirm this? Or am I missing something?

Comment #2

roball CreditAttribution: roball commented 16 July 2009 at 00:00

You can leave this field completely empty and use a "webform-confirmation-NID.tpl.php" file (replace NID with the node ID) instead. This gives you much more flexibility.

Comment #3

flaviovs CreditAttribution: flaviovs commented 21 July 2009 at 19:21

Thanks roball.

That's an alternative, though not so easy to implement by the end user.

Another alternative is to specify a redirect URL and call drupal_set_message() on the webform post-processing field.

This is also "works" but has at least one drawback I experienced by a few minutes ago in a site I'm developing: if for some reason sending the e-mail fails, you get an "could not send email" error just below your "thanks for contacting us" message. Not nice.

IMHO, we should avoid to require PHP tweaking by the end user due to the potential of breaking something, not to mention security issues. Surely, IMHO one should not be required to know PHP just to make a webform show a message after the form is submited.

It shouldn't be too dificult to implement an URL field and confirmation message. I'm pretty sure the developers of the module can do this with their hands tied. :-)

Unfortunately, time is short here, so I can't provide a patch. :-(

Comment #4

aimevp

Dutch

Belgium

CreditAttribution: aimevp commented 27 October 2009 at 17:36

I also think this would be a good idea to seperate message and redirect url because in my case I want to put a webform into a block where webformblock comes in very handy but whenever someone succesful submits a form you get redirected to the webformnode instead of the page on which you included your block.

And again as a developer you need to make a choice between informing the user of the succesful submit or get a correct redirect. I would like to have both.

Or is there in the meantime another way to achieve this?

TIA,
Hatznie.

Comment #5

BlueIrisNina CreditAttribution: BlueIrisNina commented 28 October 2009 at 17:59

Hi,
I have been searching and searching to do this! I would also like the redirect to open in a new window.

Any help on this part? I'm not much of a php coder but I'm starting to learn a bit...

Nina

Comment #6

djalloway CreditAttribution: djalloway commented 29 October 2009 at 14:09

Version:	6.x-2.7	»
Category:	support	» feature
Status:	Active	» Needs review

File	Size
webform-520524-6.patch	9.56 KB

Patch with upgrade path.
Feature will be for the 3.x branch of Webform.

This has been a huge problem for the clients that I work with.
And seeing how our application is built 90% around Webform, made it a priority to fix.

Specifically I want to ensure that these changes are usable and intuitive.

Changes:

Confirmation message / URL has become just Confirmation message.
No longer need the message: prefix within the Confirmation message field (to attain the same functionality that this did just redirect the form to itself? [bad idea?])
Added new field Redirect URL.
Upgrade path to merge existing URL's over into the new field, willl also leave regular message alone.

If there is no re-direct, the webform will use the custom confirmation theme screen and display the confirmation message there.
If the webform is re-directed to itself, the form will re-load and display anything in the Confirmation Message field via drupal_set_message.
If the webform is re-directed to any other page the Confirmation Message will display on this page with drupal_set_message.

Comment #7

DjebbZ CreditAttribution: DjebbZ commented 4 December 2009 at 18:25

This is a feature I've been waiting for long. Simple, but makes the form far more usable and logical, this is exactly the way a form is supposed to work.

Sorry I'm not php knowledeged enough to review the patch. After it's integrated in the 3.x branch, can we expect to see it into the next 2.x release ?

Comment #8

djalloway CreditAttribution: djalloway commented 7 December 2009 at 14:06

I don't think we'll see this in the 2.x branch ever.
Depending on what Quicksketch thinks of it, it 'may' make it in the 3.x branch.
There is no time-line or ETA on that though.

Comment #9

quicksketch

he/him

CreditAttribution: quicksketch commented 21 January 2010 at 03:43

I like this set of changes, but we loose the traditional "show a confirmation page" functionality. After this patch the confirmation can only be shown in the messages area, not as a page. I can see this as problematic for users that use the confirmation page to print out a "receipt".

Though in fairness the user could probably create a second node that prints out receipts and just redirect to that URL. What do you guys think, is this functionality we don't need?

Comment #10

djalloway CreditAttribution: djalloway commented 21 January 2010 at 15:31

Looking back, I see a few flaws in my thought process.
Technically, the patch needs to be updated just a tad.

This would allow the following types of "confirmation" scenarios.

1. Entering a confirmation message with NO redirect URL, would yield the traditional receipt on it's own page. (/node/x/done?sid=x)
2. Entering a confirmation message WITH a redirect URL pointing back at itself would yield the confirmation in a Drupal Message display on the form page.
3. Entering a confirmation message WITH a redirect URL pointing anywhere else would yield, that redirected page, with a Drupal Message display.
4. Entering NO confirmation message and WITH a redirect URL will yield the redirected page with NO additional Drupal message.

This should cover all use-case scenarios, retaining all the old functionality and resolving the UX issues with the existing field.

Once again though, it's all relative, this may not be the best patch to use at all, and that's ok... as long as we've given it a good consideration and analysed the workflow.

Comment #11

quicksketch

he/him

CreditAttribution: quicksketch commented 21 January 2010 at 17:39

This all makes sense to me. I think we can easily drop the "internal:" prefixing too, since if we have a separate field for redirect URL it'll be pretty obvious if it's external or not, and either way we'll just take whatever's in the field and run it through url(), meaning we don't even need this differentiation at all.

Comment #12

flaviovs CreditAttribution: flaviovs commented 21 January 2010 at 18:57

@quicksketch, I think you raised a important issue in #9.

One may always create a page node and redirect users there. We may even add an option to replace some tokens on the redirect URL so that we can pass the submission id (e.g. "/thankyou?sid=%sid").

However, we loose a bit of security as anyone can link to the confirmation page, and even pass a fake submission id (if we're willing to code this feature).

This may not be an issue for the use of webforms on most Drupal sites, but I bet it would cause problem to others.

The solution? Well, I think that the ideal solution is to let the user choose what should be done after form submission:

(  ) Do nothing -- just show webform again (usability: don't forget to set a "Confirmation message")

(  ) Just show the confirmation message on a new page (subject to %sid replacement)

(  ) Redirect to (%sid token available): _________________________________________________

This will require a bit more coding, but IMHO is the best solution.

Comment #13

quicksketch

he/him

CreditAttribution: quicksketch commented 21 January 2010 at 19:26

flaviovs: That's basically what #10 allows, only all the actions are implied. The only one that would require any effort would be the "Do nothing" option, which would require the user to enter the same path as the redirect url. I still like having the confirmation page available as a built-in option, creating a new node just for confirmation is a bit of a hassle. It would also be wise of us to more tightly lock-down the confirmation page so that it is only available after the user has actually finished a submission, such as by adding a generated token for the submission.

Comment #14

quicksketch

he/him

CreditAttribution: quicksketch commented 11 February 2010 at 22:05

Status:

Needs review

» Fixed

File	Size
webform_redirect_url.patch	12.9 KB

I've committed the attached patch, which is based on djalloway's #6 and further suggestions in #10. Providing tokens in the confirmation message seems like a good idea, but probably something that should be handled in a different issue.

Comment #15

roball CreditAttribution: roball commented 11 February 2010 at 22:31

Just had a quick look on that patch and saw

-       <li>Go to Create Content and add a webform</li>
+       <li>Go to Create Content and add a webform<./li>

which must be a typo.

Comment #16

quicksketch

he/him

CreditAttribution: quicksketch commented 11 February 2010 at 22:42

Oy vey! Thanks roball, fixed.

-       <li>Go to Create Content and add a webform<./li>
+       <li>Go to Create Content and add a webform.</li>

Comment #17

quicksketch

he/him

CreditAttribution: quicksketch commented 11 February 2010 at 23:23

File	Size
webform_external_message_fix.patch	1.12 KB

I applied one more fix, which prevents Webform from printing a message when redirecting to an external URL.

Comment #18

roball CreditAttribution: roball commented 12 February 2010 at 08:44

This feature seems to work fine. Note: Users (like me) that had a Confirmation message set at node/[NID]/webform/configure *and* are using a "webform-confirmation-[NID].tpl.php" template that contains something like

<?php print $confirmation_message ?>

should be aware that they probably want to delete that line from the template now. Otherwise, the Confirmation message would be printed twice (as an info message and in the main body).

Comment #19

quicksketch

he/him

CreditAttribution: quicksketch commented 12 February 2010 at 08:49

Thanks again for testing this out roball. This change was quite intended, it fixes #711534: Template override not respected for webform-confirmation, which might have thrown off as many users as it helped. I think we're sitting good for a beta release. :-)

Comment #20

roball CreditAttribution: roball commented 12 February 2010 at 09:03

Yes, and I like this change. I see it as an improvement whenever the need of fiddling around with PHP code in custom files gets decreased.

I will test the next 6.x-3.x-dev rollout coming around 12:30 UTC today to see if time is good to release a beta :-)

Comment #21

bart613 CreditAttribution: bart613 commented 14 February 2010 at 02:03

RE: #10

2. Entering a confirmation message WITH a redirect URL pointing back at itself would yield the confirmation in a Drupal Message display on the form page.

Could someone elaborate, please, on how to point redirect URL back at itself? I tried putting in webform URL, but that didn't work...

Comment #22

quicksketch

he/him

CreditAttribution: quicksketch commented 14 February 2010 at 06:38

Use the url "node/x" where x is the nid of the Webform.

Comment #23

bart613 CreditAttribution: bart613 commented 14 February 2010 at 10:43

@quicksketch - thanks for reply.

I forgot to add that I'm trying to use this webform alongside with Ajax plugin, ie. cause the form to be submitted via Ajax.

It doesn't seems to work anymore :-(

The actual validation is done in Ajax - when one of the fields doesn't validate, and error is thrown just above the form without redirecting the whole page. But when everything is ok, I'm getting redirected (although in perfectly correct manner, as specified in #10.

Further help greatly appreciated.