BuddyPress.org

Nobody has yet convinced me that the proposed deprecating of the friends component makes sense from a code point of view. I am not disagreeing that some people want/need a different visualization of how friending works, but you have to make the case that it will genuinely improve the codebase while providing backwards compatibility.

There is a proposal to make this major shift in how a key component of the software functions without any supporting code to show that it will actually work.

I know this project isn’t a democracy, but you can’t just say that not everyone is going to be happy all of the time and then steamroll them. A lot of people have invested a lot of their free time into BP, and if they get burned they could very well leave the community. I don’t think its worth the risk to lose smart people from an open source project only due to fear of too much code. Code is expensive to write. Free code is good.

I can see how it might be good tokeep friending, but give the option not to use it. I hate it when Ning takes away features …

Just in general I don’t like the idea of any features being taken away …

If friending gets taken out in 1.3, then I’ll stay with Buddypress 1.2 …

We should be thinking about extending the BuddyPress framework and not deprecating major components at this time …

Not sure why JJJ wants to remove the “friending feature” in favour of the “following-feature”? Can we not have both ? …

I am worried Buddypress will fall into the trap of trying to be everything to all people and will become a bloated mess. For my projects I need a coherent, reliable core before I need any more features – forums, events, galleries, enterprise features, ecommerce, …

It’s great the developers are rethinking friending, how it can make more sense in the Buddypress context. If Buddypress can come up with a different approach, logically tied into groups and (micro)blogging, that could really set BP apart from Facebook, Ning, etc. Less is more!

JJJ’s proposal already is the best of both world imho (yes, we can have both!):

1. Deprecate “Friends” component code into a separate downloadable plugin that can still be used exactly like it is now, just not part of the core anymore.

2. Merge friends functionality into private “user” groups so that developers can choose to ditch the “friends” model if they want …

3. “Friends” would replaced with the core ability to “follow” peoples activity, and for your activity to be followed by others …

This is also a next step in the evolution in web friending, from classic Friendster/Facebook -> Twitter following -> following/friending with more context in groups and blogging (not just based on 140 chars brain farts).

Absolutely agree with Windhamdavid btw!

I spend the better half of the last hour reading these threads related to depreciating ‘friends’ and I’m sold on it. This is very insightful point (from the vantage of a behavioral psychologist). It makes ‘friends’ more powerful and oblique at the same time. Friends will consolidate perfectly into the more powerful groups api while opening up more dynamic (Not “less meaningful”) ‘friend’ models.

WordPress MU 2.9 (currently trunk) / WordPress 2.9 are required for BuddyPress trunk and will be required for 1.2.

Vincole, would this cover your needs?

Kaltura Media Component for Buddypress

Demo

@Andy. Yes. Thank you. I was just pointing out that there is no option to use just a background color and no image. You’d have to use an image that was a solid color. Which is fine.

I’ve spent a couple of hours on this with rickross on IRC. See https://trac.buddypress.org/ticket/1524.

did you upload buddypress in the same path, or you have the directory name of the svn??… you can not have two buddypress installed, if the system call a redeclare, the error is similar to this situation.

@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.

@David Lewis – sorry about that, didn’t notice that there was a new custom header with options page in the trunk bp-default theme because I customized the header in my child theme

Thanks Andy. I did not know that. There appears to be no way to use just a color instead of an image though. Although I suppose a single color GIF would be pretty tiny.

In any case, I find that in general it can be a little tricky to override styles when shortcut declarations are used. If all font settings are set in a single declaration but I only want to override the size… I have to redeclare everything in short form using the “font” property. Certainly not a big deal by any means. In fact, it’s a pretty miniscule. Practically a non-issue. It only came up because I was having a hard time trying to change my header. Didn’t know about the custom header setting.

Shelly, was your problem solved? I have seen your issue on trac.buddypress, but no one have replied you. I am having the same problem.

Is there any one to help me out?

Nope. Doesn’t work in Safari / Chrome. There is no “important” in the parent. I know I could make a blank gif… but I’m not sure that’s any less ugly. Anyway… that’s cool. I’ll just use “important!” in the child.

Hi David. Works for me in all BP child themes. I presume you cleared cache/cookies and are targetting the correct selector , so

:

1. If there is !important after the background image url in parent theme, add it in your declaration in child theme – none !important

2. an alternative: create blank 1×1.gif file and use that for your background url(images/1×1.gif) to override parent theme

Actually… I just tried that. Doesn’t work.

Riiiiiiiiiiiiight. Why didn’t I think of that. I’ve never thought of using simple “none” as a shortcut. Thanks. Sorry Andy.

#header { background: #f76d16 none; }

where “none” will equate to no background image in the child theme; it overrides

url(../images/default_header.jpg);} in parent theme. Works across all browsers.

Andy… please don’t use CSS shortcuts in the 1.2 default theme. It makes overriding a little more difficult / messy if one chooses to use the 1.2 default theme as a parent. For instance… the 1.2 default theme uses a shortcut for background instead of using background-image:

#header {background: url( ../images/default_header.jpg);}

Say I want my header to have a background color and no image. This override won’t work:

#header {background: #f76d16;}

Nor will this:

header {background-color: #f76d16; background-image: none;}

One is forced instead to use the !important declaration so that using the color shortcut can override the image shortcut:

#header {background: #f76d16 !important;}

This works… but the important declaration makes me a little queazy. LOL.

@Andy, First, I have nothing negative to say about BP. It is allowing me to do things I would NEVER even attempt on my own. Looking back on the programming I’ve done in the past, there was NO separation (mostly pre-CSS, php/mysql where my separation was myriad includes). However, as I look at Justin’s code, I’m learning the elegance (and additional complication) of separating form from function.

Doing everything through functions.php, styles.css and hooks is a challenge for me, but I do see the benefits. If there are sufficient hooks, most things can be accomplished this way. If there is a hook, I can use the new template tag just by modifying functions.php instead of changing the myriad template files that might contain the new tag.

What sucks (for me) in that model is I have to switch back and forth from template to function and then ensure I test everything well. What works is I get to change it once.

Regardless, for template tags and other changes, what’s most important is documentation (which can be a challenge with development cycles). If the changelog tells me what to look for and what functionality has changed (see Peter’s post above), the process is MUCH less painful. I know you know this, but most of us would rather have the features now and struggle without the docs – Catch 22.

Whatever the result, I’m ecstatic that Buddypress exists, that Automattic adopted it and you finally have some additional help.