BuddyPress.org

… its for LOGIN not Registering.

logging in yeah, i can use it but first I need users with an email as username

That’s just a matter of restructuring the registration form (version 1.0 now, currently upgrading to 1.1.3). You can autogenerate the username from the fullname using this javascript trick and then hide the username field.

Hacking core files to actually put email addresses in the username fields in the database is a recipe for disaster. Why do you want to do that? What am I missing?

I once posted a forum article about having profile information in the registration-mail to the admin, when a new member registers. We couldn’t accomplish that, but a friend of mine made it possible to have a direct link to the members-profile. That’s one click away and helps me very much, so that I don’t have to search for them. Here is the code, just put it in a php-file and in the mu-plugins folder:

<?php

/*

Plugin Name: My Register Form

Description: Customisations for the Registration Form

Version: 0.1

Author: Marc Cawood

*/



// Custom Message in Registration Mail

add_filter( 'newuser_notify_siteadmin', 'my_newuser_notify_siteadmin');



function my_newuser_notify_siteadmin($msg) {

global $current_site;

// Extract member name

$member = substring_between($msg, ': ', "n");

// Link to member profile

$member_url = clean_url("http://{$current_site->domain}{$current_site->path}members/".$member."/profile");

return $msg . "nn" . $member_url;

}



function substring_between($haystack,$start,$end) {

$start_position = strpos($haystack,$start)+strlen($start);

$end_position = strpos($haystack,$end);

return substr($haystack,$start_position,$end_position-$start_position);

}



?>

I’ve noticed probably the same problem.

Buddypress has no welcome email by default. You can remove the Buddypress function that kills the welcome email, but then the password in the email is wrong.

I don’t believe this is a WPMU issue. It must have something to do with Buddypress’ changes to the registration process. And I’m also pretty sure that themes have nothing to do with how a password is grabbed from the database and put into an email.

Plugin page (on wp.org) says,

1.Upload the bp-registration-options folder to the plugins directory in your WPMU installation

2.Activate the plugin

3.Click on the “BP Registation Options” link under Settings.

4.Configure your BuddyPress registration options.

it’s possible that they’ve somehow managed to get your database information from the config file, and they’re posting the new registrations directly to the database, you may need to change the database password

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.

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.

Why not do the following (as we have) …

1. username

2. 1st name

3. last name

4. display name (the bp required field)

Because it’s not necessary. The goal should be to keep the registration form as short and simple as possible and not annoy new users.

Look at the registration process on Facebook, LinkedIn, etc. Most have:

First Name:

Last Name:

Email:

Password:

I use a javascript trick generate the username from the fullname in a hidden field – I can use email as username thanks to this plugin. Since BP has a built-in fullname field I’m stuck with splitting that out in firstname and lastname.

I have considered using fullname for firstname and creating a field_2 for lastname, but that causes all kinds of other issues.

Unfortunately there is no check/validation on what’s entered in the fullname field. The input is also not cleaned up to get capitals on the first letters and small caps on the rest. So the input could be anything, often just a first name or even ladiesman269.

Which undermines any reason of having that required fullname/display field in the first place…

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.

You have to do that straight from the registration form, to make sure that the data is there where/when you need it. That is basically what my function does. If you can get it to work. Apparently it doesn’t for Dan Butcher.

Now, with the (lame) fact that WP user table is actually different (not sure why it wasn’t co-opted for BP purposes)

That had mystified me since last Spring, but here’s Andy’s reason.

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.

i just installed this system, and yes it send the validation email, so the users may be compromised in error…

on my side i added a TOS plugin *(my own), so people have to check it and the input name have a name the bots are not recognising so they do not check it before registration…

Hey Brajesh,

I just checked out the auto-activate plugin and I can confirm what Pierre said that it does send an activation email even though the user account is already activated.

Also, I just checked out buddydev.com since you have the plugin running on your site and I’ve noticed a lot of spam registrations there!

Perhaps you need to add some anti-spam prevention of some kind to your BP install.

And also, as a courtesy, on the plugin release page, you should add a warning to enable some type of anti-spam solution on the user’s BP install (particularly in production environments).

Code should be free under the GPL, but support has value. Unfortunately it’s difficult to charge people for your time through a website, which is why developers tend to charge for code or put up a paywall.

Someone make a BuddyPress site where your paypal is part of registration, and every time someone in the developer group marks a forum topic as resolved, it invoices paypal for $1 from the topic starter.

That, would be the best way to make money as a dev without freelancing or consulting, in my opinion.

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.

Does the “Only logged in users can create new blogs” option in the WPMU admin not do this?

Nice, Brajesh!

Have you updated your auto-activate plugin lately?

In your comments, you mention you were going to update the plugin in November, but the last update was in October.

Also, has using this plugin affected spam registrations for you, Brajesh?

@Bowe: I am aware of the user moderation plugin… but I did not know about it’s “join groups upon registration” feature. That’s pretty cool! I’d still be relying on people to actually click those checkboxes though. But that would significantly reduce the ‘friction’ involved in getting people into the right groups. Thanks!

Like you… I’d still like to have a way to have a group that everyone belongs to automatically… without any choice in the matter. Auto Join will hopefully do that for me, but……..

@Mike: I’m running BP1.2-rare on my development box and the plugin doesn’t seem to work. Andy says there will be a compatibility layer or plugin when 1.2 goes public. So maybe it will work then.

David have you seen this plugin:

http://buddypress.webdevstudios.com/blog/2009/11/13/buddypress-registration-options/

It pretty much does what you want and helps jumpstart your community.

What I would like to is some kind of option for an admin to create a group which not gets listed in the users group list but the member is actually part of (without choice) and receives updates from. Something you might call a “sitewide group” or something!

@anointed

Check out “/wp-admin/users.php” and snag the code from there. It should give you more than enough examples on ways to filter the users on that specific site. I think it should include pagination, user type, etc…

The key for you will be making sure that the right members are subscribers of the correct site. If you have multiple domains or multiple registration pages (for each site) that should be pretty straight forward.