BuddyPress.org

Burt,

I found a bug in the 1.0 alpha 2 and I was curious if the other members have experienced the same issue, and also if you resolved the issue with the 1.0 release.

Problem:

click on Members Directory

click on a letter for a member listing, say ‘M’ and it shows 21 listings. Okay, first 10 members are displayed. If you click on page 2, it goes to a weird submenu that leads to a blank page.

Here is the weird behaviour –

a new page loads with the following url and it’s blank:

http://www.xxyy.info/OurSocial/OurSocial/wp-load.php?upage=2

Resolution:

deactivate the bpc plugin, return to Members Directory

follow same member listing search for category ‘M’

click on page 2

all is fine – works as expected.

The links for pages 2 and 3 show the same links as listed above, but when you click on them, the main page stays the same,

http://www.xxyy.info/OurSocial/members

and only the Member Listing changes

Using:

wpmu 2.7.1 and the new bp 1.0.2

Also, an other question: if we upgrade automatically to bpc 1.0, what about the existing db created tables? Will they be in conflict or will the plugin just create a new table? I ask this because I read the ‘details’ of the upgrade and it says the new plugin creates one new table in the db

Thanks so much for your hard work.

Brian

First off, I do sympathize with your frustration on finding an acceptable set of solutions to your questions. Without writing the code for you, it is difficult to point you in the proper direction. There have been a number of options presented, that while being a compromise to your ultimate, desired solution, could produce satisfactory results.

Isn’t the whole point of Buddypress to turn the WordPress base into something more user-centric?

Yes and no. As I already said two posts above:

WPMU is not designed as a user-centric platform. It is blog-centric. BuddyPress puts the focus on the user.

But, BuddyPress is still a layer that rests on top of WPMU, not the other way around. BP relies heavily on certain WPMU functions to handle much of the user registration process. And WPMU requires that the username field be populated (I realize that you know that).

This thread is NOT about the username issue.

I understand that. But what I quoted from your past post was about the username field and that is what I specifically answered in my last post.

This particular thread is entitled “How to use full name, first name + last name“. Burt already provided an answer to this question above via this thread where he shows you how to do exactly this in code.

I’ve understood all along in the various threads that you’ve started on this range of related topics that you want another option, some other way to insert your desired datum into the user_login field, or use newly created fields to allow registering users to enter their firstname and lastname, or that you want a way for users to enter their email for login, or a way to use BP’s xprofile table to display fname and lname in various ways and places, or a way to rearrange fields on the registration form, and that you hate WPMU’s concept of username and want a different option. I get all of this.

Others (including myself) have tried to be as helpful as possible in each of those threads, often rehashing the same answers. I don’t say this to be mean; I say this because we’ve tried to explain in multiple ways and multiple times that what you are after is not possible at this time without hacking the core (in some cases) or writing your own custom plugin(s).

https://buddypress.org/forums/topic.php?id=1746

https://buddypress.org/forums/topic.php?id=1811

https://buddypress.org/forums/topic.php?id=2118

https://buddypress.org/forums/topic.php?id=2119

https://buddypress.org/forums/topic.php?id=2926

How does Buddypress handle first name + last name?

It does and it doesn’t. There are no firstname and lastname fields in BuddyPress unless you create them as Mike Pratt explained above. BuddyPress has its own mandatory registration field that by default is called “Full Name”. Look in the BuddyPress submenu group in WPMU’s backend. Go to “BuddyPress > General Settings > Full Name field name”

Now, there is a function in bp-xprofile-filters.php called xprofile_sync_wp_profile() that will take the datum from the “Full Name” field and split it into a pseudo firstname and lastname and then insert that as meta data into the wp_usermeta table, but it can only do that if a user actually edits their fullname field to include a more than one-word name. So if a user does not edit that field, there will not be any fname/lname wp_usermeta entries for that user.

Buddypress puts a default first x-profile field Name on the registration form; is it possible to replace that with separate first name + last name fields?

You can change the “Full Name” field name to whatever you want but you cannot remove that field from the registration page nor edit it to be something other than a single textbox field–at least not without hacking the core. Look under the “Basic” field grouping in “BuddyPress > Profile Field Setup” to see what I mean.

