BuddyPress.org

It is already there.

But you may not edit the Fields which are stored by wordpress(If your User had registered before activating buddypress). Only Buddypress xprofile fields can be edited from profile page.

Under profile link, you will see edit profile which will allow you to change the basic details(xprofile fields).

Under settings->general you can change email/password.

The only thing you might want to look into is to show/hide specific xprofile fields for different groups. That’s more advanced and requires some new code to be written by someone

This is possible without too much effort, I have recently done it for a client. I considered using usermeta to indicate the type but it worked better for my client’s site to have it is an xprofile field. I wrote some code to not display or permit changes to it after registration, too.

Bowe, I’d store user types as usermeta. Might be a bit more work code-wise, but I think more flexible.

Showing certain profile fields by user-type with jQuery is just your basic conditional stuff. If this user-type is selected, then show these fields, if another type is selected show some other fields.

I don’t have a solution for all your problems but assigning different “user” types to your site is easy:

– Create a xprofile field in your BuddyPress admin. For example: What kind of user are you:

a. Swimmer

b. Skater

c. Surfer

– Install the BP Member filter plugin: https://buddypress.org/forums/topic/bp-member-filter

– Users can now filter members on the member directory page to find certain usertypes

The only thing you might want to look into is to show/hide specific xprofile fields for different groups. That’s more advanced and requires some new code to be written by someone

Good luck!

edit: Maybe if you combine both tips from Boris and me you just got your solution

ps: I’m interested in the jquery profile fields stuff as well.. sounds handy!

@psyber

You can just add to the existing registration process via the available hooks. So basically you add a dropdown field where the user has to select an option. Then you use a bit of jQueryness to display the various profile fields you want that user-type to fill in. I’ve done something similar for group types. Took about 20 minutes to code, so it’s not really hard

Yup- just as I thought.. in members-loop.php find-

<?php bp_the_site_member_last_active() ?>

and change to-

<?php echo bp_custom_get_member_list_xprofile_data('Gender') ?>

Where “Gender” is the name of the profile field you wish to display.

Threads been quite helpful for me so far..

I’m using Jet random members widget on the ‘members’ page and I’ve managed to get one of my profile fields to display there now, rather than a random field.

Here’s what I done…

In /directories/members/index.php find-

<?php bp_the_site_member_random_profile_data() ?>

and replace with-

<?php echo bp_custom_get_member_list_xprofile_data('Gender') ?>

where “Gender” is the name of the field you wish to display.

Then in bp-custom.php (in your plugins folder), add this:

//To add custom profile fiels to random members widget //

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 );

}

I’m working on a few other tweaks now to try adding this custom field to the actual member listing part of the page now and I imagine it will work in the same sort of way. I’ll keep you posted.

As for your other question, here are a few places to start:

1) Make a Gender field and a Enter the Competition field in Dashboard > BuddyPress > Profile Fields. Make sure they’re required on registration.

2) If by “top nav menu” you mean the thing that floats across the top of the screen, you can add to it by creating a button inside of a php function, then using add_action to attach the function to the bp_adminbar_menus hook. See buddypress/bp-core/bp-core-adminbar.php to see how it works in the core code.

3) Use a plugin like JJJ’s https://wordpress.org/extend/plugins/bp-member-filter/ to create the filters that will populate the pages that the “Men” and “Women” dropdowns will point to.

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.