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

Comments

moonray’s picture

Version: 4.7.4 » 4.7.x-dev
Assigned: Unassigned » moonray
Status: Active » Needs review
StatusFileSize
new692 bytes

Finally got around to checking out drupal 4.7.x-dev and creating the patch.

killes@www.drop.org’s picture

Version: 4.7.x-dev » 5.x-dev

moving this to 5.x to get more reviews.

chx’s picture

Version: 5.x-dev » 6.x-dev

I 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 '' == 0 but it does not equal any other string or number.

eaton’s picture

By '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?

eaton’s picture

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

chx’s picture

Version: 6.x-dev » 5.x-dev
Priority: Critical » Minor
StatusFileSize
new1 KB

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

chx’s picture

StatusFileSize
new556 bytes

Doh. This issue will serve as a memory of what the form API guys do minutes after they wake up...

drumm’s picture

Status: Needs review » Fixed

Tested with a dummy module. Committed to HEAD.

drumm’s picture

StatusFileSize
new607 bytes

btw, 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.

Anonymous’s picture

Status: Fixed » Closed (fixed)