BuddyPress.org

Those pre-built fields were removed in BP 1.1 due to being buggy. Expect to see something like this coming back for 1.3.

@Mike Pratt

I think from a development perspective, it was easier to avoid the WP profile entirely, since it’s far too limited in what you can do with it. Like you can’t (in the DB) easily tell the WP profile screen which dynamic field type to use for each dynamic field. Since BuddyPress took the direction of being entirely theme based, it made sense to make a whole new profile with a more direct apprach to setting the fields and getting/updating the data.

For 1.3 there will be a more powerful xprofile system that makes for smarter fields.

seriously, @Peter, you give yourself too much credit.

I would, however, be curious to know if there is a reason bp didn’t make use of the rudimentary profile fields already available through WP? If it was inadvertent, that’s fine, but if there was a deliberate reason, Id’ find that of interest.

The first way is for users that may have been registered before BuddyPress was installed. They can still login, post comments, and use the forums, but if they never edited their profile and set their display name(fullname), BuddyPress won’t find them.

The second is if a user edits their profile from the WordPress side (firstname, lastname, nickname) without changing their BuddyPress display name. At that point the two will be out of sync.

It’s possible to hook into the save profile action of WordPress and change the BuddyPress display name when the user changes their WordPress nickname, but some sites may want a combo of the firstname/lastname while others may want to use the nickname, and others still may not really even care or use either. From that perspective it makes sense to not have BuddyPress try to interfere too deeply with syncing profile fields that might not have a direct 1 to 1 relationship with each other.

This is great, the what i wanna do next is show certain tabs (profile groups) to different member levels.

I saw there’s a function called profile_group_tabs. is there a way i can perhaps play around with this?

