If you are writing a normal BuddyPress plugin — one that adds pages rather than replacing them — see this excellent article (and this one too) at the BuddyPress Codex for info on how to implement BP theme compatibility.

First idea: Replace the content from directory_content with the group tree.

BP_Groups_Theme_Compat::directory_content() is the native BP function that displays the group list page. It’s called as a hook to a filter called bp_replace_the_content, so the content should be available for further filtering after it runs.

 
/**
 * (BP 1.7+) Filter the theme-compatibility content for a group tree page
 */
function bp_group_hierarchy_inject_group_tree() {
        add_filter( 'bp_replace_the_content', 'bp_group_hierarchy_buffer_group_tree', 100 );
}
function bp_group_hierarchy_buffer_group_tree( $content ) {
 
        ob_start();
 
        $loop_template = apply_filters( 'bp_located_template', locate_template( array( "tree/index.php" ), false ), "tree/index.php" );
        load_template( $loop_template );
 
        $output = ob_get_clean();
        return $output;
}
 
// If admin says only show the group tree (and we are in theme compat), do it:
add_action( 'groups_directory_groups_setup', 'bp_group_hierarchy_inject_group_tree' );

Result: No dice. Directory content is echoed to the screen, not returned to the filter chain. The group tree appears below the flat group list.

Workaround / second idea: Unhook the directory_content function so it doesn’t echo.

Here’s a snippet that I threw together testing this out (warning: closure => PHP 5.3+ !):

/**
 * (BP 1.7+) Filter the theme-compatibility content for a group tree page
 */
function bp_group_hierarchy_inject_group_tree() {
 
        add_filter( 'bp_replace_the_content', function() {
                /**
                 * Filter is hooked by a method of an anonymous instance...
                 * Search all registered listeners and pick off the BP_Groups_Theme_Compat one.
                 */
 
                global $wp_filter;
 
                foreach( $wp_filter['bp_replace_the_content'][10] as $key => $filter ) {
                        if( is_array( $filter['function'] ) && is_a( $filter['function'][0], 'BP_Groups_Theme_Compat' ) ) {
                                // Found and removing the native content
                                unset( $wp_filter['bp_replace_the_content'][10][$key] );
                        }
                }
 
        }, 1 );
 
        add_filter( 'bp_replace_the_content', 'bp_group_hierarchy_buffer_group_tree', 100 );
}
function bp_group_hierarchy_buffer_group_tree( $content ) {
 
        /* Same as before */
        return $output;
}
 
// If admin says only show the group tree (and we are in theme compat), do it:
add_action( 'groups_directory_groups_setup', 'bp_group_hierarchy_inject_group_tree' );

Result: Works well but is pretty awkward and brittle. It looks like the kind of solution I’d really like to avoid.

Let’s try something completely different.

Third idea: Use BP Theme Compat functions to replace the loop template file.

BuddyPress theme compatibility adds a lot of flexibility in how content is gathered for the site. I actually find the theme compatibility process much more intuitive to work with than the traditional template loading process.

Here are some highlights:

1. bp_register_template_stack() lets you add a source of template files without filtering bp_located_template. Nice!
2. bp_get_template_part() offers an easy way to switch out template files on the fly that is just not possible with load_template.

Is it really this easy?

SPOILER ALERT: This does not work for BP Group Hierarchy. But for most applications, I think this is the best way to conditionally replace a BP page with content from a plugin.

 
/**
 * (BP 1.7+) Add plugin templates folder to list of available template paths
 */
function bp_group_hierarchy_register_template_location() {
	return dirname( __FILE__ ) . '/templates/';
}
 
/**
 * (BP 1.7+) Replace groups/groups-loop with tree/tree-loop depending on user settings
 */
function bp_group_hierarchy_maybe_replace_group_loop_template( $templates, $slug, $name ) {
 
	if( 'groups/groups-loop' != $slug )
		return $templates;
 
	return array( 'tree/tree-loop.php' );
}
 
