Closed (fixed)
Project:
Options Element
Version:
7.x-1.6
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
15 Mar 2012 at 15:06 UTC
Updated:
31 Mar 2012 at 22:10 UTC
Jump to comment: Most recent file
Comments
Comment #1
liam morlandThe 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.
Comment #2
quicksketchThanks, 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.
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.
Comment #3
quicksketchThis bit of code is responsible for the improper numbering:
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?Comment #4
quicksketchCommitted. Thanks Liam, let me know if you discover any other issues.
Comment #5
liam morlandLooks good. Thanks.