Posted by jjchinquist on October 8, 2008 at 3:23pm
8 followers
| Project: | Webform |
| Version: | 6.x-3.6 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
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.
Comments
#1
Hello, 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;
}
}
#2
Hmm, 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?
#3
I will get to it when i have a break, but unfortunately right now too many deadlines await. Thanks though.
#4
#5
#6
+1 to this. This bug makes the $_GET variables a very unreliable feature, since I'll guess most people use validation with webform.
#7
This 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.
#8
Here 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.
#9
This 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:
<?php$query = $_GET['q'];
unset($query['q']);
$form['#action'] = url($_GET['q'], $query);
?>
#10
That looks like a much better approach. I will work on a patch using that technique.
Thanks!
#11
I 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?
#12
Closing after lack of activity. The best solution here is just to use Webform 3.x, which is not affected by this problem.
#13
I've created a patch against HEAD for this.
#14
@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.
#15
Hi 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.
#16
Found 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.
#17
I like the approach in this patch. I'll give it a review next time I'm working on Webform.
#18
Nice, 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.
#19
Automatically closed -- issue fixed for 2 weeks with no activity.