BuddyPress.org

You can search here for answers :

https://trac.buddypress.org/report

To be honest you aren’t going to get much/any support based on bugs in previous versions of BuddyPress as we may have fixed them in the more recent versions.

Is it possible to have the welcome email include the RIGHT password? (i.e. the password that was entered upon registration)

Any idea how?

“limit blogs plugin is set to 1”

That’s where it goes awry. Remember that your members already have 1 blog – even as a subscriber to the blog where your BuddyPress is installed, that is counted. So increase Limit Blogs to 2 so that in addition to main blog as subscriber or whatever role you made them to be, they can create one new blog for themselves.

hi Philipp

sorry, Missed it , will be adding the post tomorrow and drop here a link. Thanks for the message and pointing here. Do you want to see that with bp 1.2 or bp 1.1.3

@Peterverkooijen

I s’pose you’re talking about the 20 minutes I said it took me to code the bits with the registration in my earlier comment? Why’s that worrisome? It just shows how fast you can get results with BP. Would you rather work with a piece of software where you’d need three times as long for something as simple as what I did? Then, may I suggest Joomla?

You keep saying you’re not interested in programming and don’t really know it. That basically means you talk an aweful lot about things you really don’t know that much about…

…if a program doesn’t have the logic you require

That is the key for me. Buddypress misses a lot of things that I think should be part of the core. I’m not asking for features like galleries and event management, but basic standard member registration stuff, getting data to/from xprofile, etc. BP is still very new of course, but this attitude that, “hey, you can program it in 20 minutes” is worrisome. Andy has also made some comments that suggest separation of logic, data and presentation is not exactly a priority for him.

If you want to learn PHP…

I really don’t…

I don’t have the time. I can’t afford it. I’m on the content/publishing site. I don’t make any money from web development, although I’m kinda forced into a career change recently…

https://buddypress.org/forums/topic/when-asking-for-support

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.

Will this type of functionality – multiple user types stored as usermeta, two-stage registration process – ever become part of the core? Is it on the roadmap?

Many site developers are not php programmers; they know html/css with perhaps a bit of jquery and php customizing skills, but not enough to code it in 20 minutes.

@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

I would like to bring up this topic again, as it is very crucial to the development of my website and I want to see if there have been any updates in the 10 months since this was posted. Right now I have blogs disabled, the main purpose of the site is to have different types of users interact on the site, and be able to search the site based the different details in their profiles..

Multiple profile types:

For my website I would like to have 4 profile types, all profiles have the same permissions, they just have different details listed in their public profile. These details can be defined during the registration process.

2-Stage registraion:

When the user decides to register, they are prompted with a page where they will select their profile type. Upon selecting their profile type, they will be taken to a second part of the registration process where they will fill in their profile information, each type of profile having a different form to fill in.

This should go along the lines of what Dev posted, minus the permissions. This is a huge hurdle for me to overcome, and if I can there will be one more addition to the Buddypress Community. Any help or direction is appreciated.

Add the function “add_user_to_blog( $blog_id, $user_id, $role )” to the registration.

There’s not supposed to be any generated password upon activation in 1.1.3. No passwords are ever sent by email in 1.1.3. You may have missed something in the upgrade.

We had noticed that the welcome email includes a wrong password, perhaps because of different encryption between WP and BP. The password that was entered upon registration still works.

Note that in 1.1.3 the WPMU is disabled by default. To bring it back you have to remove a function from the core files.

I’m trying to give this some thought. Frankly, users shouldn’t have to sign up unless there is some value to them for doing so. I will have different user types and each has different information requirements. I also want to use BP Geo so I’ll use Google ClientLocation as a starting point, but would like users to input that information too. Basically, I’m crafting the prompt for registration and more profile info based acknowledgement of the value proposition for that user type.

The plugin works with or without any other trickery; it uses the email in the database for authentication and ignores the username. Try it on an unmodified installation. Works fine.

The username is unnecessary. That’s why many modern sites don’t use them anymore. In WP/BP you still need something in the username database field because all kinds of functions rely on it, like the profile URL in BP or the ‘forgot password’ process. So you can’t just remove it entirely.

My solution is to generate a username onkeyup from the fullname via Javascript on the registration form, hidden from view. In an earlier attempt I used a script that just autogenerated a gibberish username.

You don’t have to convince me why it makes sense to use email address instead of username. This post was the start of a long a painful process for me. Trust me, that plugin does what you need and then all you need to do is restructure the form and pick a fix for the user URL etc.