I made the above changes and the center column is gone. It has left an empty space, however, the right column did not take up that empty space. Since the above recommendation is a bit dated, are there any additional changes to be made if running RC-1? Thanks. Maybe a future BP version will allow the admin to choose between two or three columns.
Copy bp_core_widget_members() and bp_core_widget_members_control() functions from the file bp-core-widgets.php into a new file. Rename the widget functions from “members” to “newmembers” or whatever. Remove everything in the div “item-options” if you don’t need ajax option choices.
Add these two lines to the end of the file:
register_sidebar_widget( __(‘New Members’, ‘buddypress’), ‘bp_core_widget_newmembers’);
register_widget_control( __(‘New Members’, ‘buddypress’), ‘bp_core_widget_newmembers_control’ );
Save the file as “newmembers.php” into mu-plugins. Next time you login the widget will be listed on the widgets page ready to be placed on the front page.
http://ajatukseni.net – finnish blogging community
I’m going to repost my BuddyPress on this page if no one minds…
http://delsolownersclub.com
It’s now a fully integrated BuddyPress/bbPress install, with a bbPress theme to match the Member Theme style layout that BP has become popular for.
I invite any/all of you to join as well (maybe don’t create a blog if you don’t need one) if you’d like to check it out and give it a test drive.
Quick suggestion, although I bet many people won’t run into this issue…
function oci_get_userdata($u){
$u = (int) $u;
$user = bb_get_user($u);
if ($user->bbGroups) {
return stripslashes_deep((array)$user->bbGroups);
} else {
return stripslashes_deep((array)$user);
}
}
Then, I changed…
function oci_user_name($u){
$bp_user = oci_get_userdata($u);
if ($bp_user['fullname']) {
return $bp_user['fullname'];
} else {
return $bp_user['display_name'];
}
}
Basically, I integrated my forums before installing BuddyPress, so there are users that haven’t updated their BuddyPress profiles that won’t have fullname’s yet… This way I have all of their normal info to manipulate later and still get their original wordpress display_name to fallback on…
There is probably a much prettier way of doing this, but this is the solution my tired brain could come up with for now.
Chad, welcome and don’t be scared; you’ve lurked long enough to know we don’t bite. 
I’m going to answer as best as I can in probably no particular order…
In step 6, Trent is referring to the BuddyPress groups page.
Checking cookie integration works fine, and as a matter of fact I’ve always checked it, because I know that not checking it on the bbPress side leads you down a different installation path. I think it basically makes me do the work twice, because checking the box makes you enter the salts and things that we’re already hard coding into the _config files. So, no worries there.
If you check my profile and look at some of the posts I’ve started, I had similar problems and Burt was awesome enough to help me through some things, but chances are that the IXR just isn’t linking up somewhere…
Let me see if I can find exactly how Burt suggested to debug this, but it worked really well and got me up and on my way in a few minutes, after a few hours of banging my head against it.
That makes sense. I’m actually using a modified version of your oci_bp_custom.php that you linked me to previously, and I think I have a good understanding of how they all work together.
The problem is going to be getting the xprofile fields and data that I want to use, since there doesn’t seem to be a function that says “get all the users extended field data.”
I guess what I’m running into is that the xprofile data doesn’t seem to be in a variable or a global anywhere, because it isn’t really considered meta. It’s kinda like how $bp doesn’t carry around all of the messages in your inbox on every page load, it also doesn’t carry around all the xprofile fields.
Deep integration actually starts WPMU and BuddyPress before it ever touches bbPress, so all of the functions and variables and data I need and can access seem to be available within bbPress.
If you do a search for “private” or “members only” you will find loads of examples of what people are doing to restrict things right now with Buddypress 
Trent
just my 2c
I’m using http://www.slicehost.com for some of the wpmu/buddypress sites I’m building now. I’ve started with a 256MB slice, and will/can expand when needed to a larger/more slice(s). My configuration is/will be:
– nginx instead of apache (implemented)
– eAccellerator (implemented)
– Multi-DB from premium.wpmudev.org (implemented soon, 256 DBs)
– WP-SuperCache or WP-SuperCache-Plus (not sure which one yet)
– offload themes to S3 (maybe)
sgrunt, works like a charm for me! Thanks. Can you post this in trac for everybody please? Just those two changes to those elements.
https://trac.buddypress.org/newticket
Do we have a set of requirements for this plugin? Also, if we all chip-in, can it be made open source afterwards?
For me, a good feature set would be:
* On the signup page have a ‘Create an account using your Facebook details’ button so that information is already added when the users account is created.
* For existing users, a button they can press to connect their accounts up.
* New events on the BuddyPress site to be published on their Facebook account. So, what you would normally have on their profiles ‘Activity’ area, posted onto Facebook. Eg, “John created a new group on The BuddyPress Demo Site”.
* This activity ‘syncing’ can be configured from the users settings page on BuddyPress, so they can turn off activity updates.
* In the same settings page, the user can choose to either use their Facebook avatar, or their BuddyPress one
* Have a page like buddpress-site.com/members/MEMBER/friends/invite, and having the ability to ‘Invite your Facebook friends to BuddyPress Demo Site’, would be great.
Are there any other features people would like added? I won’t be the one building it obviously, but if we can have a set of features then we all know what we’re chipping in for! lol
export your blog to the wordpress format then install mu and buddypress, your blog can then still be accessed by /blog, but obviously you will have to import it first,
most of the plugins will work with mu but some will not, i guess you can only hope and try them out
you will need to add your plugins again, i suggest you add them one by one to see what is working and what isnt, hope that helps, let me know if you need more help
I think the main css elements are based here:
/member-themes/buddypress-member/css/base.css
No offense but the “fix” for this bug is not acceptable. “a few international characters not working” /is/ a big deal to the rest of the world.
The characters show up fine in Buddypress no matter where I post the text; BB or BP.
The characters show up fine in BP and wrong in BB if I post the text in BP.
There has to be another way around this.
http://bouw.fnvnet.nl – dutch trade-union site experiment
http://gibcosta.com
in the social section http://social.gibcosta.com
has anyone been able to get the FBconnector plugin running with buddypress?
As far as I can see these can be changed in
member-themes > buddypress-member > header.php
Search for id=”nav” around line 39
Would be good to have a language file for these elements.
After hours working on that I found a solution, but isn’t definitive and already have a bug! Let’s go. Nicolas, don’t kill me – i’m trying to help!
In the line 728 on bp-xprofile-classes.php just copy and paste the code bellow:
<div id="titlediv">
<h3><label for="is_public"><?php _e("Is This Field Public?", 'buddypress') ?> *</label></h3>
<select name="is_public" id="is_public" style="width: 30%">
<option value="0"<?php if ( $this->is_public == '0' ) { ?> selected="selected"<?php } ?>><?php _e( 'Public', 'buddypress' ) ?></option>
<option value="1"<?php if ( $this->is_public == '1' ) { ?> selected="selected"<?php } ?>><?php _e( 'Private', 'buddypress' ) ?></option>
</select>
</div>
This code will add an opition in the field edit screen / at ProfileFields Admin – to keep the data private for “non friend users”
But the problem is IF the field have data and you aren’t a friend, you will see the field name, but the data will be hidden. look at my birthday http://voiceover-casting.com/members/admin/
I have tryed do the same with the Groups Fields but doesn’t work. Maybe someone can help me to create “Hidden Field Groups” and found a fix my newbie solusion for the “Private Fields” bug.
Could be nice if in a new version the admin and the users can select “Who can see the data” like: “Public, Only Friends, Hidden (only visible for admin and the owner), “.
Nicolas, I will donate for you soon for your great job.
I think the idea is not to have BuddyPress permanently alter the WordPress related data.
I’m new to BP and so I’m not familiar with how all the functions work, but what in the original WP data structure would be altered by deprecating fullname in favor of using the WP fields?
…then really BuddyPress should be able to modify ALL of the original WordPress user info exactly like the profile admin panel does…
I would like that, actually. Or at least to have the option to have the profile be able to modify that information.
I want the original WP functionality that allows a user to choose which fields — username, first name, last name, or nickname — to display for them. I thought that was a great addition to WP and I don’t like that installing BP has effectively cut me and my users off from that choice without some serious code modification on my end.
I think the idea is not to have BuddyPress permanently alter the WordPress related data. Right now, and please correct me if I’m wrong, but past of the design and development process of BuddyPress is that it can be added and removed without any changes done to the WPMU data structure, apart from conveniences like changing a password, etc…
You can rename the “Full Name” in the BuddyPress to say “Nick Name” or “Display Name” or whatever you’d like, and then code your themes to use that info if you so choose…
To be honest, from a developers standpoint, I like how it is right now, as it allows me to keep things separate. If you’d like to open up the ability to modify the fullname, then really BuddyPress should be able to modify ALL of the original WordPress user info exactly like the profile admin panel does, with website, info, firstname, lastname, etc…
Hello! I’ve just downloaded the 1132 trunk but the problem still remain for the Brazilian Portuguese translation. The behaviour is exactly as described in thread https://buddypress.org/forums/topic.php?id=1250.
Does anyone know how to solve it?
Thanks!
Unfortunately, that doesn’t actually make a big difference in my case; the main problem I have is that the header and footer files between the two themes are vastly different. The two main problems are that 1) one of my themes is fixed width at a size smaller than the minimum size for the BuddyPress themes (which breaks the layout) and 2) they don’t have the header with “Home”, “Blog”, etc. which I don’t want on my main site, but *do* want on the members directory and blogs directory.
I was thinking about it, though; the member-theme actually has plugin-template.php although it doesn’t appear to be used. Is there some particular reason why if a blog theme doesn’t have that file it puts up an error message instead of redirecting to the member-theme file?
These forums are not meant to be a job board. They are for ideas on expanding buddypress and support in general. If someone asks for paid support they must leave their contact information and the thread will be closed.
Well, one solution would be to have a blog created for the group with all group members set as editors.
The BuddyPress Codex (http://codex.buddypress.org) is run off WP and instead of a normal wiki users log in and are able to edit the pages – revisions are saved thanks to post/page revisions.
It would just need a plugin to add some options to the group admin area; Group Blog settings for example.
