Jump to:
| Project: | Webform |
| Version: | 6.x-3.15 |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | DC_Marc |
| Status: | closed (fixed) |
Issue Summary
If you look at the form located at http://gysd.org/node/22 it isn't providing feedback for submissions that violate validation rules. Also, on page 2 of the form on the admin side, if I place a token such as %post['country'], it shows up as just blank rather than as the actual name of country, for example. Any thoughts as to why this might be occurring? I also have Webform Events and Webform Validation installed. I previously had Webform Conditionals installed but uninstalled it because I decided I'd wanted a two-page form rather than a one-pager.
Why would this form not be providing feedback or accepting tokens, though?
Marc
P.S. here is a complete list of modules I am currently running: Drupal core 6.22 (Block, Database logging, Filter, Help, Menu, Node, PHP filter, Path, System, Taxonomy, Update status, User Modules)
Administration menu 6.x-1.8
AES encryption 6.x-1.4
AudioField 6.x-1.0
Backup and Migrate 6.x-2.4
Better Formats 6.x-1.2
Chaos tool suite (ctools) 6.x-1.8 (Chaos Tools (CTools) AJAX Example, Chaos tools, Custom content panes, Page manager, Views content panes)
Content Construction Kit (CCK) 6.x-2.9 (Content, Fieldgroup, Node Reference, Option Widgets, Text)
Content Management Filter 6.x-2.01
Diff 6.x-2.3
Embedded Media Field 6.x-2.5 (Embedded Audio Field, Embedded Image Field, Embedded Inline Media, Embedded Media Field, Embedded Media Thumbnail, Embedded Video Field)
FileField 6.x-3.10
Google Analytics 6.x-3.3
Google Fonts 6.x-1.7
ImageAPI 6.x-1.10 (ImageAPI, ImageAPI ImageMagick)
ImageField 6.x-3.10
Imagefield Crop 6.x-1.0
IMCE 6.x-2.3
IMCE Wysiwyg bridge 6.x-1.1
jQuery UI 6.x-1.5
jQuery Update 6.x-2.0-alpha1
Link 6.x-2.9
Media: Flickr 6.x-1.12
Media: YouTube 6.x-1.3
Mollom 6.x-1.16
Nice Menus 6.x-2.1
Options Element 6.x-1.4
Panels 6.x-3.9
Path redirect 6.x-1.0-rc2
Poormanscron 6.x-2.2
Read More Link (Drupal 6 and earlier) 6.x-5.0
Scheduler 6.x-1.8
Select (or other) 6.x-2.9
Signup 6.x-1.0
Slider 6.x-1.4
Slideshare 6.x-1.0-beta3
Transliteration 6.x-3.0
Views 6.x-3.0
Webform 6.x-3.15
Webform events 6.x-1.4
Webform Validation 6.x-1.5
Wysiwyg 6.x-2.4
Comments
#1
Could you provide steps for reproducing your problem? It's easier to see where the problem comes from if you describe how the form was set up (especially what tokens you're using where), rather than trying to look at a form just from the front-end. If I can reproduce problems locally on my own machine, that also eliminates the possibility of it being a server configuration problem, a problem in the theme, or a conflict with another module.
If that's the exact format of token you're using, then that explains the problem right there. Webform tokens do not have quotes around the values. So it would be %post[country], not %post['country'].
#2
Thanks for the prompt reply!
Sure, to reproduce the problem, here are the two things I just did:
(1) I created a new form. I added an email field and made it mandatory. I added a page break then a mandatory select list on page two. I saved the components, went back to the Webform, submitted it without the email address, and saw it reload the page without providing me any validation feedback as to why.
[Hopefully, I am providing the information you need here, but if not, I'm happy to try again!]
(2) As far as tokens, I was pretty careful to make sure that I used correct punctuation -- when I typed it in the issue report, I just did that part form memory. Country is the ONLY token I used. In my text form for reproducing the problem, I added a second, mandatory, disabled email field on the second page and called it email2. I set the default value to %post[email] but when you type an email in the first page, then on the second page, the email field shows up blank.
Is this enough to reproduce the problem? I hope so. If not, please let me know what I can do to help. Thanks :)
#3
#4
This is definitely not a problem on a clean installation of Webform. I'm guessing that your theme may not be displaying status messages. Do you see other messages in your theme, such as when you log in?
This probably won't work for multiple reasons. 1) %post[key] only works for logged in users and 2) the $_POST array is nested. Fields from the previous page would actually be in $_POST['submitted']['email']. The %post token does not currently support nesting, as described in #824606: Webform tokens (%session, %post) do not support arrays
#5
Thanks for the prompt attention to the issues I have been facing.
You are right that it was an issue with theme messages. I had actually figured that out right before you posted your reply. It was your original reply that led me to think it could be the theme to begin with. Indeed, $messages had been taken out of the PHP page template by a previous developer.
As for the token, it sounds as though there is no way to carry any token over from a previous page of the same Webform when data get submitted anonymously. Did I understand you correctly on that point? If so, I appreciate the information.
Thank you.
#6
Is the method described here one you would recommend for or against?
http://drupal.org/node/947678
#7
Against. Considering you could put %cookie[SESS01234567890] in the field for an anonymous user, then that cookie ends up in the page cache of the first user who visits the page, now everyone can spoof that user's session. That may not be a common use-case, but it's too dangerous to allow it in Webform core. I think we should implement this solution: #630476: Allow hidden fields to handle unsafe tokens by making the "value" type fields.
#8
Cool. Thanks so much for all your help. I'm probably not technically skilled enough to know how to best leverage the Javascript approach anyway, but I can do without the anonymous token regardless. Thanks again, really appreciate your responsiveness! Feel free to close now. I'd do it but wasn't sure which category of closed to indicate.
#9
Cool, we'll mark it fixed. "fixed" issues get moved to "Closed (fixed)" after 2 weeks with no activity.
#10
Automatically closed -- issue fixed for 2 weeks with no activity.