BuddyPress.org

Last post from me on this thread, just for the record and to summarize, I support John James Jacoby’s vision 100%.

Restructering friending around groups and microblogging/activity stream is a next step in where social web is going. Groups would become extremely useful for all kinds of use cases. It would really set Buddypress apart.

Buddypress can’t be all things to all people imho. Development should focus on a conceptually coherent core, with APIs that make it easy to plug in other more linear functionality, like classic friending and forums.

Do we need to re-invent the wheel ?

Buddypress shouldn’t just copy Facebook – apart from perhaps the registration process… BP has the opportunity to do things different, better, move things forward.

TLDR version: Introduce types of groups. e.g. “User group” type – it has no forum, no “Home” page, just members listing and activity stream. This group added to Activity Stream filters where relevant.

Would have to filter out custom group type “User group” out of the /groups/directory page & member profile group page.

These custom group types could be set so they are publicly visible/private to those members involved/or hidden (visible to the creator only). As per current Group privacy settings.

Could add e.g. “Friends”, “Colleagues” and “Fans” as default, empty groups for each user on user registration. Obviously revise theme to make the “Friends” page (“Connections”, maybe) look like the Friends page rather than a regular Group.

Different users might create “User group” types with the same name but with different meaning (“Fans” could be interpreted several ways for example). This is no problem as such categorisation is defined — and belongs to — the user who does it. Might need some semantic group kind/type identifier in the code to allow FOAF/SIOC RDF profiles to be able to assigned to these “User groups”.

Do the user accounts come from the regular user registration process (i.e. not Facebook Connect) and can you please remind me where in the wp-admin you can set user moderation on new accounts?

That’s how BP works. There is almost no security, privacy and member management built into BP. The focus is on expanding features.

There are various efforts underway to bolt better management on via plugins etc. This plugin for example offers new member moderation.

Jeff Sayre is working on a privacy component, but apparently has decided he needs to be compensated – and rightly so!

The BuddyPress Registration Options is, indeed, a useful plugin. It does not work on 1.2 bleeding but hopefully will be updated

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?

I’ve tried this regular WordPress plugin for New User Email Setup, but it didn’t do anything at all for Buddypress activation.

This BuddyPress Registration Options has some very useful features that I probably need anyway, but it still doesn’t allow you to change the From and Subject lines. [username] seems to be the only available tag, not [fullname]. You can’t make any changes unless you check Moderate New Members.

Why is more control over the registration process not built into the Buddypress core? It’s essential to a social network imho.

Has editing the activation/welcome email become any easier in versions 1.1.3/1.2?

What changes have been made?

Is the pastebin code now obsolete? I’ve noticed in 1.1.3 the default setting (?) is that new members enter their own password on the sign-up form, so I guess the “you will receive *another email* with your login” no longer applies?

@Bowe

setting up different group types is fairly easy. You just have to attach some groupmeta to the group, that basically let you add as many types as you’d like. Then you just check the metadata to figure out what type of group you’re in. Using the groups API you can then add different functionality for different groups.

I’ve written a types-plugin for one of my sites. It doesn’t have an interface, though. The 3 types I needed are hardcoded into it, so it’s really not suited for a release at the moment. There’s also a lot of more stuff, like a shopping cart, part of that plugin. So, I’ve stripped the functions needed for group types out (hopefully al of them).

First we need to add the addtional fields to our registration form:

function sv_add_registration_group_types()

{

?>

<div id="account-type" class="register-section">

<h3 class="transform"><?php _e( 'Choose your account type (required)', 'group-types' ) ?></h3>



<script type="text/javascript" defer="defer">

jQuery(document).ready(function(){

jQuery("#account-type-normal_user").attr("checked", true);

jQuery("#group-details").hide();

jQuery("#account-type-type_one,#account-type-type_two,#account-type-type_three").click(function(){

if (jQuery(this).is(":checked")) {

jQuery("#group-details").slideDown("slow");

} else {

jQuery("#group-details").slideUp("slow");

}

});

jQuery("#account-type-normal_user").click(function(){

if (jQuery(this).is(":checked")) {

jQuery("#group-details").slideUp("slow");

} else {

jQuery("#group-details").slideDown("slow");

}

});

});

</script>



<?php do_action( 'bp_account_type_errors' ) ?>

<label><input type="radio" name="account_type" id="account-type-normal_user" value="normal_user" checked="checked" /><?php _e( 'User', 'group-types' ) ?></label>

<label><input type="radio" name="account_type" id="account-type-type_one" value="type_one" /><?php _e( 'Type 1', 'group-types' ) ?></label>

<label><input type="radio" name="account_type" id="account-type-type_two" value="type_two" /><?php _e( 'Type 2', 'group-types' ) ?></label>

<label><input type="radio" name="account_type" id="account-type-type_three" value="type_three" /><?php _e( 'Type 3', 'group-types' ) ?></label>



<div id="group-details">

<p><?php _e( 'We will automatically create a group for your business or organization. This group will be tailored to your needs! You can change the description and the news later in the admin section of your group.', 'group-types' ); ?></p>



<?php do_action( 'bp_group_name_errors' ) ?>

<label for="group_name"><?php _e( 'Group Name', 'scuba' ) ?> <?php _e( '(required)', 'buddypress' ) ?></label>

<input type="text" name="group_name" id="group_name" value="" />

<br /><small><?php _e( 'We suggest you use the name of your business or organization', 'group-types' ) ?></small>



<label for="group_desc"><?php _e( 'Group Description', 'scuba' ) ?></label>

<textarea rows="5" cols="40" name="group_desc" id="group_desc"></textarea>

<br /><small><?php _e( 'This description will be visible on your group profile, so it could be used to present your mission statement for example.', 'group-types' ) ?></small>



<label for="group_news"><?php _e( 'Group News', 'scuba' ) ?></label>

<textarea rows="5" cols="40" name="group_news" id="group_news"></textarea>

<br /><small><?php _e( 'Enter any news that you want potential members to see.', 'group-types' ) ?></small>

</div>

</div>

<?php

}

add_action( 'bp_before_registration_submit_buttons', 'sv_add_registration_group_types' );

Then we have to validate things and add some usermeta when a regitration happens:

/**

* Add custom userdata from register.php

* @since 1.0

*/

function sv_add_to_signup( $usermeta )

{

$usermeta['account_type'] = $_POST['account_type'];



if( isset( $_POST['group_name'] ) )

$usermeta['group_name'] = $_POST['group_name'];



if( isset( $_POST['group_desc'] ) )

$usermeta['group_desc'] = $_POST['group_desc'];



if( isset( $_POST['group_news'] ) )

$usermeta['group_news'] = $_POST['group_news'];



return $usermeta;

}

add_filter( 'bp_signup_usermeta', 'sv_add_to_signup' );



/**

* Update usermeta with custom registration data

* @since 1.0

*/

function sv_user_activate_fields( $user )

{

update_usermeta( $user['user_id'], 'account_type', $user['meta']['account_type'] );



if( isset( $user['meta']['group_name'] ) )

update_usermeta( $user['user_id'], 'group_name', $user['meta']['group_name'] );



if( isset( $user['meta']['group_desc'] ) )

update_usermeta( $user['user_id'], 'group_desc', $user['meta']['group_desc'] );



if( isset( $user['meta']['group_news'] ) )

update_usermeta( $user['user_id'], 'group_news', $user['meta']['group_news'] );



return $user;

}

add_filter( 'bp_core_activate_account', 'sv_user_activate_fields' );



/**

* Perform checks for custom registration data

* @since 1.0

*/

function sv_check_additional_signup()

{

global $bp;



if( empty( $_POST['account_type'] ) )

$bp->signup->errors['account_type'] = __( 'You need to choose your account type', 'group-types' );



if( empty( $_POST['group_name'] ) && $_POST['account_type'] != 'normal_user' )

$bp->signup->errors['group_name'] = __( 'You need to pick a group name', 'group-types' );



if( ! empty( $_POST['group_name'] ) && $_POST['account_type'] != 'normal_user' )

{

$slug = sanitize_title_with_dashes( $_POST['group_name'] );

$exist = groups_check_group_exists( $slug );

if( $exist )

$bp->signup->errors['group_name'] = __( 'This name is not available. If you feel this is a mistake, please <a href="/contact">contact us</a>.', 'group-types' );

}

}

add_action( 'bp_signup_validate', 'sv_check_additional_signup' );

And then we set up the group for the user (there are some constants in this function, so you’ll need to change that):

/**

* Create custom groups for skools, biz and org accounts

* @since 1.0

*/

function sv_init_special_groups( $user )

{

global $bp;



// get account type

$type = get_usermeta( $user['user_id'], 'account_type' );



if( $type == 'normal_user' )

{

// Do nothing

}

elseif( $type == 'type_one' || $type == 'type_two' || $type == 'type_three' )

{

// get some more data from sign up

$group_name = get_usermeta( $user['user_id'], 'group_name' );

$group_desc = get_usermeta( $user['user_id'], 'group_desc' );

$group_news = get_usermeta( $user['user_id'], 'group_news' );



$slug = sanitize_title_with_dashes( $group_name );



// create dive skool group

$group_id = groups_create_group( array(

'creator_id'	=> $user['user_id'],

'name'			=> $group_name,

'slug'			=> $slug,

'description'	=> $group_desc,

'news'			=> $group_news,

'status'		=> 'public',

'enable_wire'	=> true,

'enable_forum'	=> true,

'date_created'	=> gmdate('Y-m-d H:i:s')

)

);

// add the type to our group

groups_update_groupmeta( $group_id, 'group_type', $type );



// delete now useless data

delete_usermeta( $user['user_id'], 'group_name' );

delete_usermeta( $user['user_id'], 'group_desc' );

delete_usermeta( $user['user_id'], 'group_news' );



// include PHPMailer

require_once( SV_MAILER . 'class.phpmailer.php' );



$mail = new PHPMailer();

$mail->IsSMTP();

$mail->Host = SV_SMTP;



$auth = get_userdata( $user['user_id'] );

$profile_link = $bp->root_domain . '/' . $bp->groups->slug . '/' . $slug . '/admin';



$message = sprintf( __( 'Hello %s,



we have created a group for your business or organization. To get more out of your presence on Yoursitenamehere please take some time to set it up properly.



Please follow this link to fill in the rest of your profile: %s



We wish you all the best. Should you have any questions regarding your new group, please contact us at support@yoursitenamehere.com.



Your Yoursitenamehere Team', 'group-types' ), $auth->display_name, $profile_link );



$mail->SetFrom("support@yoursitenamehere.com","Yoursitenamehere");

$mail->AddAddress( $auth->user_email );



$mail->Subject  = __( 'Your new group pages on Yoursitenamehere', 'group-types' );

$mail->Body = $message;

$mail->WordWrap = 75;

$mail->Send();

}

}

add_action( 'bp_core_account_activated', 'sv_init_special_groups' );

When you write a group extension we’ll have to swap the activation call with a function like the one below to be able to check for group types.

/**

* Replacement activation function for group extension classes

*/

function activate_type_one()

{

global $bp;

$type = groups_get_groupmeta( $bp->groups->current_group->id, 'group_type' );

if( $type == 'type_one' )

{

$extension = new Group_Type_One;

add_action( "wp", array( &$extension, "_register" ), 2 );

}

}

add_action( 'plugins_loaded', 'activate_type_one' );

The last thing we need to do is add our group type names to group and directory pages:

/**

* Modify the group type status

*/

function sv_get_group_type( $type, $group = false )

{

global $groups_template;



if( ! $group )

$group =& $groups_template->group;



$gtype = groups_get_groupmeta( $group->id, 'group_type' );

if( $gtype == 'type_one' )

$name = __( 'Type 1', 'group-types' );



elseif( $gtype == 'type_two' )

$name = __( 'Type 2', 'group-types' );



elseif( $gtype == 'type_three' )

$name = __( 'Type 3', 'group-types' );



else

$name = __( 'User Group', 'group-types' );



if( 'public' == $group->status )

{

$type = sprintf( __( "%s (public)", "group-types" ), $name );

}

elseif( 'hidden' == $group->status )

{

$type = sprintf( __( "%s (hidden)", "group-types" ), $name );

}

elseif( 'private' == $group->status )

{

$type = sprintf( __( "%s (private)", "group-types" ), $name );

}

else

{

$type = ucwords( $group->status ) . ' ' . __( 'Group', 'buddypress' );

}



return $type;

}

add_filter( 'bp_get_group_type', 'sv_get_group_type' );



/**

* Modify the group type status on directory pages

*/

function sv_get_the_site_group_type()

{

global $site_groups_template;



return sv_get_group_type( '', $site_groups_template->group );

}

add_filter( 'bp_get_the_site_group_type', 'sv_get_the_site_group_type' );

It’s quite a bit of code, but it should get you started. This hasn’t been tested with 1.2 btw.

I don’t see Zenphoto rewriting their excellent, mature script to become a plugin for Buddypress

The ZenphotoPress plugin is actually very effective

Make up your mind.

I’ll explain it one more time so even you can understand; a stand-alone application that has a plugin to interface with WordPress is NOT the same thing as WordPress plugin.

… plugins are not hacks. Plugins are modular.

I never said plugins are hacks. Learn to read. I’m a big fan of plugins, but I prefer plugins that interface with existing, mature applications over plugins with entire applications written from scratch.

Case in point – I want to commit to a Gallery plugin. So let’s say I do and get users to upload thousands of pics. All is well. Dev stops. BP progresses and gallery breaks. I am faced with either correcting myself, finding another and hopefully resurrecting all the images, comments, galleries, etc (prob impossible) or <shudder> asking people to re-upload (not happening) I am ok taking risks but wondered how others deal with this issue (same applies for the seemingly stalled events plugin)

Solution: Use solid, mature stand-alone applications like Zenphoto. If they don’t have an interface plugin with WordPress, write one.

The key word here is ‘was’. If you know anything about WP, then you should know that by now it’s one of the most versatile CMS around.

Sure, functionality is ever-expanding, but the foundation is still blog centered.

BuddyPress does have a way to store 1st name and last name….custom fields …

My point is that they are not built-in, which is weird for a social network. And if you add them as custom fields you have to write your own custom function to get them into wp_usermeta.

But OK people, good luck writing that kick-ass gallery plugin for Buddypress! I won’t be wasting my time on it. I’ll be busy restructuring Buddypress’ crappy registration form.

@peter BuddyPress does have a way to store 1st name and last name….custom fields. Andy didn’t need to build it in. The only difference b/t BP and Facebook here is that FB lets you login with username as well. I’m sure you could write a plugin to replicate that functionality. Beyond that, they have 1st and last name fields…just like I do on my BP site…as well as a “display field” You can manage event registration by username if you choose but, since it’s your site, you could easily require 1st and last names.

You have a misguided view of what BP is and what extensibility really means here.

I don’t see Zenphoto rewriting their excellent, mature script to become a plugin for Buddypress

The ZenphotoPress plugin is actually very effective

Make up your mind.

@Mike Pratt and Bowe, my general point is the same problem Microsoft Windows used to be criticized for; putting too many applications into an operating system while they should have strengthened/secured the core and focused on usability first.

Let 3rd party developers spend time on creating awesome functionalities for our BuddyPress sites which are fully integrated with BPs functions, so we should not have to revert to external scripts and “hacks”.

So Buddypress is The Standard and everybody else has to adapt? I don’t see Zenphoto rewriting their excellent, mature script to become a plugin for Buddypress. So then I would have to hope enthusiastic volunteers will reinvent the wheel within BP.

If Buddypress has a solid core and APIs that make it easy to integrate external scripts, you don’t have to resort to hacks. Modular vs monolithic!

You always claim NOT to be a programmer but have no problem taking shots at the evolution of the core.

I have been an IT journalist for over ten years. I’m not a php programmer, but can sort of follow what the code does and see how the database is structured. Buddypress is built on WPMU which is built on WP and it shows. WordPress was for managing posts on a blog. A social network is for managing people/profiles, but Buddypress doesn’t even a have built-in way to store first name and last name, which immediately becomes a problem when you try to do event registration.

If there’s something available that’s built on BP or WP, then I’d rather use that, even if there are less features. If there’s something that I really need, then I’d just add it myself. I’d actually been thinking of turning NextGEN into a BP plugin.

The ZenphotoPress plugin is actually very effective. After testing both I absolutely prefer the combination of Zenphoto->ZenphotoPress->Wordpress over NextGen->Wordpress. The Zenphoto solution, not cramming everything into one plugin, is more solid and versatile.

I use this Event Registration plugin in the first version of my site. The layout is awful, but it does do a lot of straightforward database communication I would never be able to php-program myself. I’ve started cleaning up the html/css and adding jquery here and there for form validation and date picker etc.

Just FYI. Not sure if it would be suitable for your needs and if any of you would be able to add more Buddypress integrations to this plugin.

As I said in another thread I’m weary of integrating events functionality into Buddypress, because I don’t want to get stuck with one event script that misses certain features. I’d rather have a solid core and API to integrate outside event management scripts.

How is this resolved?

I’m using 1.1.3 and 2.8.6 with a custom theme derived from the first version of Buddypress. I can’t upgrade to the 1.2 theme, because it’s not finished yet and has too many changes vs my custom theme to deal with in one upgrade.

Why is buddywebsite.com/register redirecting to the homepage? Even when I allow all registrations? How can I fix it in my custom theme?

EDIT: It must have something to do with address rewrite. The register page returns when I set the permalinks to default. Is there a hard hack I can add to .htaccess or elsewhere forces buddywebsite.com/register to the right template page, overriding other permalink settings?

I’ve tested several WP gallery plugins. NextGen is pretty good, but I now use Zenphoto which is much more powerful and versatile.

Zenphoto is a complete stand-alone script, not a WP plugin, althought there is a ZenPhotoPress plugin that makes it easy to integrate in WordPress. I haven’t tried it in Buddypress yet, but it should do 80 percent of what you’d need. If it doesn’t, you could probably write plugins to connect Buddypress to functionality in Zenphoto.

General point: Why would you want to try to cram this kind of functionality into Buddypress plugin? Or even integrate it into the core (shudder…)?

Same thing goes for event registration. If Buddypress had a more straightforward, standard member management structure, integrating any outside event management script would be a lot easier. Please concentrate on the core before adding more bells and whistles!

Basically, you could extend the registration form by using one of the many hooks provided there. The data your user inputs there can then be saved as usermeta and it won’t show on their profile. Something like this:

/**

* Add xtra input field to registration form

* @since 4.0

*/

function tj_add_to_registration()

{

?>

<div id="tos" class="register-section">

<h3 class="transform"><?php _e( 'Don\'t forget...', 'traveljunkie' ) ?></h3>



<?php do_action( 'bp_accept_tos_errors' ) ?>

<label><input type="checkbox" name="accept_tos" id="accept_tos" value="agreed" /> <?php _e( 'Check this box to accept our <a href="/terms-of-service" target="_blank">Terms Of Service</a> (required)', 'traveljunkie' ) ?></label>

</div>

<?php

}

add_action( 'bp_before_registration_submit_buttons', 'tj_add_to_registration' );



/**

* Add custom userdata from register.php

* @since 4.0

*/

function tj_add_to_signup( $usermeta )

{

$usermeta['accept_tos'] = $_POST['accept_tos'];



return $usermeta;

}

add_filter( 'bp_signup_usermeta', 'tj_add_to_signup' );



/**

* Update usermeta with custom registration data

* @since 4.0

*/

function tj_user_activate_fields( $user )

{

update_usermeta( $user['user_id'], 'accept_tos', $user['meta']['accept_tos'] );



return $user;

}

add_filter( 'bp_core_activate_account', 'tj_user_activate_fields' );



/**

* Perform checks for custom registration data

* @since 4.0

*/

function tj_check_additional_signup()

{

global $bp;



if( $_POST['accept_tos'] != 'agreed'  )

$bp->signup->errors['accept_tos'] = __( 'Please make sure to read our Terms of Service and then check this box!', 'traveljunkie' );



}

add_action( 'bp_signup_validate', 'tj_check_additional_signup' );

I haven’t tested the above code much so there might be some bugs…

Same problem.

Other plugins I had problems with permissions on files, but even after setting all permissions to 0777 still not working

Excellent John James Jacoby!

I was looking for a solution for this last Fall. You can see what I came up with here (How to synchronize firstname+lastname between xprofile field_1 and wp_usermeta upon registration). It’s part of a bunch of other stuff.

But your code looks a lot more sophisticated. I’ll try to incorporate it into my upgrade to 1.1.3.

Can something like this please become part of the core?

Found the solution for my problem (described above). I had the setting “Allow new registrations” set to “Only logged in users can create new blogs.”, which actually caused the 302 redirect. I changed the setting to “Only user account can be created.”, which in my case is the correct setup.

Did you ever get the tos function to work? I’ve basically got the same problem which leads to displaying the error message, even when the tos field actually is ticked.

I have buddypress 1.1 installed and it seems to work perfectly except for spammers or sploggers or whatever..

I downloaded WPMU-Signup-Captcha from WPMUDev and put the 3 files in the directories, just like you said.

I don’t see it in the plugins section of the admin, and I still don’t have any captcha applied to new registrations.

hi,

i have a similar problem. when i access the registration page at http://<somehostname>/register i get a HTTP 302 response code and a redirect to the start page.

i’m usingthe following setup:

– buddypress 1.1.2

– wordpress mu 2.8.6

i’m sure, that i followed the installation instructions correctly step by step. i double checked it. the only thing i changed is the theme. however, also with the default theme activated (which i haven’t touched) the issue remains.

does anybody have an idea, why this is?

Same problem here. No notifications are being sent, no new users are being listed in the backend. In the database table “wp_signups” I can see the registrations, in wp_users I can not.

The only plugin installed is bp-events at the moment.

(BP 1.1.3, WordPress mu 2.8.6)