[buddypress-trac] [BuddyPress Trac] #3460: Support custom post types in activity stream

buddypress-trac noreply at wordpress.org
Sat Mar 1 17:58:55 UTC 2014


#3460: Support custom post types in activity stream
-----------------------------------+-----------------------------
 Reporter:  boonebgorges           |       Owner:  boonebgorges
     Type:  enhancement            |      Status:  new
 Priority:  low                    |   Milestone:  Future Release
Component:  Activity               |     Version:  1.2.8
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |
-----------------------------------+-----------------------------

Comment (by imath):

 Replying to [comment:61 boonebgorges]:
 > I should be clear that I don't think #3856 will make this ticket
 impossible. Only that I think that #3856 should be done before we come up
 with final solutions here.
 oops, my fault, sorry lost in translation : i really should attend some
 english classes ;) I've seen that you posted a patch on #3856, so i renew
 my thanks. I've tested it, it's really an interesting improvement for
 translations.

 > imath, I'm planning to dig deeper into your patch very soon. I think
 that much of it is on the right track and can be used. But I think that
 the critical bit will be to establish easier ways for plugin authors to
 announce to BP that they want to be included in the activity stream, and
 this is something that should probably wait until #3856 has been decided
 on.

 I agree, i think testing the #3856 patch:
 1) BuddyPress plugin developer using custom post types will probably use
 bp_activity_set_action() to set their callbacks
 2) "random" custom post types will not.
 So my idea of using a post type argument to set the callbacks function
 might not be so great or incomplete. Because post types created in 1) will
 probably have their own ways to generate activities, so in this case we
 should give them a way to avoid having 2 activities posted : 1 by their
 plugin, the other by the blogs component. We could rely on the
 'show_in_nav_menus' argument but i'm not sure plugins are "hiding" their
 content visibility from being added to nav menus.

 Then taking in consideration Promotheus Fire comments:
 Custom post types created on child blogs are not visible when in
 root_blog_id, so i thought in 3460.05.patch that it could be interesting
 to let the choice to subsites admin to set their preferences and
 progressively create a "bp option" that would include all the post types
 activated by blogs. I realize:
 - it can be annoying for super administrator to give that "power" to
 subsite administrator
 - it creates an UI only for that into the subsite administrations.

 On the other hand:
 - this UI made it possible to create a specific filter in the template
 selectbox for the custom post type, and when a blog was deactivating the
 custom post type, then the "bp option" was updated or deleted and filters
 were no more showing...
 - Super admin could review the subsite setting...
 - in network admin, the UI didn't need to be completely reviewed to list
 all post types by blogs.
 - if we would have chosen not to display a specific filter action in the
 template selectbox, the "bp option" could have been  avoided...

 Then my other idea, if 3460.05.patch is a "wont-fix", as said in previous
 comment  is to hook the {{{registered_post_type}}} to progressively create
 this list of post types activated by blogs. I thought about transient but
 there's no get_blog_transient() function in WordPress and it's probably a
 bad idea as the key would need to be different by blog, on the other hand
 using transient can help us not updating the list of post types at each
 blog 'init'...

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


More information about the buddypress-trac mailing list