Closed (fixed)
Project:
Webform
Version:
7.x-4.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
22 Jul 2014 at 15:47 UTC
Updated:
11 Aug 2014 at 21:30 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
liam morlandThis happens because select components using select_or_other package their values into a array with keys "select" and "other". This patch flattens this.
Comment #2
liam morlandComment #3
liam morlandwebform_conditional_operator_string_not_equal() does not need a corresponding patch once #2307631: *_not_* functions should be wrappers is committed.
Comment #4
danchadwick commentedI'm not sure what the possible array structures are for the input values (haven't researched it), but the test in this patch looks brittle. As yourself, could any valid set of select keys match what you are testing to see if there are "other" values?
Comment #5
liam morlandAs I understand it, $input_values is a 1-dimensional array, unless it is a select_or_other component. In this case, $input_values['select']['select_or_other'] will exist. I don't think there is any other way for $input_values['select']['select_or_other'] to exist.
Comment #6
danchadwick commented@Liam - In that case,
would be a better test, no?
Comment #7
liam morlandI think that test would work, but I don't see why it would be better. My test looks specifically for select_or_other. It could happen that something else could cause there to be an array at $input_values['select'], but it is very unlikely that anything else would use select_or_other as a key.
Comment #8
danchadwick commentedMy logic is that some module -- perhaps other than select_or_other -- might add nesting. Since what you want is the items under 'select', test for what you want to use and use it if it exists, rather than test for something else and infer that what you want should exist.
Comment #9
liam morlandDo I understand correctly: You want it to use $input_values['select'] as the $input_values any time that it is an array.
I don't oppose this if you think it is better.
My thinking was that we should only intervene in the known case, that is, select_or_other, because a different situation might need a different fix.
Comment #10
liam morlandPatch done your way attached.
Comment #11
liam morlandComment #12
danchadwick commentedYuck. My apologies for leading you astray.
There are 4 permutations of "multiple" and "select_or_other" (SOO), and they all look different. Using colors as an example, $input_values is:
Case 00: Neither Multiple Nor SOO:
An array with 0 => 'blue' (because a scalar string was converted to an array). Note that this is indexed by 0, rather than by the value, as is the case with multiple.
Case 01: Multiple only:
An array, with an entry for every option, with 'blue' => 'blue' (or 0, if not selected)
Case 10: SOO only:
An array, with two entries,
'other' => 'pink' and 'select' => 'select_or_other'
OR
'other' => 'pink' (or whatever value was last used, if any) and 'select' => 'blue'
Case 11: Both Multiple and SOO:
An array with two entries,
'other' => 'pink' (or whatever value was last used)
'select' => an array with an entry for every option as above, plus 'select_or_other'
An issue that I see is that case 01 looks exactly like case 10, if your webform component used a 'select' and 'other' as keys.
I think that testing for this in the equal operator function is the wrong place. I suggest "fixing" the values in _webform_client_form_rule_check(). Something like (untested):
Comment #13
danchadwick commentedComment #14
liam morlandYour approach in #12 is working for me. Here it is in two separate patch files. The first does the $component_value refactor (no functional change) and the second that adds the fix for select_or_other.
Comment #17
danchadwick commentedI combined your patches into one commit, which went into 7.x-4.x and 8.x. Thank you very much.
Comment #19
danchadwick commentedFixed a regression during preview.
Comment #20
liam morlandThanks very much.