if( function_exists( 'bp_register_template_stack' ) )
	bp_register_template_stack( 'bp_group_hierarchy_register_template_location' );
 
// If admin says only show the group tree (and we are in theme compat), do it:
add_filter( 'bp_get_template_part', 'bp_group_hierarchy_maybe_replace_group_loop_template', 10, 3 );

Result: Works(!)
But when you trigger an AJAX request, the unaltered ID on the “All Groups” tab leads BP to load the flat list.
We also still need to hook the bp_located_template filter to find stylesheets, since we are enqueue-ing them instead of loading the contents inline.
It also also removes the ability to customize the “Group Tree” label, a feature added by popular demand.

Fourth idea: Use BP Theme Compat functions to replace the whole Groups list page.

This is really just a twist on how things are currently handled, and it looks like the current way will be around as long as BP-compatible themes bypass bp_get_template_part.

 
/**
 * (BP 1.7+) Add plugin templates folder to list of available template paths
 */
function bp_group_hierarchy_register_template_location() {
	return dirname( __FILE__ ) . '/templates/';
}
 
/**
 * (BP 1.7+) Replace groups/index with tree/index-compat depending on user settings
 */
function bp_group_hierarchy_maybe_replace_group_index_template( $templates, $slug, $name ) {
 
	if( 'groups/index' != $slug )
		return $templates;
 
	return array( 'tree/index-compat.php' );
}
 
if( function_exists( 'bp_register_template_stack' ) )
	bp_register_template_stack( 'bp_group_hierarchy_register_template_location' );
 
// If admin says only show the group tree (and we are in theme compat), do it:
add_filter( 'bp_get_template_part', 'bp_group_hierarchy_maybe_replace_group_index_template', 10, 3 );

Result: Works seamlessly. It even allows BP to load templates from the stylesheet and template directories before falling back to those included with the plugin.

The only drawback is that it requires a new template file, the group tree version of the bp-templates/bp-legacy/buddypress/groups/index.php file from BP. Which is to say that it adds another layer of template hijinks and possible theme compatibility issues rather than removing an existing one.

Wrap up

I don’t know if this is the strategy that will ultimately make it into the plugin, but it is straightforward and has performed well in early tests. In the meantime, I hope this post will be useful to anyone else trying to do something crazy and ill-advised with BuddyPress.

If you use any of the techniques on this page, please drop me a line in the comments and let me know how they worked for you. And if you have any suggestions on techniques that work even better than these, please send those along too.

Step One: Change the link at the top of every group page to a trail of links to parent groups

This is the easy part! BuddyPress Group Hierarchy includes a function, bp_group_hierarchy_breadcrumbs(), that will generate a string of links to a group and all its parents. Use it in the Groups loop, and no parameter is required.

Note: If you need to pass in a different group for some reason, you’ll need to use bp_group_hierarchy_get_breadcrumbs( $separator = '|', $group = false ) function and echo the result yourself. This tutorial won’t address using that more advanced function.

Just locate your theme’s groups/single/group-header.php file, and find the current group header which will look something like this:

<h2><a href="<?php bp_group_permalink(); ?>" title="<?php bp_group_name(); ?>"><?php bp_group_name(); ?></a></h2>

Replace it with this simple line:

<h2><?php bp_group_hierarchy_breadcrumbs() ?></h2>

Step Two: Change the page title on group pages to reflect your group structure

Changing the page title is more complicated. BuddyPress builds its page titles with a function hooked to the wp_title filter. This function in turn presents its own filter, and that’s the one we have to hook to put breadcrumbs in the title of our Group page. This makes sure our filtering function runs only when BuddyPress is enabled and on as few pages as necessary.

If you zoned out during that bit, don’t worry! Just place the code below into your theme’s functions.php file.

add_filter( 'bp_modify_page_title', 'my_func_group_breadcrumbs', 10, 4 );
 
