Fixed Regression in handling Custom field dropdowns in custom_field_edit


Well-known member
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

Well-known member
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.


XenForo developer
Staff member
The related fix that caused this:

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.