[buddypress-trac] [BuddyPress] #4102: Fallback logic in bp_get_the_profile_field_options() is broken

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Thu Mar 29 12:47:52 UTC 2012

#4102: Fallback logic in bp_get_the_profile_field_options() is broken
 Reporter:  boonebgorges  |      Owner:  boonebgorges
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  1.5.6
Component:  XProfile      |    Version:
 Severity:  minor         |   Keywords:
 In bp_get_the_profile_field_options(), there are some logic errors in the
 way that the existing user value(s) for the field are checked (for
 purposes of the `selected` or `checked` attribute):

 - When pulling up user's existing data, we run it through
 maybe_unserialize() (since it might not be an array), but we don't account
 later in the function for the fact that the value might not have been an
 array to begin with (ie, by running `count()` on it; see eg line 541
 xprofile-template.php#L526). This results in PHP warnings in some cases,
 and in others it ends up in us iterating over each letter in a string.
 - Because of the above-mentioned problem, existing string values are not
 being matched properly against arrays. If your value for the field is a
 string 'Leonardo', and the $allowed_options are array( 'Leonardo',
 'Donatello', 'Raphael', 'Michelangelo' ) as checkboxes, 'Leonardo' should
 be checked. It currently is not.
 - We do a check on a `$value` variable a few times in this function, but
 it's never defined.

 Note that these problems are very much edge cases. They only really arise
 (in my experience, at least) when the admin has changed a plaintext field
 to a checkbox/multiselect/radio field. However, this is not that strange
 of a thing to do, and if we can handle it gracefully and without much work
 (which we can), we should.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4102>
BuddyPress <http://buddypress.org/>

More information about the buddypress-trac mailing list