[buddypress-trac] [BuddyPress Trac] #6714: Filtering messages in bp_core_add_message()

buddypress-trac noreply at wordpress.org
Tue Nov 3 18:20:43 UTC 2015


#6714: Filtering messages in bp_core_add_message()
------------------------------+-----------------------------
 Reporter:  dcavins           |      Owner:
     Type:  enhancement       |     Status:  new
 Priority:  low               |  Milestone:  Awaiting Review
Component:  Component - Core  |    Version:  2.3.3
 Severity:  minor             |   Keywords:  has-patch
------------------------------+-----------------------------
 It's easy to change message strings for all cases by creating a language
 file, but there's currently no way to filter the messages added via
 `bp_core_add_message()` in more specific cases.

 It seems there are (at least) two ways to make these messages filterable:

 * Add filters inline when messages occur, in a more ad hoc approach:
 {{{#!php
 if ( ! empty( $errors ) ) {
         $message = __( 'Please make sure you fill in all required fields
 in this profile field group before saving.', 'buddypress' );
         $profile_field_group = bp_action_variable( 1 );
         $message = apply_filters(
 'xprofile_screen_edit_profile_required_fields_empty_message', $message,
 $profile_field_group );
         bp_core_add_message( $message, 'error' );
 }
 }}}

 * Add a catch-all filter at the function level, which would require the
 call to `bp_core_add_message()` to include useful filter parameters, like
 context and any extra args (which would probably vary by situation):
 {{{#!php
 if ( ! empty( $errors ) ) {
         bp_core_add_message( __( 'Please make sure you fill in all
 required fields in this profile field group before saving.', 'buddypress'
 ), 'error', 'saving_profile_field_group', array(
 'updated_profile_field_group' => bp_action_variable( 1 ), 'reason' =>
 'required_fields_missing' ) );
 }
 }}}

 I've drafted an example of the second approach, but I'm not sure that it's
 superior. The first might actually be easier for developers to use, since
 they wouldn't have to chase the args and context back to the original
 instance. Or maybe having a grand-central-station approach is easier for
 developers. I'm not sure.

 Would this be useful? Is there another approach that would be better?
 Would there be some way to standardize the `$args` array so that it works
 for most cases with a few common keys? This function is called 175 times
 in BP, so there is a lot of variety in its use.

 Thanks for your feedback.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6714>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac


More information about the buddypress-trac mailing list