Or is there already a native solution for first name + last name in WPMU that Buddypress could tap into? (Nicola Greco: ‘… you could replace it with the wp built-in name & last name, or use xprofile fields fot that …”)

In this post above, I explained that if you want to go this route, you’ll need to pull data from two records in wp_usermeta to extract the firstname, lastname combination. If you do not feel comfortable coding this yourself, you could hire a coder to write a simple function to do just that. But be aware, as I explained above, it is possible that not every user will have firstname and lastname meta date.

From your OP:

Default Buddypress is fine for teens/tweens who want to use their anonymous username, but it’s not suitable for a more grown-up business network, for example.

BuddyPress seems perfectly acceptable for business users. There are many professional, adult-based sites that are successfully attracting users to their BP sites. Mike Pratt’s site is a great example, for one.

I’ve been using my full name on this site from day one. It did not bother me that I had to use a single username when registering because I knew I had the option to fill out my full name for display purposes later. It also allowed me to brand BuddyPress.org with my unique name, creating a useful URI in the process.

In fact, the single username approach is what many sites use to allow users to brand themselves. Twitter, youtube, FriendFeed, Delicious, Digg, LinkedIn, and many more all require a unique, single-word username. Of course, some of these then allow you to (or even require) that you use an email for subsequent logins. This is in BP’s future as well.

In the not too distant future, there may be an option to allow users to sign on with their email address via OpenID or another protocol. See the BuddyPress Roadmap and read about the Open Stack.

But for now, your options are limited and if you want to change things you must code your own custom solution or hack the core.

There is not much more we can do, but as I said in my last post, if the username concept bothers you so much, you’ll have to go to the WPMU forums and see what solutions might be in the works–if any.

You need to log into WPMU’s backend as site admin ( /wp-login.php), and then go to

Site Admin > Options > Allow new registrations

and set the options you want.

Also I am unable to create an extended profile like shown in some of the demos. It only allows me change the “base” and avatar. I can’t put birthday, location, etc.

To add additional profile fields, you need to navigate to the BuddyPress submenu grouping in WPMU’s backend. If BuddyPress is installed and activated, this submenu group is found at the very bottom of the menu column.

So, go to

BuddyPress > Profile Field Setup

and set up the additional fields you want.

If anyone is looking to hack the adminbar so that when users log in, they stay on the current blog they’re on, just edit the bp-core-adminbar.php file and change the reference to $bp->root_domain, under the “log in and sign up links” section, to $current_blog. Also, I took out the redirect as well. So, my login widget now looks like this:

// **** "Log In" and "Sign Up" links (Visible when not logged in) ********

function bp_adminbar_login_menu() {

global $bp;



if ( !is_user_logged_in() ) {

echo '<li class="bp-login no-arrow"><a href="' . $current_blog . '/wp-login.php">' . __( 'Log In', 'buddypress' ) . '</a></li>';



// Show "Sign Up" link if registrations are allowed

if ( get_site_option( 'registration' ) != 'none' ) {

echo '<li class="bp-signup no-arrow"><a href="' . bp_signup_page(false) . '">' . __( 'Sign Up', 'buddypress' ) . '</a></li>';

}

}

}

catincoach-

This thread is very outdated. A lot has changed in BuddyPress since this thread last had activity 3 months ago.

If you are simply looking for where you can change the text of the menu buttons “Home”, “Blog”, “Members”, “Groups”, “Blogs”, then it is found in the header.php file of both the home and member themes.

I have read that I should follow the “BuddyPress” option under “Site Admin” menu, in order to change the member theme.

That is outdated information. If you are using BuddyPress 1.0 and have the bpmember folder installed in /wp-content/bp-themes/, then what I described is correct.

Log in to WPMU’s backend as site admin, then go to “BuddyPress > General Settings > Select theme to use for BuddyPress generated pages”. After selecting a member theme, make sure you hit the “Save Settings” button.

There is no option called “BuddyPress”, under “Site Admin” menu.

That is correct.

BuddyPress has its own menu grouping found at the very bottom of the menu group column. It is just below the Settings menu grouping.

@Staceyk18,

