BuddyPress REST API, what’s new in 7.0.0 ?

First of all, the Developer documentation has been updated according to the latest improvements we’ve brought to the BuddyPress REST API!

Members Endpoints

What’s the friendship status of the logged in user with other(s)?

If the Friends component is active and you’re wondering what’s the answer to this question, then you can get a clue thanks to a new property we’ve added to the Members item schema: friendship_status_slug.

Here’s an example of use of this new property:

/**
 * Showing the `friendship_status_slug` Members Endpoint's schema property.
 */
function test_bp_rest_api() {
	wp_enqueue_script( 'bp-api-request' );
	wp_add_inline_script(
		'bp-api-request',
		'bp.apiRequest( {
			path: \'buddypress/v1/members\',
			type: \'GET\',
			data: {
				context: \'view\',
				type: \'active\',
				exclude: [2]
			}
		} ).done( function( data ) {
			data.forEach( function( member ) {
				console.log( member.name + \' => \' + member.friendship_status_slug );
			} );
		} ).fail( function( error ) {
			return error;
		} );'
	);
}
add_action( 'bp_enqueue_scripts', 'test_bp_rest_api' );
Click on the image to view it in full screen

As you can see in the above browser’s inspector, the logged in user is :

  • not friend with admin (friendship_status_slug: 'not_friends'),
  • has requested a friendship request to Mercime that is still pending her approval (friendship_status_slug: 'pending'),
  • has received a friendship request from John that is awaiting his response (friendship_status_slug: 'awaiting_response'),
  • friend with Boone (friendship_status_slug: 'is_friend').

When was a user last active, what is his/her latest update and how many friends do he/she has ?

There’s now a new request argument you can use to know these information : populate_extras. You simply need to set it to true to do so. The response will include these extra properties:

  1. The last_activity object which contains 2 properties: 
    • date: the date the user was last active,
    • timediff: a human diff string, eg: “20 minutes ago”.
  2. The latest_update object which contains 3 properties:
    • id: the ID of the activity,
    • raw: the content of the activity as it exists into the database.
    • rendered: the content of the activity ready for output.
  3. The total_friend_count variable which contains the number of friends of the user (integer)

Here’s an example of use of this new request argument:

/**
 * Showing the `populate_extras` Members/:user_id request argument.
 */
function test_bp_rest_api() {
	wp_enqueue_script( 'bp-api-request' );
	wp_add_inline_script(
		'bp-api-request',
		'bp.apiRequest( {
			path: \'buddypress/v1/members/2\',
			type: \'GET\',
			data: {
				context: \'view\',
				populate_extras: true
			}
		} ).done( function( member ) {
			console.log( \'Last activity:\' );
			console.log( member.last_activity );
			console.log( \'Latest activity update:\' );
			console.log( member.latest_update );
			console.log( \'Total number of friends:\' );
			console.log( member.total_friend_count );
		} ).fail( function( error ) {
			return error;
		} );'
	);
}
add_action( 'bp_enqueue_scripts', 'test_bp_rest_api' );
Click on the image to view it in full screen

Can I assign more than one Member Type to a member like it’s now possible in BuddyPress?

Yes you can! You simply need to use a comma separated list of Member Types into the member_type request arggument when updating/creating the user.

Here’s an example for the first case:

/**
 * Showing the `member_type` request argument for the members/:user_id endpoint.
 */
function test_bp_rest_api() {
	wp_enqueue_script( 'bp-api-request' );
	wp_add_inline_script(
		'bp-api-request',
		'bp.apiRequest( {
			path: \'buddypress/v1/members/2\',
			type: \'PUT\',
			data: {
				context: \'edit\',
				member_type: \'leads,developers\'
			}
		} ).done( function( member ) {
			console.log( \'Member Types\' );
			console.log( member.member_types );
		} ).fail( function( error ) {
			return error;
		} );'
	);
}
add_action( 'bp_enqueue_scripts', 'test_bp_rest_api' );
Click on the image to view it in full screen

