[buddypress-trac] [BuddyPress Trac] #6515: Allow plugins to filter groups_format_notifications unmatched return values. (was: Add $format arg to groups_format_notifications filter.)

[buddypress-trac]

#6515: Allow plugins to filter groups_format_notifications unmatched return
values.
---------------------------------------+------------------------------
 Reporter:  dcavins                    |       Owner:
     Type:  enhancement                |      Status:  new
 Priority:  lowest                     |   Milestone:  Awaiting Review
Component:  Component - Notifications  |     Version:  2.3.2
 Severity:  trivial                    |  Resolution:
 Keywords:  has-patch                  |
---------------------------------------+------------------------------
Changes (by dcavins):

 * component:  API => Component - Notifications


Comment:

 OK, I'm not sure I understand what the action that I was modifying is
 meant to do. It appears at the end of a long switch for each of the
 various group-related `component_actions` but it doesn't seem as though a
 `do_action` allows a hooked function to return a value for the originating
 function.

 Here's what I'm thinking should be possible: Group-related plugins add
 their own custom `component_actions`, but they are really group-related,
 so they attempt to save them like this:

 {{{
 'user_id'           => $user_id,
 'item_id'           => $group_id,
 'secondary_item_id' => $meaningful_id,
 'component_name'    => 'groups',
 'component_action'  => 'my_plugin_action'
 }}}

 As `groups_format_notifications()` is currently written, any unrecognized
 action will not match any of the cases in the long switch and then fire
 off the `do_action( 'groups_format_notifications' )` before returning
 false.

 If it makes any sense for plugins to use the ` 'groups'` as a
 `'component_name` then my second patch adds a default case to the long
 switch so that unmatched actions will do an `apply_filters( 'bp_groups_' .
 $action . '_notification', null, $item_id, $secondary_item_id,
 $total_items, $format )`, which, if a notification results, will be
 returned.

 I'm not sure if we really want plugins that create notifications to
 declare a unique `component_name` when adding notifications (even though
 they aren't really a full-blown component), or if it makes sense to
 piggyback on existing components.

 Thanks for your input, notification-savvy people.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6515#comment:1>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac