BuddyPress.org

The name field was previously split into “First Name / Last Name” fields, but this is an issue for internationalization. In future versions it may be possible to apply rules to profile fields that will determine the content allowed.

That is such a silly argument. 90 percent of the civilized world uses firstname + lastname. Why make life difficult for the rest of us just because theoretically a few places in the world use only one name or three names or whatever? Why not let them hack a workaround it?

My issue with this is also not just about that field, but more about what it says about Buddypress’ priorities. If you want to register members in your company or sports club with name, address, phone number, etc. there is no easy way to do it, you’ll have to hack core files and later you’ll have to use custom functions to retrieve the data from several different tables in the database.

Also, BuddyPress will automatically synchronize profile fields with the WP profile fields. Check the function xprofile_sync_wp_profile()

No it doesn’t. Version 1.0 only added first name and last name to wp_usermeta if a user updated his account data after signup. You couldn’t count on the data to be there for every member. I had to write a custom function, based on xprofile_sync_wp_profile, to force that synchronization to happen upon registration.

BuddyPress is still very much a WP(MU) plugin. What it does best is create an instant social network around a community of bloggers … I don’t think this is a negative, but a positive.

I agree. That’s why I believe Buddypress has a lot of potential. It’s a social network, but with a strong content publishing angle.

I just wish that shift in focus from blog posts to “member management” would get more attention. Personally I don’t need any more new features. Adding forums for example only adds to the structural confusion. I’m still struggling with the basics, creating a user-friendly registration and profile settings interface.

The Dashboard of WordPress has gotten two complete overhauls within about the last year. The current version is awesome.

The WordPress admin interface is pretty good for what it has to do, but it is not what people expect when they sign up with a social network and it clashes with the front end interface.

Edit in response to Andrea_r:

P2 looks interesting. It’s an example of responding to user expectations and evolving interface “standards” on the web.

I agree. Buddypress is of course built on blog software WordPress, which has a totally different focus; managing blog posts instead of people/members. So BP is still a bit schizophrenic at the moment.

People do sign up on my network (aimed at web entrepreneurs…), because I’ve integrated event registration. They also sign up for groups and sometime leave messages. Nobody creates blogs or groups unless I ask them with detailed instructions.

Imho the WordPress backend should be entirely closed to regular end users. Any admin settings that they need should be integrated in the front end user interface, under Settings on the profile page etc.

My pet peeve is related to this; Buddypress has no build-in way to store full, real name, location and other regular personal profile data you’d expect from a social network. It’s still too close to the blog software base, with the focus on username/password and managing blog posts.

Ok. I’ve fixed it.

The mailer checks the domain name used. I won’t exted on this issue.

To let our local mailserver work correctly, we can do it by changing the validate_user_signup() function.

This function is located in: /wp-signup.php file, check it at the line 267 or something similar.

We must tell wordpress to consider valid our mail domain name without restrictions.

This can be done by modifying the user account check line:

We must replace the sentence

if ( $errors->get_error_code() )

by

if ( $errors->get_error_code() && $_SERVER[‘HTTP_HOST’]!“localhost.YOURDOMAINNAME” ).

Doing this, WP will accept any mail and user name if sent from our local domain.

Notice that WP won’t warn us about any registration error by doing this.

If you create by mistake an account, you can erase this sign up by editing the signup table in your wprss database using phpmyadmin.

I hope it can help anyone else.

I haven’t thought through how practical or difficult it would be to support the existing component structure. But, what if there was a base component class that all components extended (the way widgets extend the base widget).

In the child class you would need a registration process providing the component identifiers & possibly the URI to catch, activity logging, settings maintenance handler, a display handler, etc.

The end result would be that BuddyPress would become an activity based framework that the features plugged into.

@ Aufumy: The only paid registration system that comes close to your request is the “Supporter” plugin over at wpmu-dev. It’s a paid plugin though.

http://premium.wpmudev.org/project/supporter

GPL’ed software can be sold with no licensing problems. ‘Free’ as in freedom not beer.

http://www.gnu.org/philosophy/selling.html

I am wondering if buddypress has support for a paid registration system.

@Andy – A DB suggestion:

Make a register component api so that all components that are going to record in the SWA have to register. The registration process should occur at plugin activation and the component name strings are stored in a component table.

Once that is in place then you can eliminate the varchar component fields and replace with an int(11). This would reduce space in the table and improve lookup speed significantly when filtering.

@Greenkaos

I had already resolved the issue for @fd, after her mail on my blog.

This plugin is not for buddypress 1.1.x, It was pre 1.1, and still works with 1.0.3(if anyone uses that).

buddypress 1.1 has the same functionality built in core.So, This plugin is not under active development anymore.

hope It makes sense.

Thanks

Brajesh

Hi, just FYI. Doesn’t seem to work with WPMU 2.8.6, BP 1.1.3. Perhaps the author will update.

@Harry

Yes, my Privacy Component works just as I described. It is an advanced beta available for testing. See this thread for more details: https://buddypress.org/forums/topic/buddypress-privacy-component-an-update/page/3#post-30574

@David

I wouldn’t give users the option to set it to friends only. Or at least… I would like the site admin to have the ability to disable that option.

In my Privacy Component, the site admin can choose to disable this feature.

But, to get back on topic, I agree that the best solution is the one that requires the brunt of the filtering to be accomplished through invisible, behind-the-scenes techniques. Requiring users to prove that they are members and not bots should not be the first line of defense. I think it is okay, even necessary for registration purposes. But that is a one time occurrence. After that, the system should do more of the policing.

Concerning your second link above, perhaps we could create a new CAPTCHA that could harness the collective intelligence of site members to solve the Unified Field theory.

Hi DJ Paul.

as far as I can see, nobody is complaining that the sky is falling, that would be a quite silly thing to do. Well I guess technically it is, but at least the earth is stopping it from doing so

Just pointing out an inaccuracy in thinking, I am sure that this is allowed without immediately posting PHP to fix it?

Back on topic; the question should also be: how could this spammer get access to all the usernames automatically? Of course everybody is listed, but somehow the were harvested and added to the pm list.

– Anyway, I think a very good start is that you can only message your friends. Thought that this would be already ths case, that is why I wondered how we could get spammed?

– Additionally: a maximum of PM’s per user per x amount of time (seems that 1/minute should be enough, + 50 per day. of course this should be optional and configurable with error notification (site options or plugin?)

– Maybe a maximum mailbox size, which included sent messages. So that at least spammers have to clean out their sent box before being able to send new messages.

– Also a maximum of adressees per PM, else the other 2 are useless

– maybe a minimum age of user (meaning time since registration), before he can send out PM at all?

Of course, any of these can be worked around, but at least it might slow spam down, at least from strangers..

Cheers, Harry

Hi Andy, I think you are incorrect there. Spammers like to send spam. I am sure you get some in your email?

What is easier to get into a nice big community (without having to create a blog) and easily (?) send spam PM to all members of the community? You don’t even have to infect computers, as you can use the internal messaging system and you know most users will get the message as an email as well.

Hey, it saves them from email harvesting or buying ‘5 billion email addreses’ dbases as the community has already done this.

So, no, apparently (and this example that started this topic has proven this), it is possible on BuddyPress and it serves the spammers purpose, so disabling blog registration will not stop this. You can disable blog and user registration, but it might be hard to start a community that way..

Cheers, Harry

try this one. I had written about it in forum, so you can find it by searching the forum. Or check my post here

http://www.thinkinginwordpress.com/2009/11/tweaking-the-registration-link-at-wpmu-login-page-to-point-to-buddypress-registration-page/

That should do the trick.

Thanks

Brajesh

Spam is generally only a problem if you have blog registrations on, spammers only care about creating and spamming on blogs. I think some work will be done on this, but it’s not going to be on the BuddyPress side.

@Seobrien, can you confirm that you were looking at the site users and not the blog users?

It’s a common mistake to think that users don’t exist because at first you naturally check “settings->users” instead of “site admin->users”. The first is only showing you users on the blog you’re looking at, the second will show you users on your site.

I can’t think of a circumstance where a user could somehow function through-out the site without a user account. Even if there’s a misalignment of data between BP and WP, if there’s no WP account, they can’t login. Also, they cannot login simply with an incomplete registration in WPMU (wp_signups), since the login page checks only the (wp_users) table.

@nexia, if you are duplicate this phantom registration method on any WPMU or BP installation, I’d love for you to PM me the steps so we can help patch the issue.

I’d give them the choice during registration, then store that value as usermeta and check for each bp-component for that value and then either display the contents of that component or a nice little reminder with a link to upgrade their account.

Not sure how well roles would work as you can have different roles in different blogs.

I posted this elsewhere but it now belongs as part of this discussion: When using Buddypress, should /wp-signup.php result in an blank page or the registration form (or redirect to /register)? If the issue described here exists, how do you get the proper default buddypress behavior?

see: http://ttacconnect.org/wp-signup.php

I could delete /wp-signup to remove the errors but I’d like to understand how bp and wpmu is designed to work (are there any consequences for deleting wp-signup.php?).

I know BuddyPress is using /register.php and not /wp-signup.php. But when /wp-signup.php is hit (typically by spam bots) a PHP Warning is generated. No white space outside of php closing tags in header.php. I’m not too concerned about that as I figure if it’s working as it should (no registration form), then the php warning will take care of itself (and not be generated). So what needs to change to get /wp-signup.php to result in a blank page?

PHP Warning: Cannot modify header information – headers already sent by (output started at xxxx/bp-sn-parent/header.php:3) in xxxx/wp-includes/pluggable.php on line 865

See no Warning and no Registration Form (blank page). Is this the proper default buddypress/wpmu behavior?

http://nourishnetwork.com/wp-signup.php

Here /wp-signup.php was deleted and results in a page not found:

http://memomu.com/wp-signup.php

wpmu 2.8.6 with active plugins on main bp site:

bp 1.1.3, bp-groupblog, auto group join, Group Forum Subscripton, bad behavior

No need for a plugin… just make your own copy of the registration template in your child theme and delete the optional fields. Or maybe even just use CSS to hide them.

Since this is a cosmetic issue, as you indicate above, why not simply change the subject message. It may also help make registration emails from your site look even less suspicious than they do when they contain a link.

So, hardcode the subject message to say something like this:

Your New Bugle Notes Account is Ready to be Activated

Anyone have any luck using sign-up question or wpmudev’s sign-up code? They both work great on a regular MU install since the person signing up has to answer a logical question or enter a code that they have received previously. The problem is when you activate those plugins, they work on the WordPress registration page and not the BuddyPress Registration page. Those would likely solve all the problems if we could get them to work together.

I’m developing a site that we want only approved, or in some cases paid members to be able to sign up, but I can’t get either of those plugins to work with BuddyPress. Anyone been able to do that, or know how it would be done?

this is an easy hacking technique, i’ve done that 3 times yesterday when trying to create users/blogs…

you can delete these users by going in the _signups table… the problem is that WordPress is not taking into consideration the registrations that are not completed, they store them in the signups table and they can not be reached when you check for users… so when a user create an account with a blog, the whole process is created but not verified… you can then visit the site without being logged in and without a trace.

WP 3.0 is different in that technique… but i suppose we could find a tweak right now.

stwc’s summary of methods does seem to stop a lot of spam, but I’ve still been having some. I tried SI Capthca (https://wordpress.org/extend/plugins/si-captcha-for-wordpress) but that seemed completely ineffective.

My latest weapon in the war has been to modify Invisible Defender (https://wordpress.org/extend/plugins/invisible-defender) firstly to make it work with the buddypress registration page and secondly obfuscate its hidden fields by giving them random names and values:

http://bcbc.co.uk/mu/blog/2009/12/11/wordpress-registration-spam/