function my_func_group_breadcrumbs( $processed_title, $title, $sep, $seplocation  ) {
 
	global $bp;
 
 	if( bp_is_active( 'groups' ) && ! empty( $bp->groups->current_group ) ) {
		$processed_title = substr( $processed_title, strpos( $processed_title, $sep ) );
		$processed_title = bp_group_hierarchy_get_full_name( '|', $bp->groups->current_group ) . ' ' . $processed_title;
 	}
 
	return $processed_title;
}

This function strips the group name from the page title, but re-adds the names of the group and all its ancestors. The bp_group_hierarchy_get_full_name function works like the bp_group_hierarchy_get_breadcrumbs function I mentioned earlier, but it builds a plain text list instead of a list of links.

That’s it! Check back soon for a reference child theme, implementing this technique. As always, if you have any questions or problems adding this to your site, or if you have a novel implementation you’d like to share, please post in the comments below!

Update: As promised, here is the sample child theme! BuddyPress Group Hierarchy Breadcrumbs - Sample Theme

But what about users who login against an external authentication provider, and whose accounts are created and managed by such a system? Today we’re going to look at how to bring those users into the community in the same way as those who registered locally. Be warned — this is a fairly dense piece, especially if you haven’t worked with an authenticate filter before.

A crash course on authenticate

If you are using (or writing) an external authentication plugin, you’ll need a function hooked to the authenticate filter. This function is where your plugin gets a chance to authenticate users against your outside system. It is also where your users will have subordinate WordPress accounts made and managed by the external system.

A very quick example:

function my_func_to_authenticate( $user, $username, $password ) {
 // if $user is a valid WP_User, authenticated by an upstream filter
 // pass these params to the external auth source for verification
 // proceed if user is logged in, otherwise return a WP_Error
}
add_filter( 'authenticate', 'my_func_to_authenticate', 10, 3 );

The first login

The first time your users log in to your WordPress install using their external credentials, you’ll probably want to create a WP account for them. You may skip this if you’re just trying to restrict read access, but this is about BuddyPress, so I’m assuming you want them to post and contribute to the site.

Here’s a rundown of the process:

1. Suppress the BuddyPress activation email
2. Create WP user account
3. Update user meta and, optionally, xprofile data
4. Activate user and set proper display_name
5. Publish activity stream message about new user, with properly-formatted display name

Suppress the BuddyPress activation email

These users are already verified by virtue of being in our external auth system, so an activation email would just be confusing.

/** Suppress activation key email for users logging in with external auth */
add_filter( 'bp_core_signup_send_activation_key', create_function('','return false;') );

Create WordPress user account

Normally, you’d use wp_create_user (or wp_insert_user if you want access to the full set of user properties).
But BuddyPress comes with a wrapper function that can be used to do a lot of the heavy lifting for us.

$new_user = bp_core_signup_user(
	$user_login,
	$user_password,
	$user_email,
	array()
);
 
if( is_wp_error( $new_user ) ) {
	return $new_user;
}

Update user meta and, optionally, xprofile data

There are actually a few ways to handle this, ranging from bull-in-a-china-shop overwriting to graceful but more complicated filtering. Which one you choose may depend on your comfort with WP or PHP, which BuddyPress features you have enabled, or the structure of your authentication script.

$display_name = $first_name . ' ' . $last_name;
 
update_user_meta( $new_user, 'nickname',   $display_name  );
update_user_meta( $new_user, 'first_name', $first_name );
update_user_meta( $new_user, 'last_name',  $last_name  );
 
if( bp_is_active( 'xprofile' ) )
	xprofile_set_field_data( bp_xprofile_fullname_field_name(), $new_user, $display_name );
 
// Even though setting the xprofile value, above, should take care of this, 
// testing revealed that we needed to prime the cache with the right value
wp_cache_set( 'bp_user_fullname_' . $new_user, $display_name, 'bp' );

$new_user = bp_core_signup_user(
	$login_name,
	$password,
	$email,
	array(
		'profile_field_ids' => bp_xprofile_fullname_field_name(),
		"field_{bp_xprofile_fullname_field_name()}" => $display_name
	)
);

