Welcome to the first BuddyPress Blocks

Hi BuddyPress contributors,

We’re very excited to share with you this announcement: after 5 months working from a separate GitHub repository on BuddyPress blocks, the 2 first and a BP Block API have been merged into BuddyPress Core. If you checkout our development version using our SVN repository or clone its Git read-only mirror, you will be able to early play with them.

One of the top features of the 6.0.0 release

These 2 BP blocks will be widely spread to our community thanks to our next major release. Some of us will be able to contribute to their fine tuning thanks to the first beta of this release which should be available in the coming days (Everyone is very welcome to do so !!).

Although BuddyPress is compatible with WordPress back to the 4.8 version, please note that you will need WordPress 5.0 to enjoy BP Blocks. If you wish to contribute using our development version (SVN or Git), you will need to install and activate the BP REST plugin (we are using it to develop the BP REST API). If you can wait until BuddyPress 6.0.0-beta1 and all the following releases, the BP REST API (just like it’s the case in the 5.0 releases) will be included so you won’t need the BP REST plugin.

About inserting BP Blocks into your posts or pages.

In 5.0.0, we’ve introduced a specific category for BuddyPress blocks into the WordPress Block Editor. This category is only appearing if there is at least one block attached to it and if you’re writing a post or a page. So most of you should haven’t noticed this category within the Block Inserter so far. Here’s what you will see once BuddyPress 6.0.0 will be released.

You just need to click on the block of your choice from the BuddyPress category of the inserter or you can also use the “/” autocompleter to add one of these blocks to your content.

Featuring a member of your community site.

That’s the goal of the BP Member block. Once added, you’ll need to start typing the name of your member from the autocomplete control to select the one you want to feature in your post or page.

By default, the block uses all the display options available. You can customize them from its settings panel.

Featuring a group of your community site.

The BP Group block is behaving just like the BP Member block. This time start typing the name of the group you wish to feature to view how it will be displayed into your content.

You will be able to adjust the appearance of the block using its settings panel.

Advanced customizations.

Post type customizations

If you wish to make the BuddyPress Block category available to a specific custom post type or restrict the post types which can use BP Blocks, you can use this filter: bp_block_category_post_types. The example below shows you how to restrict the category to posts only.

 * Filters the supported post types for the BuddyPress blocks category.
 * @since 1.0.0
 * @param array $value The list of supported post types.
