Closed (won't fix)
Project:
Webform
Version:
6.x-3.11
Component:
Miscellaneous
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
28 Jul 2011 at 10:26 UTC
Updated:
1 Oct 2017 at 08:06 UTC
Jump to comment: Most recent
Comments
Comment #1
arski commentedhmm, I don't seem to have that issue.. you're running the latest ucwp dev, right? and which versions of webform/ubercart?
Comment #2
joachim commentedI'm running:
UCWP 6.x-3.4
UC 6.x-2.4
Webform 6.x-3.11
Comment #3
arski commentedhmm, I have webform 3.11, a recent -dev of UC and the last -dev of UCWP and I don't have the issue.
Do you mind updating ucwp to the latest -dev and testing again (if you select the -dev release in the "Version" field when opening an issue, then that is supposed to mean that you've already tried the latest dev btw)
If you still get the issue.. you could update ubercart to the latest -dev just to check as well if that fixes anything. Although I have a feeling that you either have another module or some custom code interacting here, possibly adjusting the validation function list on the checkout panes - is that a possibility?
Comment #4
joachim commentedThe problem seems to be caused by the presence of http://drupal.org/project/issues/select_or_other -- the radio buttons have the 'other' option form that module enabled.
Comment #5
arski commentedHi again,
I can indeed confirm that the select_or_other widget is causing the field not to validate correctly when used in a checkout pane.
I'm moving this issue over to select_or_other because they should be able to tell us why this is the case, in particular how is their field different from usual Webform fields and why does it act differently somehow.
FYI: the webform inside the checkout panes does not use drupal_get_form and hence stuff like hook_form_alter doesn't apply to that particular form at the moment. However, I don't see a hook_form_alter implementation in your module, so I doubt that's the issue - though I do see quite a bunch of other hooks which I'm not too familiar with.
Cheers,
Martin
Comment #6
danielb commentedI don't know, maybe ask webform? Weird case though...
Comment #7
arski commentedhmm, sure we can ask them, it may indeed be some hook missing or something..
by the way, do you know of any other modules that define fields for webforms? I could take a look at those and see if validation works fine there, and if so - maybe we can figure out why it's not working in your module
Cheers
Comment #8
danielb commentedarski, select or other doesn't define a field for webforms, it defines a drupal form element. The webform functionality is in webform.
Comment #9
arski commentedoh, i thought there was some hook to define webform fields.. but youre right, this element is kind of special so it wouldnt work with default form api options..
so considering this I would guess that the issue lies somewhere in the form element definition inside your module and not inside webform :(
Comment #10
joachim commentedThe webform I have works fine when viewed as a webform node rather than within a checkout pane.
I've not checked with the block version of the webform.
Could it be something that the webform does that UCWP is missing?
Comment #11
arski commentedsure, only it's not so easy to figure out what given that all other fields work fine. If you tell me what webform function is not being called or where its not processing as it usually does, I'll make sure that UCWP takes care of that. But given that I'm not really a Webform (field) expert, I would hope for the maintainers of either Webform, or more appropriately the select-or-other custom module to point me to the missing link.
Comment #12
danielb commentedFYI select_or_other will remove any #required property that you set on it, and instead the #required property will be set on the child select/radio element. IIRC, This was to prevent Drupal complaining about the 'other' field not being filled in.
This should theoretically not hurt anything because when a form is processed all the child elements will be checked for #required instead. Unless you're not considering the dynamic nature of forms and just looping through the widgets from some pre-defined list?
Comment #13
arski commentedhmm, well the form is indeed passed on to the ubercart checkout form constructor as an array of items, but that processes everything as a proper form so i see no reasom why it wouldnt work here..
It does sound like what sel_oo does is very similar to a fieldset, so an array of form elements, and those are indeed problematic in ucwp... That might be it.. Will need to take a look.. However if that is the issue then its more likely caused by uc checkout form processing and i might be unable to do anything about it... We'll see.
Comment #14
quicksketchThis issue may have been fixed by #966028: warning: Illegal offset type in isset or empty when using "Save draft" button with Select or Other..., which is included in the 3.12 version. If someone experiencing the problem could verify if it's been fixed or still broken that would be appreciated.
Comment #15
joachim commentedI've just updated to:
select_or_other-6.x-2.8
webform-6.x-3.12
and I'm still seeing the problem.
Comment #16
arski commentedHmm, I got a little closer to the issue..
It seems that the "select_or_other_element_validate" function is called quite nicely on the field, and indeed it is able to detect if you select "other" but don't input anything - great!
However, if you just leave everything empty.. I don't know what it's even supposed to do? It seems that in that case the validation function just doesn't do anything and hence the lack of error.
Comment #17
quicksketchI don't plan on fixing this issue if it requires installing Ubercart, but I'd be happy to look at any patches.
Comment #18
quicksketchClosing after lack of activity.
Comment #19
Jelmer85 commentedI´m having this problem now..
I need to make sure that the user selects 1 product out 2. He should not be able to proceed without selecting any..