[buddypress-trac] [BuddyPress Trac] #5630: Enable BP_XProfile_Field_Type classes to register display filter

buddypress-trac noreply at wordpress.org
Wed Jul 23 13:50:51 UTC 2014

#5630: Enable BP_XProfile_Field_Type classes to register display filter
 Reporter:  boonebgorges  |       Owner:  boonebgorges
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  2.1
Component:  XProfile      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |

Comment (by boonebgorges):

 >  Any thoughts on what unhooking all the bp_get_the_profile_field_value
 filters in bp-xprofile-filters.php might look like if we move them into
 their respective display_filters methods instead?

 I agree that this makes much more sense. A couple of complications:

 - Moving them inside the filter will break any plugins that are currently
 using `remove_filter()` on these filters. This is a legitimate concern, as
 I'd imagine that some plugins are removing some of our security features
 to allow additional markup, etc. I can imagine a way of building in
 backward compatibility for this sort of thing, but it would be pretty
 - Similarly, if we move them inside of `display_filters()`, it'd be most
 natural to do something like:

 $value = convert_smilies( $value );

 But calling the functions directly, instead of using the filter API,
 provides a bit less flexibility to plugin devs, since there won't be a
 straightforward way to remove the filtering without overriding the entire
 class. While it's a bit ugly, we might consider doing something like this
 in display_filter():

 add_action( 'bp_xprofile_display_filter_' . $this->name, 'convert_smilies'
 add_action( 'bp_xprofile_display_filter_' . $this->name, 'esc_html' );

 // use this hook if you want to remove_filters()
 do_action( 'bp_xprofile_pre_display_filter_' . $this->name, $this );

 $field_value = apply_filters( 'bp_xprofile_display_filter_' . $this->name,
 $field_value, $this );

 // then maybe remove the filters?

 Not totally straightforward, but it will allow for plugin devs to modify
 the behavior in a fine-grained way (like they can currently). Maybe this
 is something we can look at for 2.2.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5630#comment:13>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list