BuddyPress.org

This worked beautifully for WordPress 3.8 + Buddypress 1.9.1. Thank you!

I made it so that the “home” tab was named the “activity” tab, moved it over, and made the “forum” tab the first tab that users see when viewing a group. That way at least the first thing they see isn’t the activity feed for the group which is very overwhelming.

You can do this for each group individually using the BuddPress Group Extras plugin, but you’d have to do it one group at a time. Instead, I added some code to my functions.php in my child theme to do the same thing, but for all groups.

Below are the two functions I created. The first renames the activity tab and moves it over, the second forces the “forum” tab to be the first tab a user sees when visiting the group (unless the group has no forum in which case it still defaults to the activity tab).

//function to reorder and rename group tabs in buddypress
function whff_setup_nav() 
{

global $bp;

  if (isset($bp->groups->current_group->slug) && $bp->groups->current_group->slug == $bp->current_item) 
  {
     $bp->bp_options_nav[$bp->groups->current_group->slug]['home']['position'] = 110;
	 
	 $bp->bp_options_nav[$bp->groups->current_group->slug]['home']['name'] = 'Activity';
	 
}

} 
add_action( 'bp_setup_nav', 'whff_setup_nav', 100000 );

//function to redirect group home pages to the forum tab instead of the activity tab
function redirect_group_home() {
  global $bp;
  $path = clean_url( $_SERVER['REQUEST_URI'] );
  $path = apply_filters( 'bp_uri', $path );
  if (bp_is_group_home() && strpos( $path, $bp->bp_options_nav[$bp->groups->current_group->slug]['home']['slug'] ) === false && bp_is_active('forums') ) {
    if ($bp->groups->current_group->is_user_member || $bp->groups->current_group->status == 'public') {
      bp_core_redirect( $path . 'forum/' );
    }
  }
  
}

add_action('bp_init', 'redirect_group_home');

@jlarosa 1.9.1 was released to include this fix for #5299: https://codex.buddypress.org/developer/releases/version-1-9-1/

Is there any update on this? I’m a WordPress expert, but just starting to dabble into Buddypress. I’m experiencing the same problem and tried applying the patches, but it didn’t seem to fix the problem. I’m using the Huddle Theme (Purchased), also having same issue with Frisco Child Theme.

Any timeline on 1.9.1 roll out?

if you are talking about editing the regular wordpress profile fields from the front end the same way you edit the extended buddypress profiles that may be part and parcel with a feature i am currently lobbying for for 2.0 which is the merger of the two, both fronted and back.

if that’s something you’d also like to see or is what you are trying to accomplish then i would urge you to enter this code patch as a ticket in trac:

https://buddypress.trac.wordpress.org

and while you’re at it please take the survey for any other input you have as far what you’d like to see for buddypress 2.0 i believe today’s meeting is where the new features will be scoped so the next few hours could be the last chance to give your input:

2014 BuddyPress Survey

also if you want to attend the devchat itself it’s held on irc at 20:00 UTC every wednesday on the channel #buddypress-dev

if you do not have an irc client you can use the web browser version here:

http://webchat.freenode.net

hope to see you there!

CORRECTION: the feature scoping has been postponed until next week.

I think we’re a bit confused because this is a native feature of one of BuddyPress’ default components. In Admin CP -> Settings -> BuddyPress Components you find one called Account Settings.

Allow your users to modify their account and notification settings directly from within their profiles.

The link should be, though there should be a tab in the profile itself:

http://example.com/members/USERNAME/profile/edit/

Replace example and USERNAME.

the front end buddypress profile is not connected to the backend one (for the most part) you may be missing the fact that the front end profile fields need to be set by you in the profile fields section of your users settings in wp admin. those fields are only editable from the front end by default.

because of its nature (membership site where content differs depending on being logged in vs. logged out content) the best caching solution for buddypress is partial page caching (aka fragment cache), something that sort of exists and sorta doesn’t.

my suggestion is to take the BP survey and to add your voice for it so the developers know there is real demand:

2014 BuddyPress Survey

more info:
http://chrislema.com/high-performance-wordpress-membership-site/

Fragment caching in WordPress to optimize site speed for logged-in users

https://bitbucket.org/Rarst/fragment-cache
https://wordpress.org/plugins/fragmentcache/

that plugin works fine with buddypress but analytics itself doesn’t really treat bp pages any different from any other. You can set up filters, views and other GA settings to get a better picture. You might also want to check this plugin out its not free ($16 dollars i believe) but it is specifically designed to give you buddypress specific behavior analytics:

BuddyReports

@scottwermter thank you. Will report this.

Edit – Done. https://buddypress.trac.wordpress.org/ticket/5337

Hey I’m actually having a lot of trouble with this too on a few websites…. WordPress 3.8, BuddyPress 1.9, few plugins, VPS with over a ram of memory each (not enough imo but whatever) and cachhing… the site is plenty fast enough on Pingdom tests and WebPagetest.org… but the add friend functionality is painfully slow….

Cicade, did you ever find any culprits here? Has anyone else noticed with this with BP 1.9? I had not before, with 1.8. Just curious if this was solved, or if anyone else is seeing a problem/has a solution.

I’ve had a lot of luck with the W3TC plugin. I set object caching to Disk, Page caching to APC, and minification with CloudFlare (I’d use APC otherwise). If you have a lot of memory to work with, by all means use APC on the disk too…. the VPS’s I’ve worked on lately had only a gig and object cache with that had a tendency to crash under moderate traffic.

“Is it safe to say that the caching plugins do not provide a good solution for Buddypress? And that a server side caching solution is the best option?”

This question doesn’t quite make a lot of sense. APC, memcache… hell even disk is server side. And the plugins available are doing that. The question is what’s right for your site… and that really depends on what you’re starting with on your server (which I presume is a VPS not a VPN)

Anyway, W3TC works for me…but you’re gonna get a lot of answers cause it really just depends.

Key thing to note: “My site has reached popularity that I need it now.”

If you didn’t already know, play with caching on a test server. It’s useful stuff, but you can crash the site very easily if you make a mistake. This is not a toy to play with on a live website.