@Mike: you are saying that from BP 1.2 you can display user info (xprofile fields) into member blogs? So you could create a widget on a blog which would display basic info from the author (BP avatar + xprofile fields_

That would be great, but I’m not sure if that was what you meant to say!

@Andy I think the central issue is that WP and BP store member info separately. For the uninitiated, it means that comments on blogs on a BP sire will not show the same profile info as comments on forums, etc. b/c the blog gets it’s info from the Wp table. So if you go into my admin on my site, none of the info is filled out except email and username, altho there’s AIM, website, First Name etc. But none of that is made avail into a BP install. On my site, the blog comments say ” username” commented….. instead of “Display name” commented.

Additionally, if WP has all those user fields, why are they not exposed to BP already? That’s what is being talked about. So I am writing functions to sync up that data.

As much as I agree that you want to keep it simple, the last thing I want to do is a. auto-generate usernames (you have to tell them and they have to remember – let them decide)

They don’t in my site. They log in with email address. The only reason to still have an (autogenerated) username is because you need it for the URL.

parse a field into various name fields (parsing is just begging for errors – too may what-ifs) … But look deeper: they then auto-generate a username. why? who knows … Additionally they auto-gen a drop down list of “display names” … So what’s the diff between me and FB?

Also not much difference between me and FB. The difference between your solution and FB is what the user actually sees on the registration form. I don’t believe a new user will be all that interested in those extra choices.

I hearby declare it off limits to refer to Andy’s decision not to include firsname/lastname ever again.

It’s not up to you to decide what the limits of discussion are. You may get it, but until Andy/WP/Automattic gets it I’ll keep bringing it up. I like the features WP/WPMU/BP offers, there are really no alternatives for those, but they need to get central member management and the database structure up to standard.

As much as I agree that you want to keep it simple, the last thing I want to do is a. auto-generate usernames (you have to tell them and they have to remember – let them decide) or b. parse a field into various name fields (parsing is just begging for errors – too may what-ifs)

FYI – Facebook has you do the same 4 fields you mention you are doing. Fine. But look deeper: they then auto-generate a username. why? who knows since you always login with an email address. Additionally they auto-gen a drop down list of “display names”

So what’s the diff between me and FB? I let you pick your display name up front in addition to your username. Ideal no but better than the alternative…for me.

Bottom line is: let’s keep this discussion to how to do our own work arounds. The core way of doing does not appear to be changing. Fine (we can always leave the BP-sphere) Instead, let’s make it work.

I hearby declare it off limits to refer to Andy’s decision not to include firsname/lastname ever again. We get it.

Why not do the following (as we have)

1. Have 4 name fields in BP registration

1. username

2. 1st name

3. last name

4. display name (the bp required field)

Make them all required. We describe “display name” to everyone as “how you want your name to be viewed throughout the site’ If we had a choice, we’d get rid of it and mash 1st and last names together for display purpose. On the other hand, we have also seen many users do the following:

1. username -> jim1974

2. James

3. Smith

4. Jim Smith

Obviously, this allows for nicknames and with a little prodding, you get people entering nicer monikers than “ladiesman269”

Now, with the (lame) fact that WP user table is actually different (not sure why it wasn’t co-opted for BP purposes) All you have to do is create a function that writes the xprofile field values for 1st and Last name over to the WP table, in addition to setting the “display name value accordingly.

a thousand user later and no one has complained.

What does that plugin do? It has some vague requirements:

Create three news fields that will be used by the plugins (ex. “Member name”, “Member firstname”,”Member bothnames”). I suggest “Member name” to be a required field.

Fill the values of those fields for your profile (the datas for at least one user are needed to setup the plugin options)

Where are you supposed to create those fields? xprofile? In addition to the existing fullname field? You can already do that without this plugin.

wp_usermeta is nowhere in the plugin. That is the table WP uses to store firstname and lastname. Any solution in Buddypress should leverage wp_usermeta or at least synchronize with it imho. This plugin solves nothing.

If you’ve got a repeatable case of BP changes not syncing to the WP profile, please create a bug ticket on https://trac.buddypress.org/.

The problem Dan Butcher described looks like standard Buddypress behavior to me. It’s not a bug, it’s a feature, based in Andy Peatling’s design decision that firstname + lastname would cause international incidents.

Below again my hack as I use it in my sites, minus creation + update of a fullname-derived username for user_login, user_nicename, user_url and integration with a mailing list script I use:

function synchro_wp_usermeta($user_id, $password, $meta) {

global $bp, $wpdb;



$uid = get_userdata($user_id);

$email = $uid->user_email;



$fullname = $meta[field_1];

$space = strpos( $fullname, ' ' );



if ( false === $space ) {

$firstname = $fullname;

$lastname = '';

} else {

$firstname = substr( $fullname, 0, $space );

$lastname = trim( substr( $fullname, $space, strlen($fullname) ) );

}



update_usermeta( $user_id, 'nickname', $fullname );

update_usermeta( $user_id, 'first_name', $firstname );

update_usermeta( $user_id, 'last_name', $lastname );



$wpdb->query( $wpdb->prepare( "UPDATE {$wpdb->users} SET display_name = %s WHERE ID = %d", $fullname, $user_id ) );



}

add_action( 'wpmu_activate_user', 'synchro_wp_usermeta', 10, 3);

I have this code in bp-custom.php or functions.php, not as a plugin. Adding a plugin header could have caused Dan Butcher’s error messages.

BTW, I’m still looking for code to validate the fullname input for at least a two part name, so make a space required. I now get a lot of users only entering a first name. In that case the lastname field in wp_usermeta will stay empty.

I know this is a little back from the dead, but I would go about this in a totally different way myself.

I would use good old WordPress usermeta, and have three different registration screens. Giving users the ability to choose something will more often than not confuse them. If you give them a dedicated registration with only the options they need, that will yield better results.

I have a post around here somewhere on how to assign usermeta values directly from registration. Then rather than trying to group users together, rather than wasting a profile field that you eventually have to hide or prevent users from changing, and rather than creating custom user role types, you can just check the meta and go. And if they upgrade their account, you just update the usermeta value.

Custom user roles is a good idea too, but it comes with a little more work to make things cooperate the way you want to use them.

Also check out Role Scoper which now has good support for WPMU. I’m doing the same thing, but was hoping to use Role Scoper and BPContents to achieve the same.

We were discussing displaying single xprofile fields here.

Someone gave me this function:

function custom_xprofile( $field ) {

echo bp_custom_get_member_list_xprofile_data( $field );

}

function bp_custom_get_member_list_xprofile_data( $field ) {

global $site_members_template;

return xprofile_get_field_data( $field, $site_members_template->member->id );

}

So you can use this in the members index.php:

<p><?php custom_xprofile('Company') ?></p>

But it only works in members_template. I’d like to have a function for xprofile fields that works anywhere…

Haven’t had time to try variations on this one. Suggestions very welcome!

@Anton Koekemoer, I’m pretty sure the key would be in replacing $site_members_template in the function, but I wouldn’t know with what.

EDIT2: Here’s the thread where I originally got the function, from John James Jacoby.

How did this turn out? What steps did you take to make it work?

I am creating a site with a similar need. I will have 2 roles – employers and job seekers. I would like to display different fields for each role’s profile and also allow them to pick their role on signup. Any tips?

In my opinion, the downfall of this plugin is that it uses JS to hide xprofile fields that store the lat and lon instead of just using user-meta. That and it just works a little strangely, and I couldn’t really figure out why I wasn’t comfortable with it.

I’ve got a re-engineered version of this plugin I’m using for a client at the moment, and will probably give that code back to the devs of this plugin to be reused for later.

Thanks. That clears things up. The only other problem I’ve encountered is after I deactivate the BuddyPress plugin and re-activate it, I’ll get the follow db errors:

WordPress database error: [Duplicate key name ‘useritem’]

ALTER TABLE wp_bp_notifications ADD KEY useritem (user_id, is_new)

WordPress database error: [Table ‘wp_bp_activity’ already exists]

RENAME TABLE wp_bp_activity_user_activity_cached TO wp_bp_activity

WordPress database error: [Duplicate entry ‘1’ for key 1]

INSERT INTO wp_bp_xprofile_groups VALUES ( 1, ‘Base’, ”, 0 );

WordPress database error: [Duplicate entry ‘1’ for key 1]

INSERT INTO wp_bp_xprofile_fields ( id, group_id, parent_id, type, name, is_required, can_delete ) VALUES ( 1, 1, 0, ‘textbox’, ‘Name’, 1, 0 );

Thanks for further explaining yourself JJJ, and I like the general concept behind a lot.. But the idea that speaks to me the most is making BuddyPress in general more flexible and not “hook” into the group API but make a new one based on that which can not only be used for groups but also for users (and thus friends options).

The idea to make a general API which can be hooked in by the Core components and 3rd Party plugins seems to me the best solution. If you take the group API for example and use it’s functions for individual users:

– Add extra signup pages/fields

– Add new pages

– Add new navigational items etc

All these things are possible with the Group API but take lots of work with a regular profile. Like MrMaz said you could break these functions into smaller parts which can be called upon and extended upon for Groups, Users, Friends and the Activity stream.

The amount of possibilities for new plugins would be endless Once again I’m no programmer and this is coming from as a site admin/BP enthousiast/”Copy and Paste and pray to god I don’t get a white screen of death” kinda guy..

edit: I would also like to say that Mike perfectly summorized my exact ideas of what a group should be and what a group of friends means. Well spoken. I’m getting a Deja Vu here lol

I’d like to know as well. I’m not a php programmer. I’d noticed this function is specific for the members template, index I guess.

global $site_members_template;

I guess we need to add a global there. Or replace it in a separate function. I’ll try some things as soon as I have time.

Ideally I’d like to have a function that works anywhere in the theme…