Fixed Regression in handling Custom field dropdowns in custom_field_edit

[Xon]

From XF 1.4.3 -> XF 1.4.4, there was a regression in how custom field drop downs are handled.

This comes from switching from "==" to "===", and assuming the values of the choices are integers at some stage.

Suppose you have 2 choices:


Configured to show in the Preferences page.

What the Preferences page will show:


The string is $field.field_value, the array is $field.choices dumped via {xen:helper dump}.

Please carefully note that the type of the choice is a string, but the valid choices are integers. No matter what options are selected, the user will not see their choice.

 

[Steve F]

Nice tracking that down. I had the same problems with custom fields and check boxes/radio buttons the other day, so I can confirm this as well.

 

[Mike]

The related fix that caused this: https://xenforo.com/community/threads/minor-issue-in-custom_field_edit.87586/

If the old code worked for you, you can go back to it as a workaround (=== to ==). I went to === to ensure PHP's type coercion doesn't do anything unexpected (such as comparing 0 to "a" and coming back true because it does an integer comparison).

The full fix for the condition is:

{$field.hasValue} && strval({$field.field_value}) == strval({$choice})

This requires exposing strval() to the templates, so it won't actually work in 1.4.4; there could probably be an alternative that would effectively convert the values to strings that would suffice.