BuddyPress.org

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…

I’m actually having the same issue as shaisimchi. I’ve been playing around with it, but haven’t found the solution. I only had some test users, so I tried deleting those and re-creating users. No dice. Any input would be great. Thanks!

@jamesyeah: I’m pretty sure the fields just need to be instantiated. I’m using a location field from the base group. It took me a while to figure out, but all I had to do was go into edit profile, add data to the field I wanted to use for the location, and select save. Then, that field will show up in the admin drop-down. (If you look at the PHP code, it checks that there is a value for that field. That’s how I figured out what I needed to do.)

Hope that makes sense. May not even be what you were talking about! : )

I got this solution here earlier. This in functions.php or bp_custom.php:

function bp_custom_member_list_xprofile_data( $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 );

}

And then this in the template:

<?php if ( $company = bp_custom_get_member_list_xprofile_data('Company') ) : ?>

<p><?php echo $company ?></p>

<?php endif; ?>

I didn’t come up with this myself. Forgot who deserves the credit…

EDIT:

BTW, this seems to work as well:

<p><?php echo bp_custom_get_member_list_xprofile_data('Company') ?></p>

Or am I missing something?

EDIT2:

Or further cleaned up:

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

}

In the template:

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

Sure, there’s a couple ways to do it.

If you want to turn off linking in specific profile fields (so that nothing in “About Me” gets linked, but locations in “Location” or “Hometown” do), you can use https://wordpress.org/extend/plugins/custom-profile-filters-for-buddypress/. Near the beginning of that plugin, there’s a spot for you to list fields that should NOT be linkable.

If you want to be more specific and look for certain words in a field, here’s how. Copy the original xprofile_filter_link_profile_data function from bp-xprofile-filters.php, paste it into functions.php or wherever you put the remove_filter code, rename it something unique (like henry_xprofile_filter_link_profile_data), then afterwards add the line

add_filter( 'bp_get_the_profile_field_value', 'henry_xprofile_filter_link_profile_data', 2, 2 );

At this point you’ll have to customize the filter to look for certain words. Use something like this (untested, but something like it should work):

if ( strpos( $field_value, 'Boston' ) ) {

$field_value = str_replace( 'Boston', '<a href="' . site_url( BP_MEMBERS_SLUG ) . '/?s=Boston">', $field_value);

}

In other words, if ‘Boston’ is found in the field, replace the plaintext ‘Boston’ with a link to a search on the word ‘Boston’.

This is my pet peeve with Buddypress! Wasted at least two weeks on this issue last Summer.

I use the same Beau Lebens email as login plugin that David Lewis found. So I wanted to get rid of username entirely and have basically only real name and email address on my registration form.

To integrate a mailinglist script I needed separate firstname + lastname. Buddypress doesn’t store them out-of-the-box. This is NOT a WPMU issue; WP/WPMU has firstname + lastname in wp_usermeta, but Buddypress simply refuses to synchronize those fields, so you can’t count on the data being there for other scripts (mailinglist, events, etc.).

Here’s my solution:

How to synchronize firstname+lastname between xprofile field_1 and wp_usermeta upon registration

And

How to autogenerate blogname (url) from Blog Title (or username from fullname!)

The Javascript I use for fullname->username looks like this

function copyinputuser()

{

var tmp = document.getElementById('field_1').value;

tmp = tmp.toLowerCase().replace(/^s+|s+$/g, "").replace(/[_|s]+/g, "");

tmp = tmp.replace(/[^a-z0-9-]+/g, "").replace(/[-]+/g, "").replace(/^-+|-+$/g, "");

document.getElementById('signup_username').value = tmp;

}

Unfortunately a lot of people sign up with only one name in the Fullname (field_1) field. Question:

Would anyone know how to validate/check the input for a two-part (minimum) name? You’d probably have to check for a space, make a space required. How would that script look?

No firstname/lastname because this does not work for a lot of international users.

Which countries are you talking about?! Name them.

With all due respect, this is such a bizarre argument. Not only the western world, but India, China, etc. all have no problem whatsoever using two or more names. Countries that use only one name or more than four can write their own plugins, along with the language pack etc.

More than two names is no problem; separating first and last name is primarily about having a first name available. Users can put their other two, three, four names in the second field.

If Facebook, LinkedIn, etc. have no problem requiring separate firstname and lastname, why is this such a controversial issue for Buddypress? Why make life difficult for 80-90 percent of Buddypress users just to prevent offense to 10 percent with different customs?

Just had a quick look. You might be able to just get away with changing the group_id field in wp_bp_xprofile_fields to the id of the new group. The data table only seems to be looking for the id field. You can do that in phpMyAdmin. Try it locally, though, first if at all possible.