Activity Type API

[modemlooper]

We have some fantastic API's in BuddyPress. I am proposing activity be turned into an API. Components can add their own activity items with supplied meta.

In a way similar to the profile fields options you build in the admin.

Would love to hear some thoughts.

[espellcaste]

+1

[boonebgorges]

We already have an activity API. Create activity items with bp_activity_add(), fetch with bp_activity_get(), register action format callbacks with bp_activity_set_action(), etc.

Are you asking for a more centralized way to handle all these things? Can you give some examples of how it could be streamlined? Or are you asking for the registration of activity types to be part of component registration?

In a way similar to the profile fields options you build in the admin.

This suggests that what you're asking for is a UI, not an API. What would the UI look like? Having a UI suggests that it would be useful for site admins to define custom activity types without looking at code. What are some use cases for this?

[modemlooper]

I don't think admins need a UI. Its more like this:

A component "products" and want to have users post reviews. The reviews could be a special Activity Type for that component with its own post-form.php (custom fields) and entry.php or a sub template for entry.php. Usually we would use something like Gravity Forms to do a front end post UI/UX but then you loose all the BP goodness with replies, notifications, favs etc.

So when creating a component it can add an activity stream for you with a special Activity Type. Like the directory => true when extending BP_Component have Activity => true.

Special activity types show up in the main site wide feed but on your component its just the Activity Type for that component.

[modemlooper]

maybe its just beefing up scopes

[imath]

Tell me if i understand well, just like WordPress have a Post Type / Post formats API, you suggest to have an Activity API that mimic how WordPress does?

Like

bp_register_activity_type( 'reviews', array(
   'labels' => array( 'front_end' => __( 'Reviews' ), 'back_end' => __( 'posted a review' ) ),
   'supports' => array( 'activity_comments', 'activity_favorites', 'activity_mentions' ),
   'activity_format' => 'mini',
   'post_type_object' => 'products',
   'action_format_callback' => 'plugin_prefix_format_reviews_action',
) );

and have something to output the activity using different templates just like post formats ?

I guess, as boonebgorges said this would use existing functions. I can see an interest if someone want to inject some activity posting/fetching feature on a specific single page or post. Like a product page. I also think this is something that would need some shortcodes / UI... So potentially a long road :)

Using existing filters and actions i think you might almost be able to begin this API from a plugin and maybe ask for some core modifications when you're stuck, what do you think ?

[modemlooper]

ya, that sounds like it. permalink for activity could work like single.php as well. I'm gonna explore it a bit

[boonebgorges]

Something like what imath has suggested with bp_register_activity_type() sounds a bit more sane than what we currently have. It's worth noting that this suggestion involves not just building the wrapper itself, but also abstracting some logic that's currently hardcoded (like 'mini' logic).

As for auto-registering when building a component: I'm still not sure I see the big advantage here. I suppose an argument like 'activity=true' could register an activity type using some dummy arguments - though in almost all cases, those arguments (especially the labels) would need to be overridden anyway. There's no way that BP could automatically handle the creation of activity items themselves, because BP can't know when a given component might *want* activity items to be created (on CPT publish, on a specific user action, etc etc etc). But maybe I'm missing the forest for the trees here - seeing a plugin that implements some of this stuff would probably be helpful.

[DJPaul]

I think the idea might be okay, though i'd be more convinced if there was some benefit this would give us inside the BuddyPress core/default, not just for BP developers.

The activity function enhancements above aren't a bad idea, and probably where we would need to start looking at a starting point (we'd need that done before we could let people specify types, and I think it might help us de-hardcode some thing, so it's something that has value to be done by itself first).

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/

[imath]

Working on #8581 I saw benefits in being able to use such an API. Let's try to progress on it during next release.

[imath]

Working on #5644, I’ve made some progress about building such an API, I should be able to provide a patch soon to address these 2 tickets.

[imath]

I've juste added this ​Github PR to #5644 and here's how the Activity Type API looks like:
​https://github.com/buddypress/buddypress/blob/96648f039ab6a101014340a6d8e1b16c66ffffd0/src/bp-activity/classes/class-bp-activity-type.php

[imath]

We'll work on it during next development cycle.