function my_display_name_filter( $user_id, $user_login, $user_password, $user_email, $usermeta ) {
	// must get $display_name from another part of the authentication process
	if ( bp_is_active( 'xprofile' ) ) {
		xprofile_set_field_data( bp_xprofile_fullname_field_name(), $new_user, $display_name );
	}
}

function my_func_to_authenticate( $user, $username, $password ) {
 
	// ... authenticate user
	add_action( 'bp_core_signup_user', 'my_display_name_filter', 9, 5 );
	$new_user = bp_core_signup_user(
		$login_name,
		$password,
		$email,
		array()
	);
}

Activate user (and set proper display_name, if needed)

Update 08-06-2012: I used to recommend wp_update_user for this, but that has proven unreliable on a recent project. So to be safe, just use a direct query.

// activate user and set display name appropriately
$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->users SET display_name=%s, user_status=0 WHERE ID=%d", $display_name, $new_user ) );

And if you set $display_name above, use the shortened version:

// activate user
$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->users SET user_status=0 WHERE ID=%d", $new_user ) );

Publish an activity stream message about the new user and notify the site admin

Since the display_name property and associated xprofile field are finally set the way we want them, it’s time to trigger the activity stream message and administrator notification.

bp_core_new_user_activity( $new_user );
wp_new_user_notification( $new_user );

And you’re done!

Return a WP_User object to let other authentication filters know you’ve handled this user.

return new WP_User( $new_user );

A complete example

function my_func_to_authenticate( $user, $username, $password ) {
	// if $user is a valid WP_User, authenticated by an upstream filter
	if( is_a( $user, 'WP_User' ) ) return $user;
 
	// pass these params to the external auth source for verification
	// proceed if user is logged in, otherwise return a WP_Error
	if( $user_details = my_external_auth( $username, $password ) ) {
 
		// for simplicity's sake, I'm assuming that $user_details is an array with all the right keys
		// in practice, more checks would be required
		extract( $user_details );
 
		// this function returns the new user account ID if successful
		$new_user = bp_core_signup_user(
			$username,
			$password,
			$user_email,
			array()
		);
 
		// If signup returned an error, skip the rest
		if( is_wp_error( $new_user ) ) {
			return $new_user;
		}
 
		$display_name = $first_name . ' ' . $last_name;
 
		update_user_meta( $new_user, 'nickname',   $display_name  );
		update_user_meta( $new_user, 'first_name', $first_name );
		update_user_meta( $new_user, 'last_name',  $last_name  );
 
		if( bp_is_active( 'xprofile' ) )
			xprofile_set_field_data( bp_xprofile_fullname_field_name(), $new_user, $display_name );
 
		// Even though setting the xprofile value, above, should take care of this, 
		// testing revealed that we needed to prime the cache with the right value
		wp_cache_set( 'bp_user_fullname_' . $new_user, $display_name, 'bp' );
 
		// activate user and set display name appropriately
		$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->users SET display_name=%s, user_status=0 WHERE ID=%d", $display_name, $new_user ) );
 
		bp_core_new_user_activity( $new_user );
		wp_new_user_notification( $new_user );
 
		return new WP_User( $new_user );
	}
	// you can return FALSE, or a WP_Error if you have something specific to say
	return new WP_Error( 'login_failed', __( 'Could not authenticate user' ) );
}
add_filter( 'authenticate', 'my_func_to_authenticate', 10, 3 );

If you have questions, or if you put this to use in your next project, feel free to drop me a line in the comments!

BuddyPress Groups loop overview

If you aren’t familiar with bp_has_groups() from looking at the BuddyPress theme files, you should take a look at this overview from the BP Codex before continuing.

In a nutshell, bp_has_groups() accepts a series of parameters which it uses to populate the global $groups_template variable with a set of groups. This, in turn, allows all the cool template functions to work without parameters cluttering up your theme file.

How Group Hierarchy changes the Loop

BuddyPress Group Hierarchy changes this in two important ways:

1. bp_has_groups() creates a set of BP_Groups_Hierarchy objects instead of BP_Groups_Group objects
2. bp_has_groups_hierarchy() extends the loop with a parent_id parameter for getting only child groups of the passed group ID

There are more changes made just for the Group Tree, but that’s enough to get us started. Onward!

Creating a Member Groups list

Before we build our Member Groups page / widget / list, there’s something you should know about working “in the loop,” i.e. in the context of the current group. The only thing telling BuddyPress what group we’re looking at is the $groups_template variable introduced above. Our member group list is going to change that variable, so we need to save its current state and restore it when we’re done.

// If you're in a function, bring $groups_template into scope
global $groups_template;
 
// Save the current group context for later
$current_group_template = $groups_template;

Using the Codex article I posted at the top as a reference, you’ll see how easy it is to create a Member Groups page / widget / whatever.

Just replace:

<?php if ( bp_has_groups() ) : ?>

with:

<?php if ( bp_has_groups_hierarchy( array( 
	'type'      => 'alphabetical',
	'parent_id' => bp_get_current_group_id() 
) ) ) : ?>

…and the rest works as is! Since 1.3.0, pagination is handled automatically.

Don’t forget to restore the original context!

$groups_template = $current_group_template;

A complete example

Here’s a quick example that adds a list of Member Groups on the Members page, above the list of users. Drop this in your functions.php file, or in a custom plugin, but note that it will only display if the parent group has at least one member!

<?php
add_action( 'bp_before_group_members_content', 'my_func_list_member_groups' );
 
function my_func_list_member_groups() {
	// If you're in a function, bring $groups_template into scope
	global $groups_template;
 
	// Save the current group context for later
	$current_group_template = $groups_template;
 
	if ( bp_has_groups_hierarchy( array( 
		'type'      => 'alphabetical',
		'parent_id' => bp_get_current_group_id(),
	) ) ) : ?>
 
	<h3><?php _e( 'Member Groups' ); ?><br />&nbsp;</h3>
 
	<div class="pagination">
 
		<div class="pag-count" id="group-dir-count">
			<?php bp_groups_pagination_count() ?>
		</div>
 
		<div class="pagination-links" id="group-dir-pag">
			<?php bp_groups_pagination_links() ?>
		</div>
 
	</div>
 
	<ul id="groups-list" class="item-list">
	<?php while ( bp_groups() ) : bp_the_group(); ?>
 
		<li>
			<div class="item-avatar">
				<a href="<?php bp_group_permalink() ?>"><?php bp_group_avatar( 'type=thumb&width=50&height=50' ) ?></a>
			</div>
 
			<div class="item">
				<div class="item-title"><a href="<?php bp_group_permalink() ?>"><?php bp_group_name() ?></a></div>
				<div class="item-meta"><span class="activity"><?php printf( __( 'active %s ago', 'buddypress' ), bp_get_group_last_active() ) ?></span></div>
 
				<div class="item-desc"><?php bp_group_description_excerpt() ?></div>
 
				<?php do_action( 'bp_directory_groups_item' ) ?>
				</div>
 
			<div class="action">
				<?php bp_group_join_button() ?>
 
				<div class="meta">
					<?php bp_group_type() ?> / <?php bp_group_member_count() ?>
				</div>
 
				<?php do_action( 'bp_directory_groups_actions' ) ?>
			</div>
 
			<div class="clear"></div>
		</li>
 
	<?php endwhile; ?>
	</ul>
 
		<?php do_action( 'bp_after_member_groups_loop' ) ?>
 
	<?php else: ?>
 
		<div id="message" class="info">
		<p><?php _e( 'There were no member groups found.' ) ?></p>
		</div>
 
	<?php endif;
 
	// restore original group context!
	$groups_template = $current_group_template;
}

That’s it! Drop me a line in the comments if you find a novel use for this technique.

A frequent feature request for BuddyPress Group Hierarchy has been to automatically join members of a subgroup to its parent groups. While pretty straightforward to implement, there are two main reasons this feature won’t make it into the plugin:

1. This behavior isn’t appropriate for many or even most setups
2. Everyone who has requested it has wanted it to work on groups by different criteria — some want groups of a certain depth, others a specific set of groups, others all the children of a certain group. Building a UI that would let this work the way anyone wants would overwhelm the project.

Instead, I decided to post this sample implementation, including a few ways to select groups. Take a look!

The Code

The code below can be included in your theme’s functions.php file, or can be part of a new plugin.

Note for the true novice: you must choose one of the if statements in the block below with this code and substitute the placeholders for things you care about. It will not work pasted as is.

/* groups_join_group is called whenever someone joins a group in both BP 1.2 and 1.5.x */
add_action('groups_join_group', 'my_join_group_action', 10, 2);
 
function my_join_group_action( $group_id, $user_id ) {
 
	/* This part is critical - you must select ONLY the groups you want to START this chain
	 * This function will recurse up to the toplevel on its own, so if you have a parent group
	 * in the list, you will waste resources trying to join the same group multiple times
	 * as this function is called on each step up the tree
	 */ 
	/** Pick from a list of groups */
	if( in_array( $group_id, ARRAY_OF_GROUPS_I_CARE_ABOUT ) ) {
	/* -- OR -- */
	/** Select groups by depth */
	if( count( bp_group_hierarchy_get_parents() ) == DEPTH_OF_GROUP_I_CARE_ABOUT_EG_3 ) {
	/* -- OR ANYTHING ELSE YOU LIKE */
 
		/* However you choose to select groups, once the group_id matched this part will 
		 * walk up the tree, joining the user to each parent group along the way
		 */
 
		$parents = bp_group_hierarchy_get_parents();
		foreach( $parents as $parent_group_id ) {
			groups_join_group( $parent_group_id, $user_id );
		}
	}
}

If this helps you, or if you have some code to select the groups that matter to YOU, feel free to post in the comments below!

Updated (1/07/12): Updated instructions and the sample child theme to fix the activity type issue reported by Towfiq.
You can download the updated theme here: BuddyPress Group Home Page - Example Theme

Updated (11/29/11): Added a sample child theme implementing these changes.

Here are a few simple steps to make it happen. Ordinarily, this would just go in a plugin or something. But this particular change requires edits to the group-header.php groups/single/home.php file, so it’s more a theme modification than a plugin.

A note before we get started: I will assume that you’re working with a child theme. Child themes are great — they let you change just the templates or styles you want without wading through a bunch of other files, and they keep your work from being wiped out when a new version of BuddyPress is released. See this BuddyPress Codex page if you want to know more.

Step One: Create an Activity tab for the activity stream, since we’re displacing it.

To do this, we’re going to use parts of the Group Extension API to create a new nav item for the group.

In your theme’s functions.php, add the following:

function add_activity_tab() {
	global $bp;
 
	if(bp_is_group()) {
		bp_core_new_subnav_item( 
			array( 
				'name' => 'Activity', 
				'slug' => 'activity', 
				'parent_slug' => $bp->groups->current_group->slug, 
				'parent_url' => bp_get_group_permalink( $bp->groups->current_group ), 
				'position' => 11, 
				'item_css_id' => 'nav-activity',
				'screen_function' => create_function('',"bp_core_load_template( apply_filters( 'groups_template_group_home', 'groups/single/home' ) );"),
				'user_has_access' => 1
			) 
		);
 
		if ( bp_is_current_action( 'activity' ) ) {
			add_action( 'bp_template_content_header', create_function( '', 'echo "' . esc_attr( 'Activity' ) . '";' ) );
			add_action( 'bp_template_title', create_function( '', 'echo "' . esc_attr( 'Activity' ) . '";' ) );
		}
	}
}
 
add_action( 'bp_actions', 'add_activity_tab', 8 );

That adds a tab called ‘Activity’ to every group’s navigation bar, pointing to a page called ‘activity’ within the group. This new activity page is calling the same groups/single/home.php template file as the current home page. That template actually handles routing for ALL group pages, as we’ll see in a minute.

Step Two: Create a template file for your group Home page

If you’re going to have a Group home page, you need to control how it’s displayed. To do that, you’ll need a template file in your theme’s groups/single directory. It can be called whatever you’d like, but for this guide, we’re sticking with front.php.

Create this file and put whatever you want in it. This template will be in the “group loop”, so you can use functions like bp_group_description() to display group info.

Here’s an example:

<div class="home-page single-group" role="main">
<?php if(bp_is_item_admin()) { ?>
	<div class="notice info">
		<p>Welcome to your group home page!<br />
		Click <a href="<?php bp_group_admin_permalink() ?>">Admin</a> above to set the content for this page.</p>
	</div>
<?php } ?>
<?php bp_group_description(); ?>
</div>

Up to now, all we’ve done is create a new Activity tab on the group page that doesn’t even show the activity stream. But this last piece will make everything work:

Step Three: Edit your theme’s groups/single/home.php template file

Look for this section in your home.php file:

47
48
49
50
51

	elseif ( bp_group_is_visible() && bp_is_active( 'activity' ) ) :
		locate_template( array( 'groups/single/activity.php' ), true );
 
	elseif ( bp_group_is_visible() ) :
		locate_template( array( 'groups/single/members.php' ), true );

This directs a visitor to either the activity stream or the member list, depending on whether activity has been enabled. It’s a catch-all routing section, and it’s where we’ll be adding our group home page.

Change the lines above to:

47
48
49
50
51

	elseif ( bp_group_is_visible() && bp_is_group_activity() ) :
		locate_template( array( 'groups/single/activity.php' ), true );
 
	elseif ( bp_group_is_visible() ) :
		locate_template( array( 'groups/single/front.php' ), true );

This enables the Activity tab AND sends requests for the group home page to your new template! Of course, if you used a name other than front.php, you’ll need to change that line to match the name you chose.

Update! Step Four – Let BuddyPress JS know how to classify your new activity posts

Now you can make activity updates, but BuddyPress won’t remember that they came from your group. In order to fix that, we need to relax a check in another file, activity/post-form.php.

Look for this section:

59
60
61
62
63
64

	<?php elseif ( bp_is_group_home() ) : ?>
 
		<input type="hidden" id="whats-new-post-object" name="whats-new-post-object" value="groups" />
		<input type="hidden" id="whats-new-post-in" name="whats-new-post-in" value="<?php bp_group_id(); ?>" />
 
	<?php endif; ?>

Without those hidden fields, BuddyPress thinks we’re just posting a personal status update. So let’s expand that to cover our new Activity page:

59
60
61
62
63
64

	<?php elseif ( bp_is_group() ) : ?>
 
		<input type="hidden" id="whats-new-post-object" name="whats-new-post-object" value="groups" />
		<input type="hidden" id="whats-new-post-in" name="whats-new-post-in" value="<?php bp_group_id(); ?>" />
 
	<?php endif; ?>

Now BuddyPress will tie the update to a group no matter where in the group we post it.

That’s it! Check out your new group home page and enjoy the results your BuddyPress hacking chops. And if you do something really cool with a group Home page, send a link my way!

Updated: Here’s a sample child theme to get you started. It includes all the changes mentioned in this article.
BuddyPress Group Home Page - Example Theme

Replace:

remove_action( 'init', 'bp_core_action_search_site', 5 );//force buddypress to not process the search/redirect
add_action( 'init', 'bp_buddydev_search', 10 );// custom handler for the search

with

add_action( 'bp_init', 'bp_buddydev_search' ); // custom handler for the search
remove_action( 'bp_init', 'bp_core_action_search_site', 7 ); //force buddypress to not process the search/redirect

And replace:

if ( $bp->current_component == BP_SEARCH_SLUG )//if this is search page

with

if (bp_is_current_component( bp_get_search_slug() )) //if this is search page