BuddyPress 7.0.0 Release Candidate

The first release candidate of BuddyPress 7.0.0 is ready for your testing!

Thanks in advance for your contributions 😍

#7-0-0, #rc, #release

BP Dev Chat Agenda November 18, 2020.

Hi BuddyPress contributors!

Please join the #BuddyPress developers meeting that will happen on November 18 at 19:00 UTC (tomorrow), we’ll have 1 hour to talk about:

  • 6.4.0 « PHP 8.0 » compatibility release
  • 7.0.0 release tasks progress
  • 7.0.0 first release candidate (scheduled after the meeting 😱🍕)
  • Open floor (if we have some time left!)

Thanks in advance for your time 😍.

#7-0-0, #agenda, #dev-chat

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

BuddyPress 7.0.0-beta2

Hi everyone!

BuddyPress 7.0.0-beta2 is ready for your testing, thanks in advance for your help 🍕 😍

https://buddypress.org/2020/11/buddypress-7-0-0-beta2/

#7-0-0, #beta, #release

BP Dev-Chat Summary: November 4, 2020

7.0.0 latest updates

@im4th started the meeting sharing that the ticket (#8179) about the default Blog avatar has been committed and that a developer note has been published on this site. @vapvarun suggested we should respect some consistency about the UI we use when setting a group’s types or a member’s types. A ticket (#8389) has since been reported and fixed: from now on the WP-Admin/Extended Profile’s member type metabox will use checkboxes.

@im4th has updated the BP REST API’s Blogs Endpoint so that it enjoys the improvement we brought about the default Blog avatar (#BP-REST-358). He said he had no time to update the BP REST API developers documentation, but as he felt pretty guilty about it, he worked on it lately and made good progress as only the Signups and Friends Endpoints need a documentation review.

@dcavins has been working on updating the list of Props from our Trac environment and @im4th worked on the list of Props from the BP REST plugin GitHub repository. A patch is ready about these updates (#8376). Here are our progress about 7.0.0 release tasks.

TasksOwnerProgress
BP REST API documentation updates@im4th90%
BP Survey results@im4th0%
7.0.0 Release note@vapvarun0%
7.0.0 Credits update:
– BuddyPress Trac
– BP REST GitHub repository

@dcavins
@im4th

100%
100%
7.0.0 Pizza Restaurant name@dcavins🤫
7.0.0 Announcement post@im4th0%

Last checks before releasing 7.0.0-beta2

We’ve decided to postpone the 7.0.0-beta2 release to tomorrow (November 11th, 2020). @im4th was concerned about a cache issue (#8388) that was reported lately about the xProfile component. @dcavins volunteered to work on it and has since contributed to 2 patches. Don’t hesitate to comment on the ticket to share with him your thoughts about our 2 possible ways to fix this issue. @vapvarun brought to our attention another issue (#8386) that was reported about the BP Nouveau Template pack. @im4th volunteered to work on it. It has been since fixed. @im4th also asked @vapvarun to test the patch attached to the ticket (#8384) about making sure Site Icons / Blog avatars synchronization is also happening when BuddyPress is not network activated on multisite configurations. He recently tested it and we will probably include it into the 7.0.0-beta2 release. Finally @johnjamesjacoby improved the new strings we introduced about the BP Types UI 🤝. We finally agreed on this new schedule for the 7.0.0 development cycle.

  • 7.0.0-Beta2: November 11.
  • 7.0.0-RC: November 18.
  • 7.0.0 final release: December 9.

Open floor

@vapvarun shared his enthusiasm about the promising download results of the BuddyX theme he recently submitted on the WordPress.org Themes Directory 🍕👏📈. As it’s a beautiful BuddyPress theme, @im4th asked him to work on a post to share his experience about the process he had to go through to have his theme hosted on the official Themes Directory. We will soon publish this post on BuddyPress.org 🎨 .

We also talked about the BuddyPress code reference, it’s still under construction but @vapvarun ran some tests about it lately so we might progress about it soon!

Next Dev-Chat

It will happen on November 18 at 19:00 UTC and of course in #BuddyPress. If you have ideas or questions, feel free (and we are strongly encouraging you) to comment this summary to share them!

#7-0-0, #dev-chat, #summary

BP Dev-Chat Agenda: November 4, 2020

Our next development meeting will happen this Wednesday November 4 at 19:00 UTC in #BuddyPress. Here’s our agenda:

  • 7.0.0 latest updates.
  • Last checks before releasing 7.0.0-beta2.
  • Open floor.

If you have anything you wish to add (or remove) to this agenda or specific items related to those listed above, please leave a comment below.

PS : 7.0.0-beta2 will be packaged just after the meeting.

#7-0-0, #agenda, #dev-chat

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

BP Dev-Chat Summary: October 21, 2020

7.0.0-beta1 feedbacks

7.0.0-beta1 was released on October 16. So far, nothing specific to it was posted into our support forums. At the time we had the meeting, @im4th, thanks to @IAmTheWebb tests, had reported an issue (now fixed) with the Activity Embed block into our Trac environment. This last Friday @k3690 reported a wrong usage of the member term into a Group Type meta property (now fixed).

7.0.0 remaining tickets

  • #8292 @vapvarun submitted a patch during the meeting 💪, @im4th reviewed it some time after, brought some minor improvements and it has been fixed yesterday. It’s now possible to assigned more than one member types to users from their WP Admin Extended Profile 🙌 .
  • About #8179, @im4th asked @vapvarun to update the ticket with 2 squared corner avatars with these dimensions: 150px x 150px (full) & 50px x 50px (thumb). @im4th will try to progress on a patch in the meantime.
  • We’ve postponed #8093 (Profile Field visibility improvements) to a next milestone.
  • #8375 was reopened by the reporter, as the filter we’ve added wasn’t matching its needs. @dcavins @johnjamesjacoby & @im4th have been discussing about it last week in #BuddyPress and came to the conclusion a possible better place to allow the invitation table’s name filtering was to include the {$bp_prefix}bp_invitations table name into the global_tables property of the BP_Members_Component object. @dcavins will investigate this week about that possible change.
  • Finally shortly after our meeting, @boonebgorges reported a new ticket about improving the xprofile_get_field() function so that it only pulls up the data for a field when necessary. The patch he suggested as a first step looks safe to @im4th who thinks it should be included into the 7.0.0 release: it’s always great to improve DB performance. Please have a look at #8378 and send him some feedbacks about your thoughts.

7.0.0 release schedule update

We are going to package a new 7.0.0-beta to include as much fixes as possible considering the previous chapter. Packaging will happen shortly after our next BP Dev-Chat.

  • 7.0.0-beta2: November 4th
  • 7.0.0-RC1: around November 18 (string freeze).
  • 7.0.0: December 1st 🎯

7.0.0 release tasks

The following list of tasks needs to be achieved before we package our next major release (7.0.0).

TasksOwner
BP REST API documentation updates@im4th
BP Survey results@im4th
7.0.0 Release note@vapvarun
7.0.0 Credits update:
– BuddyPress Trac
– BP REST GitHub repository

@dcavins
@im4th
7.0.0 Pizza Restaurant name@dcavins
7.0.0 Announcement post@im4th

NB: we’ll also need to add a patch to #8376 to update our “Hello BuddyPress” modal.

GitHub default branch naming for BuddyPress repositories

This point was moved to a future development meeting. @johnjamesjacoby shared his thoughts about it. Possibilities are main or trunk. FYI WordPress contributors decided to use trunk for repositories of the WordPress organization on August 19.

Open floor

@dcavins asked a question about using the new BuddyPress development environment: when making changes to the BuddyPress source code, he was wondering how is updated the running environment? In other words, do we need to run some specific commands to update it?

@im4th replied changes were automatically taken in account without doing anything more than saving the BuddyPress source code changes. @IAmTheWebb confirmed: “the folder you see outside docker is mapped to inside, so changes you make should appear automagically

Next Dev-Chat

It will happen on November 4 at 19:00 UTC and of course in #BuddyPress. If you have ideas or questions, feel free (and we are strongly encouraging you) to comment this summary to share them!

#7-0-0, #dev-chat, #summary

BP Dev-Chat Agenda: October 21, 2020

Our next development meeting will happen tomorrow on October 21 at 19:00 UTC in #BuddyPress. Here’s our agenda:

  • 7.0.0-beta1 feedbacks.
  • 7.0.0 release tasks (BP REST API documentation updates, BP Survey results, release note, credits, announcement post).
  • GitHub default branch naming for our repositories.
  • Open floor.

If you have anything you wish to add (or remove) to this agenda or specific items related to those listed above, please leave a comment below.

#7-0-0, #agenda, #dev-chat