[buddypress-trac] [BuddyPress] #4233: Privacy features don't work?

[buddypress-trac at lists.automattic.com]

#4233: Privacy features don't work?
--------------------------+-----------------------
 Reporter:  Mqlte         |       Owner:
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  1.6
Component:  XProfile      |     Version:
 Severity:  minor         |  Resolution:
 Keywords:                |
--------------------------+-----------------------

Comment (by boonebgorges):

 (In [6069]) In bp_get_the_profile_field_options(), don't delete properties
 from $field global

 bp_get_the_profile_field_options() expects the $field global object to be
 an
 instance of BP_XProfile_Field, because it needs access to that class's
 get_children() method. Inside of a profile loop, however, $field is *not*
 an
 instance of this class. So bp_get_the_profile_field_options() clears
 $field and
 replaces it with a new instance of BP_XProfile_Field. However, this has
 the
 side effect of wiping out any custom data that has been manually inserted
 into
 the $field global (for instance, data and visibility_level). This meant
 that
 visibility level was being reset in the case of radio button and other
 get_children() fields.

 This changeset works around the problem by ensuring that the new
 BP_XProfile_Field object contains all of the properties of the $field
 global
 before it is replaced; when they are missing, they are supplied by the
 manually-created $field global before it is replaced with the new object.

 It will be a good idea down the road to revisit the way that the profile
 loop
 is set up, so that the BP_XProfile_Field is used as much as possible,
 making
 this kind of switcheroo unnecessary.

 See #4233

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4233#comment:11>
BuddyPress <http://buddypress.org/>
BuddyPress