BuddyPress 6.4.0 has been released yesterday, as we’ve been discussing during the development meeting, it includes fixes to PHP 8.0 deprecated notices for BP Core & BP REST. It also includes a security fix. Read more about this release.
@vapvarun has been working on the release note, the remaining things to write is the changelog. @johnjamesjacoby removed the link to the BP Survey on our official site, @im4th needs to write a post about the results and publish it on BuddyPress.org asap.
7.0.0 first release candidate
We’ve spent the rest of the meeting working on getting the 7.0.0-RC1release ready:
Finally we decided to include the feature to list the displayed Member’s Member Types into their profile header (#8394) as the poll @im4th made on Twitter got 83% votes for 🙌.
Hello #BuddyPress contributors, what do you think of this last minute improvement I think we should bring to next BP release (7.0.0) ? 👇https://t.co/xUlWyiUcYt
7.0.0-RC1 has been released 2 days late (November 20) according to the initial schedule. It’s an important step, BuddyPress plugin/theme authors should really test their piece of work against it so that our users can fully enjoy 7.0.0. If you find a bug, please open a ticket to report it on our Trac environment or use this support topic.
RC1 also marks the string freeze point of the 7.0.0 release schedule. So we will not add/edit or delete i18n strings until 7.0.0 is released. Just like what we did for 6.0.0, we will credit people who contributed to translating BuddyPress into as many languages as possible. Don’t hesitate to join the effort!
Here’s 7.0.0 (development column on GlotPress) translation tops so far:
It will happen on December 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!
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.
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:
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”.
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.
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:
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:
total_member_count: the count of all Group members,
last_activity: the date the Group was last active,
last_activity_diff: the human diff time the Group was last active.
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:
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.
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:
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.
@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.
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!
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 🙏.