Closed (fixed)
Project:
Drupal core
Version:
5.x-dev
Component:
forms system
Priority:
Minor
Category:
Bug report
Assigned:
Reporter:
Created:
20 Nov 2006 at 18:25 UTC
Updated:
16 Jan 2007 at 09:45 UTC
Jump to comment: Most recent file
If a select has a mix of numbers and strings as value, and the #default_value is set to 0, you'll wind up with a whole list of selcted options.
Here is the element as it is being fed into the form_select_options function:
Array
(
[#required] =>
[#attributes] => Array
(
[class] => form-select
)
[#input] => 1
[#name] => edit[tasktype]
[#value] => 0
[#id] => edit-tasktype
[#description] =>
[#processed] =>
[#default_value] => 0
[#title] => Task Type
[#options] => Array
(
[0] => All Tasks
[action] => Action
[project] => Project
)
[#tree] =>
[#weight] => 0.003
[#parents] => Array
(
[0] => tasktype
)
[#type] => select
)
And here is the resulting HTML:
<div class="form-item">
<label for="edit-tasktype">Task Type: </label>
<select name="edit[tasktype]" class="form-select" id="edit-tasktype" >
<option value="0" selected="selected">All Tasks</option>
<option value="action" selected="selected">Action</option>
<option value="project" selected="selected">Project</option>
</select>
</div>
Alright, I'm completely confused about the why, but here is the fix (line 663 of form.inc):
<?php
if ($value_valid && ((string)$element['#value'] == $key || ($value_is_array && in_array($key, $element['#value'])))) {
?>
I basically had to add the (string) to cast the $element['#value'] to string.
I would still appreciate an answer as to why, if there is one to be had. :-)
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | test_0.module | 607 bytes | drumm |
| #7 | select_typed_0.patch | 556 bytes | chx |
| #6 | select_typed.patch | 1 KB | chx |
| #1 | drupal_form_options.patch | 692 bytes | moonray |
Comments
Comment #1
moonray commentedFinally got around to checking out drupal 4.7.x-dev and creating the patch.
Comment #2
killes@www.drop.org commentedmoving this to 5.x to get more reviews.
Comment #3
chx commentedI simply refuse to open this Pandora's chest this late. We walked this path before and there be dragons.
Make your
#default_value => $foo ? $foo : '';because'' == 0but it does not equal any other string or number.Comment #4
eaton commentedBy 'there be dragons' chx means that there is a delicate balancing act going on with checkbox default values and proper return values in formapi. the way it treats zeros is the solution that was arrived at before, in the 4.7 beta cycle, and changing it this late in the game in 5 risks introducing another wave of subtle bizarro-bugs. is this a show-stopper? Can't the $foo ? $foo : ''; thing that chx mentioned solve it for the current cycle?
Comment #5
eaton commentedThat'll teach me to post issue clarifications ten minutes after waking up, with no coffee. This doesn't directly relate to checkboxes, but rather is *like* the situation we encountered with checkboxes in 4.7. It can be fixed, and it can be worked around... but if it goes into core this late without a lot of THOROUGH testing it's asking for trouble. Checkboxes taught us that. :-)
Comment #6
chx commentedHardly critical, much rather minor. I slept over it and now I say: here is a patch but I please do not commit it until it got an extremely through review with every wicked possibility. I am thinking of mixed numbers - strings for options, multiple, not multiple, and then default being 0, a number, an empty string, some rome random number, an empty array, an array of 0, an array of on an empty string, an array of some random number, then the submitted value being 0, an array of 0 etc.
Comment #7
chx commentedDoh. This issue will serve as a memory of what the form API guys do minutes after they wake up...
Comment #8
drummTested with a dummy module. Committed to HEAD.
Comment #9
drummbtw, here is the module I used to test. I'll leave the .info file as an exercise for the reader unless someone asks for it.
Comment #10
(not verified) commented