Groups Endpoints

Is there a route to get the groups the logged in user belongs to?

Yes, it’s /buddypress/v1/groups/me. Querying it you’ll get a list of these groups for the current user.

Here’s an example about how to use it:

/**
 * Showing the groups/me endpoint.
 */
function test_bp_rest_api() {
	wp_enqueue_script( 'bp-api-request' );
	wp_add_inline_script(
		'bp-api-request',
		'bp.apiRequest( {
			path: \'buddypress/v1/groups/me\',
			type: \'GET\',
			data: {
				context: \'view\'
			}
		} ).done( function( groups ) {
			console.log( \'My Groups\' );
			groups.forEach( function( group ) {
				console.log( group.name );
			} );
		} ).fail( function( error ) {
			return error;
		} );'
	);
}
add_action( 'bp_enqueue_scripts', 'test_bp_rest_api' );
Click on the image to view it in full screen

When was the last time a group was active & how many users are members of this group ?

Juste like for the Members Endpoints (GET Members & GET Member), there’s now a new request argument you can use to know these information : populate_extras. You simply need to set it to true to do so. The response will include these extra properties:

  1. total_member_count: the count of all Group members,
  2. last_activity: the date the Group was last active,
  3. last_activity_diff: the human diff time the Group was last active.

Here’s an example about how to use it:

/**
 * Showing the `populate_extras` Groups/:group_id request argument.
 */
function test_bp_rest_api() {
	wp_enqueue_script( 'bp-api-request' );
	wp_add_inline_script(
		'bp-api-request',
		'bp.apiRequest( {
			path: \'buddypress/v1/groups/1\',
			type: \'GET\',
			data: {
				context: \'view\',
				populate_extras: true
			}
		} ).done( function( groups ) {
			groups.forEach( function( group ) {
				console.log( \'Last activity date:\' );
				console.log( group.last_activity );
				console.log( \'Last activity time diff:\' );
				console.log( group.last_activity_diff );
				console.log( \'Total number of group members:\' );
				console.log( group.total_member_count );
			} );
		} ).fail( function( error ) {
			return error;
		} );'
	);
}
add_action( 'bp_enqueue_scripts', 'test_bp_rest_api' );
Click on the image to view it in full screen

Is it possible to append one or more Group Types to the Group Type(s) the group is assigned to ? What about removing one or more specific Group Types from the ones the group is assigned to ?

The PUT verb of the Groups/:group_id endpoint now supports 2 new request arguments to achieve this:

  • append_types : a string containing the Group Type name to append to existing group’s Group Types. To append more than one Group Type, use a comma separated list of Group Type names.
  • remove_types : a string containing the Group Type name to remove to existing group’s Group Types. To remove more than one Group Type, use a comma separated list of Group Type names.

Here’s an exemple of appending Group Types to the one that is already assigned to the group:

/**
 * Showing the groups/:group_id update method new request arguments.
 */
function test_bp_rest_api() {
	wp_enqueue_script( 'bp-api-request' );
	wp_add_inline_script(
		'bp-api-request',
		'bp.apiRequest( {
			path: \'buddypress/v1/groups/1\',
			type: \'PUT\',
			data: {
				context: \'view\',
				append_types: \'team,pizzalovers\'
			}
		} ).done( function( groups ) {
			console.log( \'The initial + appended group types:\' );
			groups.forEach( function( group ) {
				console.log( group.types );
			} );
		} ).fail( function( error ) {
			return error;
		} );'
	);
}
add_action( 'bp_enqueue_scripts', 'test_bp_rest_api' );
Click on the image to view it in full screen

Activity Endpoint

Is it possible to filter the list of activities on more than one action/type?

Yes, to filter the fetched activities (GET Activities) on one action/type, you need to set the type collection parameter to an array containing the corresponding action/type. For more than one action/type, include all the needed actions/types into the array used as the type collection parameter.

Here’s an example of how to achieve this:

/**
 * Showing the activity streams filtered on 2 actions/types.
 */
