The screen-dump below is from this issue #2762705: Slick view and Drupal 7.50 new issue.
Notice that the version number given in the sidebar top right is "7.50", but the version number that appears in the editable metadata is "7.5".
As you can see from the comments Fabianx corrected the version number in #2. The correction is registered, but the change does not "stick". When another comment is added it is bumped back to "7.5" again (unless the commenter explicitly corrects it to "7.50").
Comment | File | Size | Author |
---|---|---|---|
#21 | select_elements_should-2762953-21.patch | 662 bytes | cilefen |
#11 | list_text_field-2762953-11.patch | 2.65 KB | cilefen |
#11 | list_text_field-2762953-11-TEST.patch | 1.94 KB | cilefen |
#9 | list_text_field-2762953-9.patch | 733 bytes | cilefen |
Comments
Comment #2
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI seem to remember something like this happening with Drupal 7.40 too... at least I think. So I would guess there is some code somewhere which is evaluating these numerically and thinks "7.50" and "7.5" are the same thing.
Comment #3
drummLooking into this, it can be reproduced with 7.40.
Comment #4
drummI can reproduce this with a fresh copy of Drupal core.
Comment #5
drummI can reproduce this in 8.2.x-dev too.
Comment #6
drummThe markup ends up as
Browsers go with the last selected option. This confirms it is a PHP issue.
For Drupal.org, I’ll hold off building, and maybe even deploying, a fix since this is a bit of an edge case, the -dev versions are preferred anyway. See also #2691889: Add option to remove tagged releases from the version selector.
Comment #7
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedComment #8
cilefen CreditAttribution: cilefen commentedI just did a lot of debugging and the bug is in form_select_options().
Comment #9
cilefen CreditAttribution: cilefen commentedComment #11
cilefen CreditAttribution: cilefen commentedComment #13
drummLooks good to me.
Comment #14
drummMore-accurate title since this is a Form API issue.
Comment #15
alexpottin_array() really should default to TRUE - classic PHP mistake. Nice find and and nice test!
Committed and pushed 2893aec5df3d95fd6e4da2401cd8aa661045c13a to 8.2.x and 2280ea7 to 8.1.x. Thanks!
Setting as 'patch to be ported' till the Drupal 7 backport issue is open.
Comment #18
cilefen CreditAttribution: cilefen commented#2770641: Backport from D8: Select elements should use strict comparison
Comment #19
cilefen CreditAttribution: cilefen commentedComment #20
cilefen CreditAttribution: cilefen commentedBe aware, the same simple fix breaks TaxonomyTermTestCase::testTermInterface in D7, which incidentally tests multiselect list options with integer keys, so those field types may not have the test coverage they need and this may not be releasable.
Comment #21
cilefen CreditAttribution: cilefen commentedThis probably needs a revert and new test coverage. This patch explains why.
Comment #22
cilefen CreditAttribution: cilefen commentedComment #25
alexpottTook the safe route and reverted...
Comment #36
drummMarking #2176623: form_select_options() does not perform strict strings check when default value is array as a duplicate of this issue.
Comment #42
quietone CreditAttribution: quietone at PreviousNext commentedI tested this on a fresh install of the standard profile on Drupal 7.90-dev and 9.4.x. I followed the steps in #4 and was not able to reproduce the problem. I don't know when it was fixed, just closing as outdated.
If that is wrong, reopen and explain what needs to be done.
Thanks