Like this:

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.)

Like this:

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' );

Like this:

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.

Over the next few weeks, a series of posts will appear on this blog, featuring developer notes on upgrading your plugins and themes for BP 1.5. Follow the series at the 1.5 plugin update tag.

Like this:

In version 3.1, WordPress began enforcing a restriction against using is_page(), and other conditional functions that leverage $wp_query, before the init action. Prior to version 1.5, BuddyPress was one of the violators of this restriction – BP’s global- and navigation-setup routines, which required reference to $wp_query, were hooked to plugins_loaded, well before init. This transgression was corrected in r3742, where the main BP hooks (bp_setup_globals, bp_setup_nav, and the like) were switched from plugins_loaded to init. See #2609 for further discussion.

What does this mean for BuddyPress plugins and themes? The good news is that the change will be invisible and seamless for most. However, the change in load order does have some implications for functions like bp_core_remove_nav_item() and other functions that only work properly once the global- and navigation-setup routines are finished. That’s because, with the switch to init, your plugin files as well as your theme’s functions.php are now loaded before BP sets up its globals and nav.

In practical terms, BP 1.2.x erroneously allowed you to put the following line directly into a plugin file or functions.php, into the global scope:

bp_core_remove_subnav_item( 'activity', 'friends' );

This will no longer work. Modifications to BP navigation should be done inside of a function hooked to bp_setup_nav, with the priority of 10 or higher. So the previous code becomes:

function bbg_remove_activity_friends_subnav() {
    bp_core_remove_subnav_item( 'activity', 'friends' );
}
add_action( 'bp_setup_nav', 'bbg_remove_activity_friends_subnav', 15 );

Likewise, any modifications to the $bp global should be hooked to bp_setup_globals.

See #3438 for more discussion. Many thanks to sbrajesh for raising the issue.

Like this:

As I discussed in a recent post, BP 1.5′s slug setup is a bit different. To ensure full compatibility with all BP 1.5 setups (and specifically, those with hierarchical page structures – such as http://buddypress.org/community/groups), you’ll need to change the way you concatenate links.

The most straightfoward way to do this is by using BP 1.5′s new bp_get_x_root_slug() functions, eg
$group_admin_link = bp_get_root_domain() . bp_get_groups_root_slug() . '/' . $this_group_slug . '/admin';

However, using bp_get_groups_root_slug() means that your plugin will not work with earlier versions of BP, which will show a fatal ‘undefined function’ error. If you need to continue to support earlier versions of BP, you might want to think about assembling your links like this:

global $bp;
$group_slug = function_exists( 'bp_get_groups_root_slug' ) ? bp_get_groups_root_slug() : $bp->groups->slug;
$group_admin_link = bp_get_root_domain() . $group_slug . '/' . $this_group_slug . '/admin';


Similarly, the recommended way to check for the current component in BP 1.5 is to use the component-specific functions:

if ( bp_is_groups_component() ) { ...

or, for arbitrary components,

if ( bp_is_current_component( $component_slug_or_root_slug ) ) { ...

However, if you need to retain backward compatibility for the moment, try something like the following:

if ( ( function_exists( 'bp_is_groups_component' ) && bp_is_groups_component() ) || $bp->current_component == $bp->groups->slug ) { ...

I’ll probably be doing this myself with some of my more popular plugins, as a stopgap release until I feel more comfortable dropping backward compatibility with pre-1.5 installations of BuddyPress.