Problem/Motivation

When zero is used as a valid choice in the "Available options" of an integer select list the edit form fails to find a default value and instead loads the empty option (-Select a value-). The "0" is stored correctly, the widget fails to load the value on the edit form.

Here's an example of options that fail:

KEY|VALUE
0|No idea - I do not know them
10|Uncertain
40|They have some experience
60|They are very experienced
80|They are a professional

Proposed resolution

In the select_or_other.field_widget.inc line 156 the#default_value is calculated by calling !empty() which returns false for a zero value. If we instead use isset() a zero value will be correctly handled.

Remaining tasks

For my use case with zero (0) values this works. Switching to isset() for strings seems to have no impact on the current behavior.

Testing with on a text field with the following available options:

KEY|VALUE
|empty
a|a
b|b

Resulted in the "empty" value being selected on edit no matter if it was "empty" (empty string) or null "- Select a value - " selected using either the existing !empty() or isset().

Attaching patch in a moment. Needs review.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

stupiddingo’s picture

FileSize
1.05 KB

Attaching patch.

stupiddingo’s picture

Status: Active » Needs review

And needs review.

haydeniv’s picture

Commited b4203cb and rolled a new release 7.x-2.18

Thanks!

DamienMcKenna’s picture

Status: Needs review » Fixed

Updated the status as the change was committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit b4203cb on 7.x-3.x, 8.x-3.x:
    Issue #2024693 by stupiddingo: When 0 is stored as an available option...
hhvardan’s picture

Component: CCK / Field API widget » Field widget (non-specific or listed)
Issue summary: View changes
FileSize
824 bytes

The issue still exists ... attaching another patch.