[@peterverkooijen Participant 17 years, 3 months ago]

If during registration the user actually enters their fullname–which means that there is at least a single space between their first name and whatever comes after that–then this function will parse the datum and create first_name and last_name meta pair entries in wp_usermeta.

Making that required would solve a lot of problems and make the system a lot more consistent imho. As it is you can’t rely on wp_usermeta (or fullname…), so if you want real names you have to come up with complicated work-arounds.

The full name registration field is already required. Why not put some standards on it? At the moment it is unclear, to users as well, what this field is for exactly. Display name? Another username? A blog name? A blog URL name?

The function will parse it as follows, placing these entries in wp_usermeta:

first_name: John

last_name: James Jacoby

Nothing wrong with that. It’s handy to be able to use the first_name separately, but I can’t think of scenarios where I would only use the last_name.

Even if you wanted to use last_name by itself, you have to work with the information the user gives you. If the user wants to be a pompous ass and include his middle name, that’s his problem.

First name + last name is an issue for me because I have to import a members list where this data is separate. So I need to make a decision what to do with that.

You could do a check to make sure that there is at least one single space in the “Full Name” field before allowing the registration to be processed, but you will have no guarantees that they have used their real full name or that they have used just their first and last names.

Facebook and LinkedIn don’t have those guarantees either. From my existing 600+ members list, built with a PunBB-based registration form, I know that most people will give their full, real names if asked nicely – I did need to add some code to capitalize the first letters.

It depends on the etiquette of the site. If everybody is identified with their full names, new members will give their full names to be part of the club. That’s one reason why I dislike usernames. Emphasizing usernames teaches users wrong behavior, says it’s OK to identify yourself by BS pseudonyms.

[@peterverkooijen Participant 17 years, 4 months ago]

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.

So this synchronization only happens when users edit their profile after registration? Would it be possible to require the user to enter a more than one-word name in the fullname field and guarantee that synchronization with wp_usermeta always takes place on registration?

Or would it be easier to use the full name field for first name and add a custom field for last name?

(Please forget about the username issue. I’ll put that in a separate thread…)

[@peterverkooijen Participant 17 years, 4 months ago]

This particular request is a WPMU issue and has nothing to do with BuddyPress. I’m afraid there is nothing we can do here to help you, but I strongly encourage you to search the WPMU forums for a similar thread and post a new thread if you can’t find anything related.

It has everything to do with Buddypress. My question is about the relationship between Buddypress X-Profile tables and how WPMU handles first and last name. It’s about optional fields and how to integrate them into the registration process.

I do understand this concept and your desire to achieve this type of setup. However, as I said in my previous post, WPMU is blog-centric, not user-centric. The username field is actually what WPMU stores in the “user_login” field of the wp_users table. Therefore, the way WPMU currently works, this datum is mandatory.

This thread is NOT about the username issue. I use the wp-email-login that allows members to log in with their email address, but I understand the username is still mandatory. That’s why I would like to figure out a way to autogenerate it from first+last name.

Which brings me back to first and last name. Let me restate the question:

How does Buddypress handle first name + last name?

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? Or should I use Name as First name and create a custom field for Last name?

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 …”)

WPMU is blog-centric, not user-centric.

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

[@peterverkooijen Participant 17 years, 4 months ago]

So, my best advice is that you will have to do as Mike Pratt suggests and then code a custom function to extract the new firstname and lastname data from an xprofile table as you see fit, or just output that data in your theme files.

I’m not too worried about displaying firstname and lastname once they are in the database, whereever they end up. My problem is how to customize the registration process to get them there, trying to find the shortest route, avoid redundancies.

