%get[], tokens do not work in disabled or hidden fields
SimonV - February 18, 2008 - 18:42
| Project: | Webform |
| Version: | 6.x-2.0-beta6 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (code needs work) |
Description
I have a system that has property listings on it. I am trying to have people be able to fill out a Reservation Request form from which a copy is sent to their email. I have %get[email] as the default value for an email field that is disabled and required. I have checked off "E-mail a submission copy" for this field and it appears to be enable under the "Conditional email recipients" heading. This field does get the correct value when the form is called, but upon submission I get the error "email field is required." Somewhere along the line the field value has been dropped.
#1
bump
#2
Looks like a general issue with disabled fields rather than something specific to the email component. Disabled fields are not passed along in the $_POST array, so webform is loosing track of them when the value is dynamic and the field is disabled.
I'll see if there's a way to better hook into Drupal's form processing to retrieve the submitted values rather than trying to pull from $_POST.
#3
Thanks for your interest in this... I have a very dirty work around right now that I really don't like using. (A new content type that anonymous can create, no one can edit, that hooks in and sends the body as an email to the author of the node they came from.)
Also, it's a little off topic so I won't post here but if anyone came from the topic that was asking for a select box value to change the email recipient I do have a workaround for that, let me know if you're interested.
#4
Marked http://drupal.org/node/241827 as duplicate
#5
As davis4104 mentioned in the other thread http://drupal.org/node/241827, changing #value in _webform_render_hidden to #default_value works. Setting #value again when it builds the component again after submission it overrides anything that may have been set on the form.
#6
(subscribe)
Is this fix going to be added to the module? I really dislike patching modules, because you have to redo it on every update.
#7
We can speed up inclusion by both making a patch and then testing it. Then I can just commit it after it's been confirmed to work and I don't have to spend the time up-front.
#8
Here is a patch. It works for me.
#9
Rock! Thanks. I committed this change to both 5 and 6 versions.
#10
The same problem happens to disabled textfields.
The values of both hidden and disabled fields are blank in the emails body and also when viewing the form on the results page.
#11
I had the same problem with
When 'submit' is pressed it says there is no value for that textfield, although the value username is perfectly visible when filling in the form.
I could correct this for textfields by in textfield.inc on line 64
changing
'#default_value' => _webform_filter_values($component['value']),back into
'#value' => _webform_filter_values($component['value']),But I might as well have broken something else by doing this. :/ Posted here because I think it's related. Doing the opposite of the patch attached here makes it function again.
#12
Let's reopen this issue as it seems like it's caused new problems. Thanks vint for the update.
#13
Okay, so the problem is solved for hidden fields, but not yet for textfields, textareas, or emails. I think I've found a solution, where the #value needs to be set ONLY if the field is disabled. Setting it to #value even for not-disabled fields would cause a plethora of problems because users woudn't be able to change the value even if the field was editable. Please try out the attached patch (one is for D5 and the other for D6) and let me know if this remedies the problem.
#14
This patch seems to break quite a bit of things (editing submissions). I wouldn't suggest using it. We'll need to figure something else out regarding disabled fields.
#15
Subscribing. This issue drives me nuts since I really-really need the conditional email recipients option to work and to be hidden at the same time.
#16
Regarding "hidden", things should already work fine with hidden fields (in the 2.x dev version). It's "disabled" textareas and textfields that are giving trouble.
#17
quicksketch, thanks a lot! Sure enough, unchecked the disabled check-box and it started working. Not sure though if I hid the field manually myself or the webform actually does it for me. Well, it works - thanks a million!
#18
Subscribing to renegaded "disabled" option on textareas and textfields. ;)
Although "hidden" work just fine, it would be nice to have "disabled" option working.
Bye.
#19
Using a hidden works for me, but is not optimal. I'd like users to see the field, just not be able to edit it.
A work-around that I use is:
- Have a hidden field with default text that is used in the generated email.
- Have a second field with the same default data that is displayed in the form but is not editable. Do not include in the email.
Fixing this bug would be the more elegant solution. :)