function vingt_vingt_restrict_bp_blocks_to_posts( $post_types = array() ) {
    return array( 'post' );
add_filter( 'bp_block_category_post_types', 'vingt_vingt_restrict_bp_blocks_to_posts', 10, 1 );

Block output customizations

You can completely override the output of the BP Member and the BP Group blocks using the following filters:

Blocksfilter nameparameters
Memberbp_members_render_member_block_output1. string $output the HTML output ;

2. array $params An associative array containing these keys:
* integer $params['itemID']: the user ID ;
* string $params['avatarSize']: ‘full’ or ‘thumb’ ;
* boolean $params['displayMentionSlug']: true to display the @mention name, false otherwise ;
* boolean $params['displayActionButton']: True to display the action button, false otherwise ;
* boolean $params['displayCoverImage']: True to display the cover image, false otherwise ;
* string $params['username']: User’s username ;
* string $params['display_name']: User’s display name ;
* string $params['member_link']: User’s profile URL ;
* string $params['avatar']: User’s avatar URL ;
* string $params['cover_image']: User’s cover image URL ;
Groupbp_groups_render_group_block_output1. string $output the HTML output ;

2. BP_Groups_Group $group the group object ;

3. array $params An associative array containing these keys:
* integer $params['itemID']: the group ID ;
* string $params['avatarSize']: ‘full’ or ‘thumb’ ;
* boolean $params['displayDescription']: true to display the group description, false otherwise ;
* boolean $params['displayActionButton']: True to display the action button, false otherwise ;
* boolean $params['displayCoverImage']: True to display the cover image, false otherwise ;
* string $params['group_name']: Group’s name ;
* string $params['group_description']: Group’s description ;
* string $params['group_link']: Group’s home URL ;
* string $params['avatar']: User’s avatar URL ;
* string $params['cover_image']: User’s cover image URL ;

Disabling one or more component’s block(s)

You can disable a specific or all component’s blocks using the dynamic filter "bp_{component_id}_register_blocks". Here’s how you can disable all the Groups component blocks.

add_filter( 'bp_groups_register_blocks', '__return_empty_array' );

So far there’s only one block for this component, but we will add more in next releases! So if you want to disable a specific component’s block, here’s how you can do.

 * Filters the Groups Blocks to disable the BP Group Block one.
 * @since 1.0.0
 * @param array $blocks The list of BP Blocks for the component.
 * @return array        The list of BP Blocks for the component.
function vingt_vingt_disable_bp_group_blocks( $blocks = array() ) {
	// Use the block's ID to disable it.
	unset( $blocks['bp/group'] );

	return $blocks;
add_filter( 'bp_groups_register_blocks', 'vingt_vingt_disable_bp_group_blocks', 10, 1 );

Using a custom stylesheet for a BP Block

If you need to adapt the blocks appearance to match your active theme’s one, you can use the same dynamic filter ("bp_{component_id}_register_blocks") to override the style_url property to use a different CSS file. For example, here’s how you can do for the BP Member block.

 * Filters the Members Blocks to override the style the BP Member one.
 * @since 1.0.0
 * @param array $blocks The list of BP Blocks for the component.
 * @return array        The list of BP Blocks for the component.
function vingt_vingt_bp_member_block_custom_style( $blocks = array() ) {
	$blocks['bp/member']['style_url'] = get_theme_file_uri( 'css/member.css' );

	return $blocks;
add_filter( 'bp_members_register_blocks', 'vingt_vingt_bp_member_block_custom_style', 10, 1 );

What’s the BP Block API you’re talking about into the first lines of this post?

We will soon write a documentation page about it into our Codex. In a few words, we are using a specific function bp_register_block() that extends the WordPress one (register_block_type()) so that scripts, styles & translations registration is automagically handled.

About the next blocks?

Let’s build them together! You’re very welcome to contribute to the GitHub repository we are using to create the future of BuddyPress blocks.


The profile photo & cover image features belong to Members

Since the very first version of BuddyPress, the local avatar management feature was depending on the xProfile component. During the 2.1 development cycle we’ve renamed this feature “Profile Photo”. The cover image feature was introduced in BuddyPress 2.4 and, just like the Profile Photo feature one, it needed the xProfile component to be active to be able to enjoy it. In BuddyPress 6.0.0, we are introducing a major change about these 2 features: they will belong to the Members component.

This decision is the result of a Slack Discussion the team had about the subject just after we brought the first version of the BuddyPress REST API into BuddyPress Core. We’ve been working on it from this Trac ticket and yesterday the changes landed in Trunk.

What does it change for end users ?

When the xProfile component is active not much! They will only see that the settings to disable profile photo and cover image uploads are now available from a new Members settings section.

When the xProfile component is not active, BuddyPress used to fill the blank with a single member screen to show some information about the user’s WordPress profile (display name, website, biographical info and potentially some contact methods). As you can see below this lonely screen will have 2 new neighbours in BuddyPress 6.0.0*.

* If profile photo and cover image uploads are allowed by the site owner.

Logged in users will be able to edit/delete their profile photo and cover image from their self profile area, even if the xProfile component is not active.

Within the WordPress extended profile administration screen, Administrators will be able to edit the Profile Photo of the displayed user, even if the xProfile component is not active.

What does it change for BuddyPress plugin and theme developers?

If their WP_DEBUG constant is set to false, we believe nothing more than what we’ve described so far. Otherwise there are good chances their screens will be full of deprecation notices!! As a result we’re asking plugin and theme developers to start testing BuddyPress very early to make sure their master pieces will be ready before 6.0.0 release (scheduled for end of April). You can do it by cloning one of our Git mirrors or by checking out our SVN development repository:

svn co https://buddypress.svn.wordpress.org/trunk/

git clone git://buddypress.git.wordpress.org/

# OR
git clone https://github.com/buddypress/buddypress.git

To help you, here are the deprecated functions and hooks in 6.0.0 about the profile photo and cover image features.

Deprecated in 6.0.0Replacement in 6.0.0Type

Let’s use the time we have left before the 6.0.0 release to make sure we haven’t forgot anything: please test your plugins and themes against Trunk, update them as needed and let us know asap if you need more help / BP Core code changes to take these evolutions in account.

BuddyPress Contributors, let’s update the Codex!

We still need to update our documentation about these changes. Here are the first Codex pages needing updates I’ve identified:

Thanks in advance for your help in making this change as smooth as possible for our end users 😍.


BuddyPress 6.0.0 will require at least PHP 5.6

Hi everyone,

Please note we’ve just raised our PHP minimal required version to 5.6. Of course, we are supporting PHP versions up to WordPress requirements.

According to these stats PHP 5.3 is now used by less than 3 % of WordPress installs.



WordPress required version update

Hi !

Please note that BuddyPress 6.0.0 will require WordPress >= 4.8.

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

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