1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Fixed Regression in handling Custom field dropdowns in custom_field_edit

Discussion in 'Resolved Bug Reports' started by Xon, Jan 22, 2015.

  1. Xon

    Xon 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:
    choices.PNG

    Configured to show in the Preferences page.

    What the Preferences page will show:
    Capture2.PNG

    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 likes this.
  2. Steve F

    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.
     
    Xon likes this.
  3. Mike

    Mike XenForo Developer Staff Member

    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:
    Code:
    {$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.
     
    Xon likes this.

Share This Page