1. Create a new Webform select component.
2. Enter values, "one", "two", "three".
3. Save.

The first option will appear as "|one". Go back in to edit and choose Manual entry. You will see:

|one||one
1|two
2|three

Comments

liam morland’s picture

Status: Active » Needs review
StatusFileSize
new489 bytes

The attached patch fixes the problem by starting the count at 1 instead of 0. Since these values are hidden anyway, I don't see this as a problem. As well, many users would probably be more familiar with the idea that counting starts at 1.

quicksketch’s picture

Thanks, that looks like a good and easy fix, though we should probably make it so that a key of 0 is supported by default too. I haven't checked what happens if you manually create the keys, i.e.

0|zero
1|one

But I'm guessing that this problem only exhibits itself when there aren't any keys at all? In any case it's a good fix, as this problem arose because of the change we made to Form Builder that used the same pattern of starting at 1 instead of 0. See #1404988: Set default option keys to numbers and increment intellegently for backstory.

quicksketch’s picture

StatusFileSize
new640 bytes

This bit of code is responsible for the improper numbering:

    if (is_int($item['key'] * 1)) {
      $new_key = max($item['key'], $new_key);
    }

So $item['key'] is NULL, which results in the calculation of max(NULL, 0) == NULL, which I would not have expected. While this is the cause of the improper numbering and we can fix it by making sure that the starting number is 0, I agree with you that we should make the starting number 1 nonetheless. Let's do both changes so we don't accidentally run into this problem again. How does this patch look to you?

quicksketch’s picture

Status: Needs review » Fixed

Committed. Thanks Liam, let me know if you discover any other issues.

liam morland’s picture

Looks good. Thanks.

Status: Fixed » Closed (fixed)

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