function test_bp_rest_api() {
	wp_enqueue_script( 'bp-api-request' );
	wp_add_inline_script(
		'bp-api-request',
		'bp.apiRequest( {
			path: \'buddypress/v1/activity\',
			type: \'GET\',
			data: {
				context: \'view\',
				type: [\'activity_update\', \'friendship_created\', \'friendship_accepted\']
			}
		} ).done( function( activities ) {
			console.log( \'Updates and created friendships:\' );
			activities.forEach( function( activity ) {
				console.log( activity.id + \' => \' + activity.type );
			} );
		} ).fail( function( error ) {
			return error;
		} );'
	);
}
add_action( 'bp_enqueue_scripts', 'test_bp_rest_api' );
Click on the image to view it in full screen

Do we still need to set the component request argument to groups when fetching group activities about a specified group_id request argument?

No! From now on the group_id is enough, of course you can still alternatively use a request (GET Activities) having the primary_id argument set to the ID of the group and the component argument set to groups.

Here’s an example about how you can use this request argument:

/**
 * Showing the activity streams filtered on a specific group.
 */
function test_bp_rest_api() {
	wp_enqueue_script( 'bp-api-request' );
	wp_add_inline_script(
		'bp-api-request',
		'bp.apiRequest( {
			path: \'buddypress/v1/activity\',
			type: \'GET\',
			data: {
				context: \'view\',
				group_id: 1
			}
		} ).done( function( activities ) {
			console.log( \'Group Activities:\' );
			activities.forEach( function( activity ) {
				console.log( activity.id + \' => \' + activity.component );
			} );
		} ).fail( function( error ) {
			return error;
		} );'
	);
}
add_action( 'bp_enqueue_scripts', 'test_bp_rest_api' );
Click on the image to view it in full screen

Blogs Endpoint

And last but not least, we’ve added a new route to let users create a blog (POST Blog) when the Network option is allowing it, read more about it from our freshly updated Developers documentation.

PS: if you want to get all examples at once, here’s a Gist.

#7-0-0, #rest-api

Meet the new default avatar for Sites

The BuddyPress Members and Groups were the only components to have a default avatar so far. The Site Tracking component felt very strongly about it, protesting it was about time to give it a default “blavatar” (blog avatar) 😁. It’s finally happening in BuddyPress 7.0.0 🙌.

The default site avatar

The default blavatar !

Multisite WordPress configurations will be able to find it when displaying the Sites directory. It appears when sites of the loop doesn’t have a WordPress Site Icon set. Here’s how this directory will look like once BuddyPress 7.0.0 will be released.

Using a Site Icon as the Site’s avatar

The Site Icon / Site Avatar synchronization of the Site Tracking component was introduced in BuddyPress 2.7.0, but here’s a reminder about how to set a Site Icon for a site of your network.

The Site Icon Customizer’s panel

The primary use of the WordPress Site Icon feature is to generate icons for your site so that, for example, it displays into your browser’s tab (favicon). You can set it using the Cutomizer from the corresponding site of the network. In our example the WordPress site. Once the Customizer is loaded, head over to the Site Identity panel and you’ll find the place to set the Site Icon at the bottom of it (⚠️ don’t confuse with the Site Logo). Click on the “Select Site Icon” button (or the “Change image” button if you already have a Site Icon in place) to upload your image and crop it to match WordPress needs. Once you’ll publish your changes, BuddyPress will automagically use this image to set the Site’s avatar and use it everywhere the Site Tracking component is displaying your site (into the Sites directory and into the “Sites” tab of the Member’s front-end profile page for the users attached to this site).

Tada!

Keeping the Site’s admin avatar as the default Site’s avatar

If you prefer to keep on displaying the Site’s admin avatar as the default site avatar after BuddyPress 7.0.0 is released, you can always do so using the following piece of code into your bp-custom.php file for example.

/**
 * Filter to carry on using site admin avatar.
 *
 * @param array $args The Blog Avatar arguments.
 * @return array      The Blog Avatar arguments.
 */
function carry_on_using_site_admin_avatar( $args ) {
	global $blogs_template;

	if ( isset( $blogs_template->blog->admin_user_id ) ) {
		$args['admin_user_id'] = (int) $blogs_template->blog->admin_user_id;
		$args['alt']           = sprintf(
			/* translators: %s: the author display name */
			__( 'Profile picture of site author %s', 'buddypress' ),
			esc_attr( bp_core_get_user_displayname( $args['admin_user_id'] ) )
		);
	}

	return $args;
}
add_filter( 'bp_before_blog_avatar_parse_args', 'carry_on_using_site_admin_avatar', 10, 1 );

If you’d like to know the story of this change, you can get more information reading the #8179 ticket.

The new default site avatar will be available into the BuddyPress 7.0.0-beta2 release we plan to publish next Wednesday, we strongly encourage you to test it as well as all the 7.0.0 new features 🙏.

#7-0-0, #8179, #site-tracking

Assigning multiple Member Types to a user

Starting in BuddyPress 7.0.0, community administrators will be able to assign more than one member type directly from the user’s WP-Admin/Extended profile page.

The regular select box of the Member Type metabox has been replaced by a multiple select box so that you can assign as many member types as you need to a single user.

Be aware of a change we made to the Member Types bulk actions behavior.

Community Administrators can bulk assign a member type to a list of users from the corresponding Administration screen by:

  1. activating the corresponding checkboxes at the left of users avatars.
  2. selecting the Member Type name from the Member Types dropdown list that is located over or under the users table.
  3. clicking on the change button immediately at the right of this dropdown list.

This strictly means you are changing the existing member type(s) of a user to the selected member type. In other words, if the user nicknamed imath was selected, he would be reassigned to the Lead Developer member type only (and lose the Pizza lover one 🍕).

If you choose the “No Member Type” option, then all the assigned member types of the selected user(s) will be removed.

If you want to read about how this change was made and thank the contributors who made it happen, head over this trac ticket.

By the way, did you know you’ll be able to create, edit, delete Member & Group Types directly from your WordPress Administration in BuddyPress 7.0.0 ?

#7-0-0, #member-types

The last_activity user metadata is not mirrored by default anymore as of BuddyPress 7.0.0

Hi BuddyPress Plugin/Theme developers,

Since BuddyPress 2.0.0, the primary storage location for the user last_activity information is the activity DB table. For backward compatibility reasons, we used to mirror that data into the usermeta DB table.

This means you could get the last date the user was active on the community site in 2 ways:

  • The right one using the bp_get_user_last_activity( $user_id ) function.
  • The deprecated one using bp_get_user_meta( $user_id, 'last_activity', false ) function.

Please note, starting in BuddyPress 7.0.0, we will stop mirroring the last_activity user metadata, meaning the only way to get the last date the user was active is by using bp_get_user_last_activity( $user_id ).

If your development absolutely needs this piece of information to also be available into the usermeta DB table, then you’ll need to use the following filter to keep it there:

add_filter( 'bp_use_legacy_user_query', '__return_true' );

To read more about this change, see #7882.

#7-0-0, #developers

Here are the 3 new BP Blocks to expect from BuddyPress 7.0.0 🎁 🎁 🎁

The BuddyPress blocks
New BP Blocks arriving in BuddyPress 7.0.0

1. Activity Embed

The Activity Embed block let authors embed an activity into their post or page. It’s very similar to the WordPress Embed block except that it is specific to BuddyPress Activities. Copy the permalink to the Activity single view page, add the Embed an activity block to your post or page, paste the activity link into the placeholder’s input and click on the “Embed” button to have it rendered.

Once rendered, you can adjust its alignment and include a caption under the embedded activity.

2. BP Members Block

Use this BP Block to select community members you want to feature into a post or a page. It’s a different approach than what we’re doing into our Members widgets. These are sorting members rather than allowing the author to pick the ones he’d like to include in his custom list.

It looks very similar to the BP Member block at first sight 😉. But as soon as you’ve added the first member, the Autocompleter control will still be available at the bottom of the block. Use it to add as many members as you need.

From the block’s settings you can choose whether to display the user names, mention names, the full/thumb version of profile photos or no photo at all.

Grid display

From the block’s toolbar you can select the display mode to use : List or Grid. If you chose the grid one, you’ll be able to customize the number of columns to use for this grid from the block’s settings. You can also choose to add extra BuddyPress information about the displayed members. For this grid display, only the information about the last time members were active is available.

List display

When you select the List display, you can include the latest activity the members posted 🏄🏻‍♀️.

If you need to remove a member from the list, Simply click on the x button at the right of the member’s line or cell.

3. BP Groups Block

Use this BP Block to select the groups you want to feature into a post or a page. It’s a different approach than what we’re doing into our Groups widget. Instead of sorting groups according to the date they were created, to the last time they were active, to their amount of members or alphabetically, authors can pick the ones they’d like to include in their custom list.

Just like the BP Members block, once you’ve added your first group, the Autocompleter control will still be available at the bottom of the block to let you choose as many groups as you wish.

Using the block’s toolbar you can select whether to display the groups in a list or in a grid. If you chose the Grid display, you’ll be able to define the number of columns to use from the block’s settings.

Still from these block’s settings, you can show or hide the group names, decide to use the full or the thumb version of the group profiles photo and include some extra information about the Group.

The List display lets you select any of the available extra pieces of information :

  • the group descriptions,
  • or the last time the groups were active,
  • or the amount of group members.

When the grid mode is active, only the two last pieces of extra information will be available.

Finally, if you need to remove a group from the list, Simply click on the x button at the right of the group’s line or cell.

BuddyPress 7.0.0-beta1 is scheduled for tomorrow, please do test it to help us buil a wonderful 7.0.0 stable release 🤝

#7-0-0, #blocks

WP CLI BuddyPress – 2.0

BuddyPress 7.0 will come with several updates for the 2.0 version of the wp-cli-buddypress package.

For those of us living in the command line, it is important to have a tool to facilitate tasks that would require several clicks, tabs, and time. That’s the beauty of WP-CLI, you can perform those tiresome tasks from the command line without much hassle.

Taking advantage of this technology, the Buddypress team created a CLI package to perform those tasks. The 1.0.0 version was launched in 2014 and since then, a lot of changes were made to make it better and more stable.

Since we lauched the 2.0 version a few weeks ago, I’d like to share a few things that were changed, improved, and fixed.

New Commands

We are introducing a few more commands to the package that might be helpful. Mainly:

wp bp group meta

The group meta command can be used to manage BuddyPress Group Meta (custom fields). Here a few commands that can be used to manage the meta information from a group:

$ wp bp group meta
usage: wp bp group meta add <id> <key> [<value>] [--format=<format>]
   or: wp bp group meta delete <id> [<key>] [<value>] [--all]
   or: wp bp group meta get <id> <key> [--format=<format>]
   or: wp bp group meta list <id> [--keys=<keys>] [--fields=<fields>] [--format=<format>] [--orderby=<fields>] [--order=<order>]
   or: wp bp group meta patch <action> <id> <key> <key-path>... [<value>] [--format=<format>]
   or: wp bp group meta pluck <id> <key> <key-path>... [--format=<format>]
   or: wp bp group meta update <id> <key> [<value>] [--format=<format>]

wp bp activity meta

Just like the wp bp group meta command, the activity meta command can be used to manage BuddyPress Activity Meta (custom fields).

wp bp tool signup

This command can be used to activate or deactivate the BuddyPress signup feature.

$ wp bp tool signup 1

wp bp scaffold tests

This command can be used to create BuddyPress specific testing code for plugins. It is targeted at BuddyPress plugin authors that need to set up BuddyPress specific unit tests.

Package Improvements

We made some major internal changes. The big one was removing our legacy Behat set up. We opted to use the WP-CLI composer package: wp-cli/wp-cli-tests.

This was an important change since we don’t need to manage that ourselves, also outsourcing that job to that package, we can benefit from changes and improvements made there. This package is also used in several, if not all, WP-CLI core packages.

Contributions will be much easier now since they won’t need to understand our previous custom set up.

Other Improvements

Besides those new commands and major internal changes, we took the time to improve the code base for reliability:

  • we bumped the PHP version from PHP 5.4 into PHP 5.6.
  • we made sure all Behat tests were passing correctly, fixing bugs where we found them.
  • we improved the readme documentation to better explain a few commands.
  • we forced the creation of the signups table when using the wp bp signup command. This was important in cases where the table was not present and would cause the CLI to fail.
  • we also updated the commands to return proper success/error messages when using tge parent::_delete or parent::_update helper methods.
  • we improved the commands PHPDocs: very useful when using the help param to find out what a command does.
  • we updated to fetch values from PHPDoc instead of PHP.
  • updated or removed the default values from several commands (most of them were wrong, lol).

And several other minor changes to improve the codebase and make sure the commands would run smoothly.

#7-0-0, #wp-cli

BP Template Packs: expect changes to the Activity comment form in version 7.0.0

Hi BuddyPress Template Pack “overriders” 🔩

Here’s an important information for you: get ready to update a possible template override you’ve added to your active theme. We’ve just fixed an issue to avoid duplicate IDs into the nonce field we generate within the comment form (see #8004 for more information).

You are using the BP Nouveau template pack

Please check if your theme contains an activity/comment-form.php template. If so, make sure the second argument of the bp_nouveau_submit_button() function is bp_get_activity_id().

You are using the BP Legacy template pack

Please check if your theme contains an activity/entry.php template. If so, make sure the second argument of the wp_nonce_field() function is:

'_wpnonce_new_activity_comment_' . bp_get_activity_id()

BuddyPress 7.0.0 release schedule

  • 7.0.0-beta1: October 15
  • 7.0.0 : December 1st

Thanks in advance for your help in making sure BuddyPress users will enjoy this improvement 😍

#7-0-0

Administration screens to manage Group and Member types are arriving 🙌

Hi !

Member types were introduced in version 2.2 and Group Types arrived in 2.6. These two BP types let BuddyPress developers and advanced users organize the members and the groups of their community site in smaller populations according to something they have in common. The site of an open source project could use Member types to inform about who is a maintainer, a committer, a lead etc.

So far BuddyPress types registration was only happening using code within a plugin, a must use plugin, a theme or a bp-custom.php file.

WP Dashboard

In BuddyPress 7.0.0 site administrators will be able to add, edit or delete Member and Group types using their WordPress Administration Screens just like they would do for Post tags.

The member type administration screens are available from a “Users” submenu and the Group ones from a “Groups” submenu as shown into the above screen capture.

Adding a type

Updating a type

Deleting a type

Some types cannot be deleted?

Types registered using code can only be edited. To delete such a type, you’ll need to deactivate the Plugin/Theme or remove the custom code generating the BP Type first.

PS: all above screen captures are showing Member type Administration Screens. Group type ones are very similar. The only differences are the available fields to customize the type behavior.

Want to play ahead with these Administration Screens?

You can test them from our development version. If you find some bugs or possible improvements, don’t hesitate to contribute to this feature. Tickets and patches are very welcome.

Interested about the feature’s development story?

  • You can read the Member Type’s Admin UI story from this ticket #7181.
  • You can read the Group Type’s Admin UI story from this ticket #7179.

👋

#7-0-0, #group-types, #member-types

WordPress required version update

Hi !

Please note that BuddyPress 7.0.0 will require WordPress >= 4.9.

To learn more about this change: https://buddypress.trac.wordpress.org/ticket/8318

To learn more about how we decide to bump our WordPress required version: https://codex.buddypress.org/getting-started/wordpress-version-compatibility/

#7-0-0, #wp-requirements