New xProfile Field Type – Checkbox Acceptance will be introduced in BuddyPress 8.0.0

The BuddyPress xProfile component gives you the power to create as many profile fields as you wish quickly and to organize these fields into groups of fields. An important step when creating a new profile field is to select the Field Type that best suits your need to display the information.

The Checkbox Acceptance field type is a new type of field we will introduce into our next major release (8.0.0). Thanks to it you’ll be able to easily create a new field to manage the Terms of Service of your site (which is often mandatory nowadays to follow compliance) or any other acceptance page (eg: code of conduct, good behavior rules, etc…). As it’s a profile field, it’s very easy to include it into your registration form to be sure to have your new members to agree to your linked acceptance page.

Adding a new field using the Checkbox Acceptance type.

When you’ll create a new xProfile field once you upgraded to BuddyPress 8.0.0, you will find a new field type option – Checkbox Acceptance.

Checkbox Acceptance field option

After selecting the Acceptance field, you can map your terms of service page to field options and include it into your registration form using the checkbox of the new Signup metabox (also introduced in 8.0.0).

Select your Terms of Service page to Checkbox Acceptance field

Save your profile field, and log out to preview the result on your registration page.

Checkbox Acceptance field view at register page.

It will be visible as in the above screenshot, mapped terms & condition page link on the register page with checkbox. Of course, new users will be able to click on the “Terms and conditions” link to aknowledge it.

Checkbox Acceptance field view for existing users.

Existing members can also agree to your acceptance page. Tell them to log in and visit their edit profile screen to submit their Acceptance from there. Once submitted, it will be a read-only field; members can not uncheck the value for the Acceptance field.

The acceptance field will only be visible to the logged-in member (viewing their self profile) and the admin. It will not be visible to members visiting any other one’s profile.

Checkbox Acceptance field view at own profile

Watch the demo!

The video below will show you how to create a new Acceptance field

Please read the full story about this new xProfile field type, head over to this ticket on our Trac environment.

#8-0-0, #xprofile

Bye-bye BuddyBar, you did great!

I have the great honor to announce you all, the BuddyBar that was with us since BuddyPress 1.0.0 (@apeatling gave it birth on September 9, 2009) has been completely removed from our source code on April 29, 2021, 12.854 commits later!

Screenshot of the BuddyBar
Screenshot of the BuddyBar into BuddyPress 1.0.3

Its menus has been transposed into the WP Admin Bar which firstly appeared in WordPress 3.1. It was possible to turn off the WP Admin Bar in favor of the BuddyBar for a while even when we deprecated it in BuddyPress 2.1. We were thinking about completely removing it since version 3.0, but we regularly delayed its disappearance. I can understand it was a difficult move to do 😉. Yesterday, I took my courage in both hands and made this hard move.

To honor its memory and to remember my early times with BuddyPress, I’ve installed the 1.0.3 version of BuddyPress on a WordPress µ (version 2.8.1) configuration earlier today. The least we can say is: it looked really great in our first default theme!

The BuddyPress member’s page, 12 years ago!

Thanks a lot BuddyBar, you did a great job and I won’t forget you 💪 😘

#8-0-0, #buddybar

2 new xProfile Field types will be introduced in BuddyPress 8.0.0

The BuddyPress xProfile component gives you the power to easily create as many profile fields as you wish and to organize these fields into groups of fields. So far there was only one field which was linked to an existing WordPress user field : the base Name field. This field’s data is synchronized with the WordPress user display name (unless you opt out this synchronization from the BuddyPress Options Administration screen).

WP xProfile field types are arriving!

In BuddyPress 8.0.0, you’ll have the extra power to include other WordPress fields into the xProfile groups of fields. This time, unlike what we’re doing for the Name field, we are not duplicating and synchronizing field values between the WordPress user field tables (the wp_users & the wp_usermeta ones) and the BuddyPress xProfile data table). Instead we are directly using the WordPress user field values.

Creating these new field types, we’ve also improved our xProfile field API so that you can now have more control about the features your custom type of field can support.

/**
 * Custom xProfile field type.
 */
class Custom_XProfile_Field_Type extends BP_XProfile_Field_Type {

	/**
	 * This property enforces Field's default visibility.
	 */
	public $visibility = 'public';

	/**
	 * Supported features for the WordPress field type.
	 */
	public static $supported_features = array(
		'required'                => false,
		'do_autolink'             => false,
		'allow_custom_visibility' => false,
		'member_types'            => false,
	);
}

Using the static $supported_features property, you can disable the corresponding features meta boxes from the xProfile Administration Screen. The above example is showing the supported features by the WordPress fields : as defined by WordPress, these fields cannot be made required, cannot have their visibility changed for something different than public and cannot be restricted to a member type. Below are the values used by default for any xProfile field type.

A regular xProfile field can be made required, can be restricted to a specific member type, can be set to let members define the field data visibility and can be auto linked to a members search request about the field value.

1. wp-biography

The first type is specially designed to let you include the biographical information of the user into the group of xProfile fields of your choice.

2. wp-textbox

Using this type of field, you can insert the first name, the last name, the website URL and the potential WordPress User Contact Methods you added. Once you created your wp-textbox field, you’ll just need to use the advanced meta box below the field’s description textarea to select the information to include into the group of fields of your choice.

Watch the demo!

The video below will show you how to create a new field to add/edit the Member’s website URL and the Biographical information directly from their front-end profile.

If you want to read the full story about these new xProfile field types, head over to this ticket on our Trac environment.

#8-0-0, #wordpress, #xprofile

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