If you mean the buddybar (grey) at the top of the page, you can change it by going into:

wp-content>plugins>buddypress>bp-core>bp-core-adminbar.php

and

wp-content>plugins>buddypress>bp-core>css>admin-bar.css

If you want to add menus to the login bar, you’re better off setting up a bp-custom.php, this thread will have details on what to do (read thru the whole thread):

https://buddypress.org/forums/topic.php?id=2186#post-12003

Firstly I notice that your Avatar cropper javascript is failing on registration. Also looks like bits of your site are missing, and messing with the BuddyBar (sub-sub menus aren’t appearing on hover.)

Otherwise, it’s working the way you have it setup. If what you’re asking is “why doesn’t my home theme look like testbp.org” it’s because you didn’t change your active home theme in WordPress.

Not sure what’s up with your member theme though. Might be missing some files or have some funky CSS or JS somewhere. Haven’t really looked into it for you.

Lo.

> Why is it when I add a page to my WordPress site, it doesn’t show up in my BuddyPress navigation?

Because that’s just the way the default home theme is written. The items listed on that menu aren’t ‘Pages’ in the WordPress sense, anyway, so it makes little sense for the default, out-the-box BuddyPress theme to do that.

The bit of code you’d need to change (or to add in your custom/duplicate theme) is in header.php. Where you see:

<ul id="nav">

Add this underneath:

<?php wp_list_pages('title_li=<h2>Pages</h2>' ); ?>

Documentation for that function is at https://codex.wordpress.org/wp_list_pages

We’ve unhooked the current fns and hooked up our replacement fns. So far they do exactly the same thing as the current fns. We need the ability to decide who gets to see the menu item. I choose to create yet another fn to decide yes or no on blog creation.

function my_can_user_create_a_blog(){

if (is_site_admin())

return true;

else

return false;

}

That goes in bp-custom.php also. Ya, all it does is check if the current user is the site admin. I’m not sure what you mean by only letting ‘Admins’ create blogs. There are blog admins and one site admin. Everyone with a blog gets to have the wp role ‘administrator’. Not sure what you want so i’ve wrapped the logic in a fn so you can change it to whatever you like.

Now we need to alter our new replacement fns to skip the display of the menu items if that returns false.

In our my_blogs_setup_nav() there is a line like this:

bp_core_add_subnav_item( $bp->blogs->slug, ‘create-a-blog’ __(‘Create a Blog’,

‘buddypress’), $blogs_link, ‘bp_blogs_screen_create_a_blog’ );

We need to wrap it like this:

if (my_can_user_create_a_blog()){

‘bp_core_add_subnav_item( $bp->blogs->slug, ‘create-a-blog’Create a Blog’,’buddypress’), $blogs_link, ‘bp_blogs_screen_create_a_blog’ );

}

Also the function my_adminbar_blogs_menu() has code that looks like this:

echo '<li' . $alt . '>';

echo '<a href="' . $bp->loggedin_user->domain . $bp->blogs->slug . '/create-a-blog">'

. __('Create a Blog!', 'buddypress') . '</a>';

echo '</li>';

You need to wrap that the same way:

if (my_can_user_create_a_blog()){

..all that stuff..

}

Okay, putting aside the subdomain versus subdirectory issue for a second, you state that:

…the bp link in the menu works but where is says “disbale components using below form” nothing shows

It sounds like BuddyPress is not activated. With the 1.0_RC2 changes, BuddyPress is now considered a single WPMU plugin. You must first login to the WPMU backend as site admin and then go to Plugins > Installed and make sure that BuddyPress is activated.

Once it’s activated, a new menu group is created at the bottom of the menu tree called “BuddyPress”. You click on BuddyPress > Component Setup and you should see that all the BP components are enabled by default. It is in this admin screen where you can enable and disable individual components.

If you’ve already activated BuddyPress, then something is clearly wrong. Have you double checked to make sure that you copied all the BP component files and folders (minus the theme folders) into the /wp-content/plugins/ folder? Did you install the BP suite into the /wp-content/mu-plugins/ folder instead?

