Closed (fixed)
Project:
Webform
Version:
6.x-3.6
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
8 Oct 2008 at 15:23 UTC
Updated:
10 Mar 2011 at 07:21 UTC
Jump to comment: Most recent file
Our Webform has 1 field which is set through the url (token) %get[title].
The url looks like this:
http://www.mydomain.at/booking?title=Waldheimathof
If validation returns false for any reason, the url then becomes:
http://www.mydomain.at/booking
I know this issue "could be" tied to the form handling in drupal as well. But I think that it is a genuine bug in the webform. I do have other (non-webform, custom) forms working correctly on our website, they do not however make use of %get tokens.
Note: We may test the upgrade to 2.2 tomorrow as well.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | webform-318578-3.patch | 833 bytes | skilip |
| #15 | webform-318578-ayalon.patch | 798 bytes | ayalon |
| #13 | webform-318578-1.patch | 837 bytes | skilip |
| #8 | webform-6.x-urlvars01.patch | 907 bytes | andrewfn |
| #8 | webform-5.x-urlvars01.patch | 961 bytes | andrewfn |
Comments
Comment #1
jjchinquistHello, I solved my own problem but wish to be made aware if this is the correct way to patch the code! I hope it works for others.
If anyone wishes to report to me directly if this helped, send an email: (http://www.quax.at/jeremy-chinquist).
For version 5.x-2.1.3
line 1231
++
//If any get parameters are set, then save them as well in the action.
//This change only works for clean urls. Must change later
/*@Todo todo: update for non-clean urls. */
$first = true;
foreach($_GET as $k => $v){
if (!($k == "q")){
if ($first){
$form['#action'] .= "?";
}
$form['#action'] .= "&" . $k . "=" . $v;
$first = false;
}
}
For version 5.x-2.2
line 1247
++
//If any get parameters are set, then save them as well in the action.
//This change only works for clean urls. Must change later
/*@Todo todo: update for non-clean urls. */
$first = true;
foreach($_GET as $k => $v){
if (!($k == "q")){
if ($first){
$form['#action'] .= "?";
}
$form['#action'] .= "&" . $k . "=" . $v;
$first = false;
}
}
Comment #2
quicksketchHmm, I don't quite understand what this patch is supposed to be doing. Could you give http://drupal.org/patch/create a look and try to roll a patch?
Comment #3
jjchinquistI will get to it when i have a break, but unfortunately right now too many deadlines await. Thanks though.
Comment #4
quicksketchComment #5
quicksketchComment #6
joelstein commented+1 to this. This bug makes the $_GET variables a very unreliable feature, since I'll guess most people use validation with webform.
Comment #7
quicksketchThis does not seem to affect the 3.x version, which has significantly improved value handling. I'm not sure we'll see a fix for this in the 2.x branch. If a patch is provided for both Drupal 5 and 6 branches I'd be happy to take a look.
Comment #8
andrewfn commentedHere are patches for both Drupal 5 and 6 branches as you wanted (against head in each branch).
I have simplified the logic, tidied up the style and corrected a bug in which both '?' and '&' appear before the first parameter.
Comment #9
quicksketchThis patch has a couple problems.
- The documentation needs to be formatted correctly (include a space after the //, go to the 80 character limit before wrapping)
- This should work without clean URLs
- This will not work with any special characters because each key/value needs to be run through urlencode()
- Related to the above, rather than manually building a string, you should be using the url() function anyway.
I'd suggest something more like the following:
Comment #10
andrewfn commentedThat looks like a much better approach. I will work on a patch using that technique.
Thanks!
Comment #11
Todd Young commentedI haven't been able to resolve this issue in 6.x - Is there a known-working solution, and has it made it into the current version?
Comment #12
quicksketchClosing after lack of activity. The best solution here is just to use Webform 3.x, which is not affected by this problem.
Comment #13
skilip commentedI've created a patch against HEAD for this.
Comment #14
quicksketch@skilip, I don't think this patch should be necessary now that #248157: Allow any Webform to be displayed as a block is in. Please reopen if you have a situation that is not already covered by that patch.
Comment #15
ayalon commentedHi quicksketch
I think, this patch is still necessary. Imagine the following situation:
You have a panel page with a webform. If you enter the panel page with /mywebform?title="test" you can access and prefill some webform field.
If you validate the form and it fails, all GET Params are lost. The url will be /mywebform
I tested patch in #13 and it solves the problem but it is not mergable with the latest version.
I updated the patch for the latest version.
Comment #16
skilip commentedFound a bug in my latest patch which caused the webform to redirect to the home page when the webform is multistep. The following patch solves that.
Comment #17
quicksketchI like the approach in this patch. I'll give it a review next time I'm working on Webform.
Comment #18
quicksketchNice, I tested this patch out and it works great. As an added bonus, it also makes it possible to use %get tokens on pages other than the first page in the form, very cool. Works great in both 3.x branches, committed.