As far as registration, have you looked at Mike’s site (http://buglenotes.com/register) to see what he does? If that is what you want, you should PM him and get more advice.

That is exactly what I want to avoid! Username is still at the top. I want to eliminate that impersonal username as much as possible. I want a simple, inviting, natural registration form like this:

• First name
• Last name
• Email address
• Blog name (=username, preferably auto-generated from first+last name)

That should be enough! Additional optional profile fields would be on a next page or in the members account settings.

Mike’s site has too many required fields. I assume Display Name is the default full name field in Buddypress and that he just added the others as custom fields.

This form has username + display name + first name + last name; way too confusing and annoying to potential members. Totally unnecessary, but understandable since Buddypress/WPMU makes it almost impossible to do anything else.

[@peterverkooijen Participant 17 years, 4 months ago]

OK… So what does that mean practically?

[@peterverkooijen Participant 17 years, 4 months ago]

OK, upgraded to 1.0.2.

Deleting the earlier test users to “free up” some email addresses I can use for testing. Why do deleted members remain in wp_signups? Is that necessary?

Deleting those users manually in phpmyadmin…

Then testing registering with an email address that I had used before:

testuser

peter@testaccount.net

Peter Testuserman

The expected error message:

Sorry that email address is already used

Reloading register page.

mumbaitest

peter@mumbaiaccount.com

Raj Mumbaiman

Congratulations, you are now registered!

Your new username is: mumbaitest

And this time the full name on the account is Raj Mumbaiman. So I guess 1.0.2 fixed the problem.

Leaving this long post here for reference and comments…

[@peterverkooijen Participant 17 years, 4 months ago]

WordPress MU 2.7.1 + BuddyPress 1.0.1.

Was this issue fixed in version 1.0.2? I will upgrade, test and report back, but any info on this from your side is appreciated.

Clearing the browser cache should not be necessary. Regular users could try registering different accounts from the same computer as well. You can’t tell them to first clear the cache before trying to register.

[@peterverkooijen Participant 17 years, 4 months ago]

Group photo was simple guess. Change this:

<?php bp_the_site_group_avatar_thumb() ?>

to this:

<?php bp_the_site_group_avatar() ?>

[@peterverkooijen Participant 17 years, 4 months ago]

Thanks Jeff Sayre. Went with your solution of course. Less intrusive – my custom code hack already created this problem.

I assume for the group and blog pictures it will be something similar…?

[@peterverkooijen Participant 17 years, 4 months ago]

Same problem here. Just reinstalled everything with the latest versions, because my previous attempt used subdomains instead of subdirectories.

The avatar doesn’t get uploaded/created. The full name also doesn’t get stored.

EDIT: It worked on the second attempt, after removing some avatar related code from bp-custom.php…

[@peterverkooijen Participant 17 years, 4 months ago]

I can’t pass the member ID. It’s for the featured members loop on the directory page, something like this:

?php while ( bp_site_members() ) : bp_the_site_member(); ?>



<a href="<?php bp_the_site_member_link() ?>"><?php bp_the_site_member_avatar() ?></a>

<h3><a href="<?php bp_the_site_member_link() ?>"><?php bp_the_site_member_name() ?></a></h3>



<?php do_action( 'bp_core_directory_members_content' ) ?>



<?php endwhile; ?>

The function is in bp-core-templatetags.php:

function bp_the_site_member_avatar() {

echo apply_filters( 'bp_the_site_member_avatar', bp_get_the_site_member_avatar() );

}

function bp_get_the_site_member_avatar() {

global $site_members_template;



return apply_filters( 'bp_get_the_site_member_avatar', $site_members_template->member->avatar_thumb );

}

Would it be possible to write a variation on this function to get the big version? Replace ‘avatar_thumb’ with ‘avatar’?

Trying that now…

YES, replacing ‘avatar_thumb’ with ‘avatar’ does produce the bigger versions. So here’s an alternative function that works, put in bp-custom.php:

function bp_the_site_member_photo() {

echo apply_filters( 'bp_the_site_member_photo', bp_get_the_site_member_photo() );

}

function bp_get_the_site_member_photo() {

global $site_members_template;



return apply_filters( 'bp_get_the_site_member_photo', $site_members_template->member->avatar );

}

Or is there already a similar function somewhere in BP?

[@peterverkooijen Participant 17 years, 4 months ago]

I’ve split the function as follows:

function xprofile_add_signup_fields() {

global $bp_xprofile_callback, $avatar_error, $avatar_error_msg;



/* Fetch the fields needed for the signup form */

$fields = BP_XProfile_Field::get_signup_fields();



if ( $fields ) {

?>

<div id="extra-form-fields">

<?php

for ( $i = 0; $i < count($fields); $i++ ) {

if ( $bp_xprofile_callback[$i]['field_id'] == $fields[$i]->id && isset($bp_xprofile_callback[$i]['error_msg']) ) {

$css_class = ' class="error"';

} else {

$css_class = '';

}

?>

<div class="extra-field">

<?php if ( $css_class != '' ) { echo '<div class="error">' . $bp_xprofile_callback[$i]['error_msg'] . '</div>'; } ?>

<?php echo $fields[$i]->get_edit_html($bp_xprofile_callback[$i]['value']); ?>

</div>

<?php

$field_ids .= $fields[$i]->id . ",";

}

?>

</div>

<input type="hidden" name="xprofile_ids" value="<?php echo attribute_escape( $field_ids ); ?>" />

<?php

}

}

add_action( 'signup_extra_fields', 'xprofile_add_signup_fields' );



function xprofile_avatar_field() {

global $bp_xprofile_callback, $avatar_error, $avatar_error_msg;



if ( !(int) get_site_option( 'bp-disable-avatar-uploads' ) ) {

?>

<div id="avatar-form-fields">

<h3><?php _e('Profile Picture (Avatar)', 'buddypress'); ?></h3>

<p id="avatar-help-text"><?php _e('You can upload an image from your computer to use as an avatar. This avatar will appear on your profile page.', 'buddypress'); ?></p>

<?php

if ( $avatar_error ) {

$css_class = ' error';

} else {

$css_class = '';

}

?>



<div class="avatar-field<?php echo $css_class; ?>">

<?php if ( $css_class != '' ) { echo '<div class="error">' . $avatar_error_msg . '</div>'; } ?>



<label for="file"><?php _e( 'Select a file:', 'buddypress' ) ?></label>

<input type="hidden" name="MAX_FILE_SIZE" value="<?php echo get_site_option('fileupload_maxk') * 1024; ?>" />

<input type="hidden" name="slick_avatars_action" value="upload" />

<input type="hidden" name="action" value="slick_avatars" />

<input type="file" name="file" id="file" />

</div>

<script type="text/javascript">

jQuery(document).ready( function() {

jQuery('form#setupform').attr( 'enctype', 'multipart/form-data' );

jQuery('form#setupform').attr( 'encoding', 'multipart/form-data' );

});

</script>

</div>

<?php

}

}

add_action( 'signup_avatar_field', 'xprofile_avatar_field' );

Unfortunately it doesn’t work 100%. I was able to register a test user, but first name, last name and avatar were not stored.

With the old combined function first name and last name were stored correctly, so I must have made a mistake in splitting them. Where?

Comments + suggestions appreciated!

[@peterverkooijen Participant 17 years, 4 months ago]

There are already fields for first_name and last_name in wp_usermeta, so it shouldn’t be necessary to create custom profile fields for them in bp_xprofile.

How can I add these first_name and last_name fields to the registration form, instead of one “Name” field? And how could the one fullname be generated from first_name and last_name?

btw, this is standard across a lot of social media sites. Look at Facebook – aside from the fact that they login with email instead of username, they also have display name, first and last….just like BP can have

Exactly, but how?! Do I really have to get into complicated custom coding to get an “industry standard” registration process?

Where is that built-in “name & last name” feature that Nicola Greco mentioned?

[@peterverkooijen Participant 17 years, 4 months ago]

Following Mike Pratt’s suggestion I’ve added custom profile fields for separate first name and last name and made them required.

They now show up on the registration form, but there’s already the required field “Name” there.

Is there a way to autogenerate “Name” from “first name” and “last name”?

Aren’t separate first name and last name already a default part of the system somewhere? I noticed user management in wp-admin has separate first and last name fields. Where are they stored? Can’t I use that for the registration form as well?

Very confused…

[@peterverkooijen Participant 17 years, 4 months ago]

This seems to word for including a php file:

<? include get_option(‘home’).’/common/whatever.php’; ?>

And adding this to header.php in the theme also seems to work:

‘<script src=”<? echo get_option(‘home’) ?>/common/js/whatever.js” type=”text/javascript”></script>’

Best solution?

[@peterverkooijen Participant 17 years, 4 months ago]

Thanks! That’s pretty straightforward. I’ll use that a lot!

[@peterverkooijen Participant 17 years, 4 months ago]

I have to do something similar. Not looking forward to it…

I’ve found this plugin:

User Import for BuddyPress (All Fields)

To export member data from another WordPress installation you could use this:

Users to CSV WordPress plugin

Haven’t gotten to testing this yet, so let me know if it works…

[@peterverkooijen Participant 17 years, 4 months ago]

Generating the username from the email address is not ideal, because it’s also used for the blog URL – if you allow creation of blogs.

My first thought would be to generate username from the full name. Or leave the username field on the registration form, but rename it as “blog name” and move it down on the form.

Or a combination of both where the username/blog name field is not visible when you first register and you get a suggested blog name based on your real name when you register a blog.

[@peterverkooijen Participant 17 years, 5 months ago]

@David Lewis, I know. I use something similar a lot in my current site, based on PunBB. I’m not really a coder though, so ‘simply redirect’ will probably require trial and error.

Hardcoding in the navigation is a good suggestion. I could do that in template files, right?

[@peterverkooijen Participant 17 years, 5 months ago]

Thanks!

But as with the code in the other thread, I still need to figure out how to let the user no what is going on. I’ll get to it later in June…

[@peterverkooijen Participant 17 years, 5 months ago]

There are bits of code all over the place + several plugins for “privacy” or “member access”. I’m just trying to get people’s insights in what currently the best solution is.

I had tried a version of the code from the previous thread, but it had some problems in the redirect.

I will try to put something together again as soon as I have time, probably two weeks from now, and will post the result on this thread.

Sometimes I start threads as reminders to myself, issues on my to do list. Hopefully these threads will turn into useful documentation and summaries of solutions.

[@peterverkooijen Participant 17 years, 5 months ago]

Which is the final code? Does it include error message+redirect so the user understands what is going on?

[@peterverkooijen Participant 17 years, 5 months ago]

Would it be possible to extend this plugin to work for the members and groups sections in BP?

[@peterverkooijen Participant 17 years, 5 months ago]

Thanks for the clear answer John James Jacoby.

I vote and added a long comment. The registration process is the heart of the system imho. I really hope it gets upgraded to a more mature standard before even thinking about adding lots more ‘cool’ features and ‘widgetizing everything’.

A more mature, flexible and extendable registration system would dramatically broaden the possible uses of Buddypress.

[@peterverkooijen Participant 17 years, 5 months ago]

Is there a workaround? It’s pretty essential to have a registration form that makes sense to potential new members.

What is the best way to approach this now? Will the fields show up in the order they are created? Or backwards?

What are the chances that this issue will be solved before September?