If the BP install locations and files are in their proper place, then I would recommend deactivating BuddyPress then deleting the entire BP directory and try reinstalling the BP plugin suite again and see what happens.

Here’s two functions that change the way the admin bar displays user blogs.

// sort array of blog objs by $blog->role according to the order of $blog_roles

// roles not included in $blog_roles array will not be displayed

function filter_blogs_by_role($blogs){

global $bp, $blog_roles;



$blog_roles[] = __( 'Admin', 'buddypress' );

$blog_roles[] = __( 'Editor', 'buddypress' );

$blog_roles[] = __( 'Author', 'buddypress' );

$blog_roles[] = __( 'Contributor', 'buddypress' );

$blog_roles[] = __( 'Subscriber', 'buddypress' );



// get roles

foreach ($blogs as $blog){

$blog->role = get_blog_role_for_user( $bp->loggedin_user->id, $blog->userblog_id );

}



// eliminate roles not in $blog_roles

foreach ($blogs as $key => $value){

if (!in_array($value->role, $blog_roles))

unset($blogs[$key]);

}



// sort by $blog_roles sequence if there are any left

if ($blogs){

usort($blogs, 'compare_roles');

}



return $blogs;

}



// i love php.net. stolen from php.net usort manual, user mkr at binarywerks dot dk's

// contribution for priority list comparision function.

function compare_roles($a, $b){

global $blog_roles;



foreach($blog_roles as $key => $value){

if($a->role==$value){

return 0;

break;

}



if($b->role==$value){

return 1;

break;

}

}

}

You can put those two fns in your bp-custom.php file. The fn filter_blogs_by_role() does the work and the fn compare_roles() is just a helper fn.

filter_blogs_by_role() takes the array of blog objects returned by the fn get_blogs_of_user() in the admin bar’s bp_adminbar_blogs_menu() fn. It first gets all the roles for the user’s blogs and then removes all of the roles that are not listed in the $blog_roles array. That way you can eliminate some roles such as ‘Subscriber’ if you want. Next it sorts the blogs by the sequence of roles defined in $blog_roles. However you list them in that array is how they will display in the admin menu.

1) So, put those two fns in bp-custom.php

2) Arrange the roles defined by $blog_roles in the fn filter_blogs_by_role() however you want the roles to appear in the menu

3) Comment out the roles you do *not* want to appear in the menu

4) Put the call to filter_blogs_by_role() on line 133 in bp-core-adminbar.php like this:

if ( !$blogs = wp_cache_get( 'bp_blogs_of_user_' . $bp->loggedin_user->id, 'bp' ) ) {

$blogs = get_blogs_of_user( $bp->loggedin_user->id );

wp_cache_set( 'bp_blogs_of_user_' . $bp->loggedin_user->id, $blogs, 'bp' );

}



$blogs = filter_blogs_by_role($blogs);

Just in case the forums trash the code I also stuck it here: http://pastie.org/445729

There were some changes to the header.php file. Off the top of my head, I cannot remember if both the buddypress-home and buddypress-member themes had changes. Or, if only one of them had changes.

Either way, the best thing to do is open your header.php file and compare it to the new header.php file of the respective BuddyPress theme.

If I have the Blog-Menu in my theme – the bp_home_slug doest point to the right page (the home-blog) but to an article in another blog…

It should be BP_HOME_BLOG_SLUG, not BP_HOME_SLUG.

Hi Tutsie,

This type of change would typically be done with a plugin. Keep in mind that this isn’t a BuddyPress customization as much as it is a WordPress MU one.

I did a quick Google search for “change wordpress admin profile link” and found a few places you could start.

In this WordPress forum topic is some code that would change the behavior of the profile link (albeit for a different reason); this method of changing the admin behavior isn’t recommended, however, since it requires hacking a core file. A plugin would be much better since it doesn’t require changing the core file (and having to stress about updating your WordPress MU code later).

Depending on how much you want to work on this, you could download these two plugins: WP Hide Dashboard and Admin Menu Management, open them up in a text editor, and look at how they change the menus in the WordPress admin area.

Plugins do two things: (1) they provide a new functionality and (2) they hijack the normal WordPress behavior and perform the functionality described in the plugin instead.

Hope that helps…