[buddypress-trac] [BuddyPress Trac] #5669: Help plugins to generate activities for their post type(s)

[buddypress-trac]

#5669: Help plugins to generate activities for their post type(s)
-----------------------------------+------------------
 Reporter:  imath                  |       Owner:
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  2.2
Component:  Activity               |     Version:  2.0
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |
-----------------------------------+------------------

Comment (by boonebgorges):

 > Unfortunately i cannot rely on bp_ready as it's too late for the
 activity administration screen (dropdown list of activity actions).

 > I am not a huge fan of the name of the new core action,
 "bp_fully_loaded".

 I changed `'bp_activity_tracking_register_post_types'` to 'bp_ready' and
 the admin dropdown seems to be populating fine. And to be honest, if it's
 broken, we should be fixing the dropdown rather than creating a new action
 - we should not be generating markup before 'bp_ready'. Let's try to get
 rid of this new action.

 Some nitpicky feedback as I look through the patch more closely:

 * Why the clever `call_user_func_array()` stuff in
 `bp_activity_tracking_register_post_types()`? Can't we just call
 `bp_set_activity_action()` procedurally?

 * `do_action( 'bp_activity_tracking_register_post_type' );` should be a
 filter. We want to discourage plugin authors from reaching into the `$bp`
 global. Let them modify the `track` array before we stash it.

 * We should sort by 'position' at the time of registration, not at the
 time of output. That way we only have to do it once, and the code is
 cleaner on output.

 * `bp_activity_set_post_type_tracking_args()` is great. This, plus support
 in `register_post_type()`, provides a ton of flexibility to plugin
 authors. If you're going to use `bp_parse_args()` there, be sure to pass a
 third param so it can be filtered. (Or just use `array_merge()`.)

 * 'admin_filter' needs the same treatment as 'bp_activity_new_post' and
 'bp_activity_new_post_ms'. We can't `sprintf()` like this.

 * In `bp_activity_post_type_publish()`, I think your filter on
 'hide_sitewide' is incorrect (and do we need a filter here at all? It all
 runs through `bp_parse_args()` later)

 * I'm a bit confused by your filter backward compatibility in
 `bp_activity_post_type_publish()`. I suggest: remove the individual
 filters from `$activity_args`, and only run the legacy hooks if
 'component=blogs'. That filter can be hardcoded - no need to assemble
 dynamically from the component name. Then have a single filter on all the
 args, or none at all; see my comment above.

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