Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.If a required radio group selection is placed on a webform without a default value and the webform is submitted without choosing a value an error is recorded in the error log. I think this error should not be reported since it's the users mistake and not a code error.
The attached patch fixes this problem.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | webform_865934.patch | 880 bytes | tobiasb |
| #10 | webform_865934.patch | 879 bytes | tobiasb |
| webform.patch | 700 bytes | markwittens | |
Comments
Comment #1
quicksketchThanks, this needs a bit of work in that it would allow a value of "0" to be submitted even it wasn't an option. We should be using isset() here instead of just checking the variable.
Comment #2
quicksketchI can't reproduce this issue on a clean install. The code for validating is identical to Drupal core, so I don't think this would be an issue normally anyway (say Poll module doing the same thing by not setting a default choice on polls). I'll need instructions on how to reproduce this problem.
Comment #3
quicksketchClosing after lack of response.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedI m having the same issue.
Using drupal core 6.19, webform 6.x-2.10. (had same issue on previous version of webform too)
I have a webform with 2 radio selection fields, one is mandatory, second one isnt. Both dont have default value set.
When submitting webform, while no value selected for mandatory field, user gets message "-Field name- is required." Same time in site log appears error message: "Illegal choice in -field name- element".
When no value selected for non mandatory selection field - no error shows up.
Comment #5
vernond CreditAttribution: vernond commentedWhy not just set a default value? If the field is marked as mandatory input the users attention should be alerted in any case. If you choose a default that they do not like then it is up to them to change it.
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedWell thats what i did for now to remove errors from log - set default value. But in some cases you do not want to "push" users to choose specific answer. Often they dont really think, just see something is chosen and dont bother to change it. Anyways its not too important bug, just something which would be nice to see fixed. Since report previously was closed after lack of response, thought i d confirm it with my info.
Comment #7
quicksketchMoving this to the 2.10 version. AFAIK, this problem does not exist in the 3.x version. Upgrading might be a viable way to fix this problem. If the problem does exist in 3.x, I'd be happy to try to correct it. The 2.x version is end-of-life and probably won't see this problem corrected.
Comment #8
markwittens CreditAttribution: markwittens commentedThe fact that you get errors on this field could indicate that users just didn't see the field or don't want to fill it with any given option. Setting a default value could mean you get results people did not really choose or did not really want to choose and are therefore useless.
Comment #9
vernond CreditAttribution: vernond commentedThe original post said it was a required field. As a required field, users are forced to accept one of the options you have on screen in any case. If it is not genuinely required input (i.e. optional) then it should, IMO, rather be expressed as a checkbox list... Dunno where I got it from, but in my fuzzy little world it makes sense to use radio button lists with a populated default value.
In the old days I found that I could not count on the radio field being present in the POST if nothing was selected, not sure if modern browser technology operates differently.
Comment #10
tobiasbThe Bug is also in 6.x-3.x.
Comment #11
tobiasbComment #12
quicksketchInteresting. Thanks for the patch tobiasb. I think this patch would allow a value of "0" to pass through, even if 0 is not a valid option. This could prove dangerous if someone were using Webform as a light e-commerce system (say a large t-shirt now costs $0 instead of $15). I think the equality check should probably be identical,
$elements['#value'] !== ''.Comment #13
tobiasbComment #14
unclejustin CreditAttribution: unclejustin commentedI can confirm this is an issue in 6.x-3.x and that tobiasb's patch fixes it for me.
Comment #15
8thom CreditAttribution: 8thom commentedI can also confirm the patch #13 has fixed this issue for me in 6.x-3.x
Comment #16
quicksketchI don't really like this solution since it's essentially changing code that also exists in Drupal core (Webform just duplicates it identically so that it can skip the processing if necessary). However it's better than no fix at all so I've committed tobiasb's patch from #13. Thanks 8thom for testing.