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.

CommentFileSizeAuthor
#13 webform_disabled_textfields5.patch5.02 KBquicksketch
#13 webform_disabled_textfields6.patch4.97 KBquicksketch
#8 patch.diff547 byteswill_in_wi

Comments

SimonV’s picture

SimonV commented

bump

quicksketch’s picture

quicksketch
he/him
commented

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.

SimonV’s picture

SimonV commented

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.

quicksketch’s picture

quicksketch
he/him
commented

Marked http://drupal.org/node/241827 as duplicate

Schoonzie’s picture

Schoonzie commented

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.

will_in_wi’s picture

will_in_wi commented

(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.

quicksketch’s picture

quicksketch
he/him
commented

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.

will_in_wi’s picture

will_in_wi commented
Status: Active » Needs review
StatusFileSize
new patch.diff547 bytes

Here is a patch. It works for me.

quicksketch’s picture

quicksketch
he/him
commented
Status: Needs review » Fixed

Rock! Thanks. I committed this change to both 5 and 6 versions.

kuber’s picture

kuber commented
Version: 5.x-2.x-dev » 6.x-2.0-beta6
Component: Miscellaneous » Code

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.

vint’s picture

vint commented

I had the same problem with

  1. a textfield
  2. with %username set as default data
  3. set to disabled
  4. set to mandatory

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.

quicksketch’s picture

quicksketch
he/him
commented
Status: Fixed » Active

Let's reopen this issue as it seems like it's caused new problems. Thanks vint for the update.

quicksketch’s picture

quicksketch
he/him
commented
Title: %get[] as default value does not work with conditional email recipients » %get[], tokens do not work in disabled or hidden fields
Status: Active » Needs review
StatusFileSize
new webform_disabled_textfields6.patch4.97 KB
new webform_disabled_textfields5.patch5.02 KB

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.

quicksketch’s picture

quicksketch
he/him
commented
Status: Needs review » Needs work

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.

gemini’s picture

gemini commented

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.

quicksketch’s picture

quicksketch
he/him
commented

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.

gemini’s picture

gemini commented

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!

izkreny’s picture

izkreny commented

Subscribing to renegaded "disabled" option on textareas and textfields. ;)

Although "hidden" work just fine, it would be nice to have "disabled" option working.

Bye.

jamiefifield’s picture

jamiefifield commented

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. :)

rank’s picture

rank commented

A fix for this problem will be greatly appreciated.
We have a mandatory and disabled textfield that gets auto populated if the user is logged in (i.e. %username).
This field serves as an important sanity check that the user does have a user account in our site.
In Webform 5.x-2.3 this worked fine; migrated to 6.x-2.3 and we get "xxx field is required" error when submitting the form, although the filed does get auto-populated.
The workarounds suggested in this thread are not an adequate solution for us.
Thank you!

quicksketch’s picture

quicksketch
he/him
commented
Version: 6.x-2.0-beta6 » 6.x-2.3
Status: Needs work » Fixed

I've fixed this in #349418: Fields with "Disabled" (uneditable) and "Manditory" fail to submit and clears that field, which takes a different approach. The option is still called "Disabled" in the administrative interface, but we're actually using the "readonly" HTML property now, which doesn't destroy data like "disabled" does. Please reopen if further problems continue to exist in the 2.4 version which will be released this weekend.

rank’s picture

rank commented

I've tested 6.x-2.4 and verified the fix: a disabled and mandatory textfield is now submitted without a hitch.
Thank you quicksketch!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.