I’ve just released version 1.5.5 of BuddyPress in the wordpress.org repository. BP 1.5.5 is a security and maintenance release. Read more about it at the buddypress.org blog http://buddypress.org/2012/03/buddypress-1-5-5/ or on the Codex http://codex.buddypress.org/releases/version-1-5-5/

Several weeks ago, a series of changesets addressed what is perhaps the most popular request in the history of BuddyPress: profile privacy. (See #3695.) We’re calling it “visibility”, and you can check it out now in BP trunk. Here’s what developers need to know:

Profile Edit view

• Users can edit their profile field visibility on a field-by-field basis.
• Options available by default under “Who can see this field?” are Anyone, Logged In Users, and My Friends.
• Site administrators can select a default visibility level for each field. Admins can also force a field to maintain the default visibility – for instance, an admin may decide that a field called “Phone Number” should always be limited to Friends. (See the new bp_xprofile_map_meta_caps(), and the bp_xprofile_change_field_visibility cap.)
• Developers can customize the available options using two new filters:
  • bp_xprofile_get_privacy_levels – Register or deregister new privacy levels with this filter. The data being filtered here is an array that looks like this:

    
    array(
      'public' => array(
        'id' => 'public' // Canonical, non-translatable name
        'label' => __( 'Anyone', 'buddypress' ) // Label visible to users
      ), // etc
    )

    Add or remove items as you see fit.

  • bp_xprofile_get_hidden_fields_for_user – This is an array of xprofile field ids that should *not* be visible for the current viewer of the current displayed profile.

  In the upcoming weeks, I’ll write a short example plugin to demonstrate how to remove existing levels and add custom levels.

• While the visibility filtering does not happen at the template level itself, the markup that allows users to modify profile visibility does require theme-level changes. The two key files are: /members/single/profile/edit.php (see the block beginning if ( bp_current_user_can( 'bp_xprofile_change_field_visibility' ) )) and /registration/register.php. In each case, you should be able to simply copy and paste the relevant blocks from bp-default; if you need to support older versions of BP, you may want to wrap it in a if ( function_exists( 'bp_xprofile_get_privacy_levels' ) ) check.

  Note that if your theme does not provide the proper markup for users to customize their profile field visibility, fields will default to the admin-provided visibility level, which itself defaults to Public. Thus, the feature degrades gracefully in the absence of theme support.

Questions or comments? Leave them below, or in a relevant Trac ticket.

BP 1.5.3 is available, with some fixes for better WP 3.3.x compatibility. Read http://buddypress.org/2012/01/buddypress-1-5-3/ for more details.

Several recent changes in the BuddyPress trunk have added better cache support for group meta (r5460) and activity meta (r5505). In brief, these changesets make it so that every time you call up groups or activity (as in, for example, bp_has_groups() or bp_has_activities()), BuddyPress will automatically fetch all of the metadata for those items and add it to the WordPress object cache. The net effect of these changes is that, inside of the group and activity loops, the performance of groups_get_groupmeta() and bp_activity_get_meta() is radically improved, since individual database queries are no longer required. (This behavior is modeled on how WordPress handles postmeta after a posts query – our new bp_update_meta_cache() is based on WP’s update_meta_cache().)

For the most part, plugin authors do not need to do anything to take advantage of these new features. However, in order to make bp_update_meta_cache() as flexible as possible, the format of the keys used to cache activity meta has changed. It used to be of the form:

'bp_activity_meta_' . $meta_key . '_' . $activity_id

but is now of the form

'bp_activity_meta_' . $activity_id . '_' . $meta_key

to better match other components. As a result, your activity meta cache will be flushed when you upgrade to BP 1.6. And if you made any manual references to the activity meta cache in your own plugin, you’ll need to change those references. (If you used bp_activity_update_meta() and bp_activity_get_meta(), you don’t need to do anything.) This should affect very, very few (if any) BP customizations.

BP 1.5.1 was just released. Check out the blog post, the changelog, and the Trac milestone.

Thanks to all contributors for your hard work!

A new version of the BuddyPress Skeleton Component, complete with rich documentation on how to use the new BP_Component class, is now available. Read more about it.

If you’ve used the BP Template Pack to make your WP themes BP-compatible, you’ll be happy to know that BP Template Pack 1.2 is fully compatible with BP 1.5. Check out the announcement post here.

If your plugin or theme manually manipulates the navigation tabs in individual groups, either through the use of functions like bp_core_new_subnav_item() and bp_core_remove_subnav_item() or through the direct manipulation of $bp->bp_options_nav, you’ll want to know about some changes in BP 1.5.

Due to an oversight long ago, in BP 1.2.x, the key ‘groups’ (or, more precisely, $bp->groups->slug) was used to store two totally different nav items in $bp->bp_options_nav: the ‘Groups’ item on a user’s profile, and the main navigation of an individual group (Admin, Forums, Members, etc), an overlap that caused incorrect navigation to be rendered in some cases. In BP 1.5, this inconsistency has been rectified by moving individual group navigation items from $bp->bp_options_nav['groups'] to a new array position, keyed by the group slug. So if your group has the slug boone-for-president, the navigation for the Boone For President group will be stored at $bp->bp_options_nav['boone-for-president']

What does this mean for you? If you use the BP_Group_Extension class – which is true for the vast majority of plugins that create group navigation – you will not be affected (because the BP_Group_Extension class builds navigation for you, and takes this change into account). You may be affected if, like Jonnyauk was attempting to do, you’re using bp_core_remove_nav_item() to take stuff out of the group nav, like this:

function bbg_remove_send_invites_from_group() {
	global $bp;
	bp_core_remove_nav_item( $bp->groups->slug, 'send-invites' );
}
add_action( 'bp_setup_nav', 'bbg_remove_send_invites_from_group' );

which won’t work anymore. Do this instead:

function bbg_remove_send_invites_from_group() {
	bp_core_remove_nav_item( bp_get_current_group_slug(), 'send-invites' );
}
add_action( 'bp_setup_nav', 'bbg_remove_send_invites_from_group' );

Navigation for profiles, and elsewhere in BuddyPress, has not changed; the advice above is only relevant for groups (or custom components that have single items – Achievements comes to mind, meaning that if you are manually manipulating the single-Achievement subnav, you’ll need to make similar modifications.)

There was a quirk in the way that BuddyPress 1.2.x’s Blogs component recorded posts and comments in the activity stream. With you published a new post, it only got published in the activity stream if $post->post_type == 'post'. In other words, Pages and all custom post types were ignored. On the other hand, no such post_type check took place in the case of comments, with the result that comments on pages and other post types did show up in the stream.

This odd inconsistency was fixed in the BuddyPress trunk with changeset 4959; BuddyPress now checks to make sure that the item being commenting on is a WordPress ‘post’ before adding the comment to the activity stream. However, anointed chimed in to let us know that some BuddyPress admins were taking advantage of the quirk. The result of this discussion is r4971, in which the post type checks are enhanced by turning them into checks against a filterable whitelist.

Plugin authors should be aware of this changed default behavior. If your plugin creates custom post types, and if you want comments on those custom post types to be recorded in the BP activity stream by bp_blogs_record_comment() (if you are using your own function for this purpose, you don’t need to worry about the change), you will have to update your plugin to do something like this:

  function bbg_record_my_custom_post_type_comments( $post_types ) {
      $post_types[] = 'dolphin'; // Add your custom post type name to the array. If you have a post type called 'dolphin' then you have a weird plugin
      return $post_types;
  }
  add_filter( 'bp_blogs_record_comment_post_types', 'bbg_record_my_custom_post_type_comments' );

In a few of the previous posts in the 1.5 plugin update series, I’ve talked about maintaining backward compatibility with earlier versions of BP while upgrading your plugins for BP 1.5. In those posts, I suggest the function_exists() method, which will always work nicely.

However, there’s another method you might want to consider: update your plugin as if you weren’t going to support earlier versions of BP, and then conditionally include an abstraction file that defines the necessary functions. Here’s what I mean.

When I was upgrading BuddyPress Group Email Subscription for BP 1.5, I wanted to make use of a few BP 1.5-only functions: namely, bp_is_groups_component() and bp_is_group(). So I did. Then, I created a new file called 1.5-abstraction.php, which looks like this. You’ll notice that I haven’t copied the functions directly over from the 1.5 source. The main reason for this (especially in the case of bp_is_groups_component()) is that the original function references bp_is_current_component(), which in turn has a bunch of complicated logic that is not necessary in my case. So, in my case, it made sense to take a minute to write less general functions from scratch. However, I could just as easily have copied these two functions directly into my abstraction file.

Then, I loaded the 1.5-abstraction.php file conditionally, like so:

if ( defined( 'BP_VERSION' ) && version_compare( BP_VERSION, '1.5-beta-1', '<' ) ) {
	require_once( dirname( __FILE__ ) . '/1.5-abstraction.php' );
}

In this way, I only load the file when necessary.

The nice thing about this method is that my main codebase remains clean and easy to read. When I decide to drop backward compatibility for early versions of BP, this file can simply be removed from the package.

Another great thing about these abstraction files is that we can share them. Feel free to copy the small one from BP Group Email Subscritpion into your own plugin and build upon it – and share your own version with other developers.