BuddyPress.org

You can actually switch themes on users under certain conditions via a plugin, so no, it’s not a core thing to go in WP.

Second, you can make the theme not error out when BP is turned off. Someone should run thru the code with some ifs and submit a patch.

I’m somewhat at a loss as to why people debate this issue or try and state it’s a WP issue as logically that doesn’t make sense?

As jfigura posts this is an inherent problem, I have it on a production install and it must be hugely confusing for users, and yes the only approach so far has been to modify the text and remove the WP password from the confirmation emails.

Further testing points to the initial blog registration as being possibly the issue:

Clean install of WP MU 2.9.1 & BuddyPress 1.2 no significant further plugins activated.

Test Condition 1:

WP MU with BuddyPress disabled – admin options -> Allow New Registrations ->’Only user account can be created’

Register new user

Receive confirmation email of new registration along with Activation key

Activate registration

Receive second email with account username and pass

All as expected!

Test Condition 2:

WP MU with Buddypress activated – admin options for registration still set as ‘User Account only’

Register new user

Receive confirmation and activation key

Activate registration – screen message stating ‘you can now login with user name and password you set’

No further emails sent!

Test Condition 3:

WP MU BuddyPress still activated – admin options -> Allow New Registrations -> ‘Enabled. Blogs and user accounts can be created.’

Register new user as well as a blog!

Receive confirmation and activation for account and new blog

Activate registration – screen message ‘you can now login with password you set etc etc’

Receive further email from WP! (copied below)

Dear User,

Your new *********.co.uk Blogs blog has been successfully set up at:

http://eggs.********.co.uk/

You can log in to the administrator account with the following information:

Username: eggbert

Password: 5f112917

Login Here: http://eggs.**********.co.uk/wp-login.php

We hope you enjoy your new blog.

Thanks!

–The Team @ ********.co.uk Blogs – Sent via Site Admin options email

So having new accounts and new blogs enabled at initial registration triggers the sending of the ‘Welcome Email’ noted above.

clearly this is confusing as it contains the WP generated password.

Why is it that BP registration doesn’t disable / override the WP registration completely? To my mind this IS a BP issue, but I may very well be wrong on that score as I don’t profess to have a deep understanding of the core coding involved here.

On a sidenote:

Testing this and the slightly odd behavior of ‘Allow New Registrations’ where option for ‘only logged in users can take a blog’ actually seems to prevent all registrations. It occurred to me that on a social community ,and from our experience, blogs are not necessarily what users register for and that I would prefer the option to have a blog be only available for registered users from their account options. what actually happens is that registration is disabled completely! Not the effect I desired. I realise this IS a WP MU issue but is simply daft behavior and that set of options needs to be re-worded to be a lot clearer as to what it really does.

It would be great to be able to restrict blog signup to users already with account set up and remove, completely, the option to take a blog on initial signup, I have done this by simply scripting out the option / section for registering a new blog in BP register page but feel it’s not the best approach?

@ Mike—

“The fact that this occur for you in v1.1.3 obviously points to the fact that you have had issues independent of v1.2. What version of WPMU?”

“Are you setting the password during registration AND receiving an email with a DIFFERENT password?” — Um yes, that’s obvious and it is what the thread is about.

“Are you expecting to receive an email with a password (if so, why? given that’s not how BP works – in spite of @Peter’s incessant protests” —- If BP ASKS the user for a password, then the email SHOULD state that password, not something different. This is confusing the user and you already agreed with me on this earlier in the thread.

Using WPMU alone, you are not asked to set a password, therefore when the email arrives from WPMU, the password works. Not so with BP because the user has already set a password.

If this is not how BP is supposed to work, then how IS it supposed to work? You have stated previously “That’s it. No email.” —- Then why are my users getting emails to activate, then another email with a password after?

Again, there is no option for an admin to turn off BP overriding the password, or WPMU NOT to send the emails out. So obviously this is an underlying code issue somewhere involving BP since IT IS SUPPOSED to override WPMU.

It is apparent I am not the only one experiencing this and I think the issue is quite clear right from the OP’s first post.

Have both, MU subdirectories and subdomains, where this is happening. Can create from user side but not from backend when BP is activated. When bp is not activated mu can create blogs just fine.

From admin go to Blogs>> Edit >> see this in the Blog Options (wp_13_options)

Warning: Invalid argument supplied for foreach() in …/wp-admin/wpmu-blogs.php on line 149

My install of BP 1.2 final on my WPMU doesn’t seem to work with the v1.6 Welcome Pack plugin. It activates fine, preferences save, but when new users join, they’re not welcomed with anything. Any ideas why it installs fine but doesn’t seem to work at welcoming new users? Thanks.

pjnu – Works for me. What type of WordPress MU install do you have (example.com/blogs or blogs.example.com). Anythign in your error log? Emails not being caught as spam?

I am having the same problem. I’ve traced it down to the fact that when the Buddypress plugin is activated the tables are not created. I started putting die() statements in bp-core.php and found that the install and check install functions were not running.

I went back to bp 1.0.3 and did the install and it worked. The tables were created. Here is my info:

1. Which version of WP/MU are you running?

2.8.6

2. Did you install WP/MU as a directory or subdomain install?

directory

3. If a directory install, is it in root or in a subdirectory?

subdirectory

4. Did you upgraded from a previous version of WP/MU? If so, from which version?

no clean install

5. Was WP/MU functioning properly before installing/upgrading BuddyPress (BP)? e.g. permalinks, creating a new post, commenting.

yes

6. Which version of BP are you running?

tried to install 1.1.3

7. Did you upgraded from a previous version of BP? If so, from which version?

no

8. Do you have any plugins other than BuddyPress installed and activated?

no

9. Are you using the standard BuddyPress themes or customized themes?

standard

10. Have you modified the core files in any way?

no

11. Do you have any custom functions in bp-custom.php?

no

12. If running bbPress, which version? Or did your BuddyPress install come with a copy of bbPress built-in?

came with it built in

13. Please provide a list of any errors in your server’s log files.

In Apache I got:

[Sun Feb 14 10:51:51 2010] [notice] child pid 8139 exit signal Segmentation fault (11)

or with different pid each time I tried to install

in php there was this in the log

[14-Feb-2010 09:45:54] PHP Notice: Constant DB_NAME already defined in /Users/chris/Sites/wpmu/wp-config.php on line 23

[14-Feb-2010 09:45:55] PHP Notice: Constant DB_USER already defined in /Users/chris/Sites/wpmu/wp-config.php on line 26

[14-Feb-2010 09:45:55] PHP Notice: Constant DB_PASSWORD already defined in /Users/chris/Sites/wpmu/wp-config.php on line 29

[14-Feb-2010 09:45:55] PHP Notice: Constant DB_HOST already defined in /Users/chris/Sites/wpmu/wp-config.php on line 32

[14-Feb-2010 09:45:55] PHP Notice: Constant VHOST already defined in /Users/chris/Sites/wpmu/wp-config.php on line 39

[14-Feb-2010 09:45:55] WordPress database error Table ‘wordpress.wp_blogs’ doesn’t exist for query SELECT * FROM wp_blogs WHERE domain = ‘localhost.localdomain’ AND path = ‘/wpmu/’ made by require, include, include_once, require_once, require_once

[14-Feb-2010 09:45:55] WordPress database error Table ‘wordpress.wp_sitemeta’ doesn’t exist for query SELECT meta_value FROM wp_sitemeta WHERE site_id = 1 AND meta_key = ‘site_name’ made by require, include, include_once, require_once, require_once, get_current_site_name

[14-Feb-2010 09:45:55] WordPress database error Table ‘wordpress.wp_blogs’ doesn’t exist for query SELECT blog_id FROM wp_blogs LIMIT 0,1 made by require, include, include_once, require_once, require_once

[14-Feb-2010 09:45:55] WordPress database error Table ‘wordpress.wp_sitemeta’ doesn’t exist for query SELECT meta_value FROM wp_sitemeta WHERE meta_key = ‘wpmu_sitewide_plugins’ AND site_id = 1 made by require, include, include_once, require_once, get_site_option

[14-Feb-2010 09:45:55] WordPress database error Table ‘wordpress.wp_sitemeta’ doesn’t exist for query SELECT meta_value FROM wp_sitemeta WHERE meta_key = ‘active_sitewide_plugins’ AND site_id = 1 made by require, include, include_once, require_once, apply_filters, call_user_func_array, mu_filter_plugins_list, get_site_option

14. Which company provides your hosting?

No hosting, I’m installing it locally on a MAC with MAMP

You have a missing column in a BP table (wp_bp_activity_user_activity_cached)

Deactivate BP and reactivate it.

i installed the bleeding version and am now sweatin’ blood myself, getting the following on a wpmu 2.9.1, bp 1.2 rc, bp-links bleeding install:

[08-Feb-2010 22:56:40] PHP Fatal error: Call to undefined function is_user_logged_in() in /home/public_html/wp-content/plugins/buddypress/bp-core/bp-core-templatetags.php on line 676

edited to include that i’ve got bp default theme activated

I say it again: GREAT plugin – thanks alot!!!

A couple suggestions/questions:

1. Do I get it right: I can set the default in the backend, but eyery user (not the group admin) sets/changes the notification for themselves?

2. Forum-Notification: I don’t want forums activated on my site, but I cannot get it off (no CSS classes for display:none). It is also not dynamically I guess, for I disabled forums in the backend, but still shows forum-notifications… Any solution to this?

3. What exactly means “added something new to the group”? Is that comments? Is that another plugin like gallery, group-documents etc?

4. Member must be registered for option: When I type 0 in the field, that would mean no delay, right?

5. “You can also specify a minimum gap in time between updates regarding group wiki page edits.” This sentence does not make sense to all the users who haven’t wikis installed. It’s hardcoded. Any solution to get rid of it?

6. Last but not least: Is it translatable??? I really would love to do that for german (at least try it as my first ) – could you provide a POT-File?

Thanks for all the work. This is REALLY IMPORTANT for us and well/simple made!

Ps: This is my test-install-site: http://wp.graphic-studio.ch/network – there I am testing your plugin

I think when you activate site-wide they’re activated for all blogs. Plugin control is all or nothing; close access to the plugins for all users or leave them wide open. More selective control over plugins would make WPMU/BP exponentially more useful.

The issues with the existing plugins for ZenPhoto and NextGen are that they are designed for a single user blog and content.

When users are split into the different sections many of which do not have blogs it creates serious issues. I looked into those, and even stripped them down a bit.

I think WP 2.9 is on the path to galleries, although not active. It has editing, uploading, management(although wrong) and many other features that would be easier to get working then to hack around a outside solution.

Photos should be core, Events as well. If you want to develop these as “core plugins” that users have to activate like the repos in Linux thats fine, but they still need to be there and accessible.

You are most welcome

I will suggest putting javascript with template files, reason, the javascript is mostly dependent on template and will change in custom templates, so give the user the ability to customize without modifying the plugin.

The problem for loading comes, when you want to activate your javascript function after activity is called, as Andy suggested in trac,

https://trac.buddypress.org/ticket/1616

Using ajaxStop for determining the case, though it is not the most efficient way. I am working on a custom javascript event thing, and if Bp1.2 is delayed for 2 weeks, I will put my solution for Andy’s review.

In other case, using the wp_print_scripts action and wp_enqueue_script is your best recourse.

Not sure if I can contribute, but I also have this problem.

WPMU 2.9.1.1

BP r2400

In wp_signups a user has

activated: 2010-01-22 03:06:39 (GMT)

In wp_bp_activity it’s

date_recorded: 2010-01-21 19:06:39 (America/Los_Angeles)

In the activity stream is say “8 hours ago.” I’m not sure what the code does but it seems that when the time is moved to the activity table it’s converted to local time rather than staying in GMT.

If I manually update wp_bp_activity to

date_recorded: 2010-01-22 03:06:39

the activity stream works as normal.

Hope that makes sense and helps.

Hi there,

I dont understand the fix you’re proposing Issidha, because when I go to the WordPress MU files you indicate need tweaking, I dont SEE those lines pertaining to taking out the www in front of URLs… ??

I tried entering the domain name where i’m trying to have Buddypress with a www. in front but I have the same issue:

— > The main page is showing up but all other pages ( Members/Blog…) are not accessible: ie, I get a wrong URL message.

As in:

Trying to go to : http://www.sitename/groups

*** The requested URL /groups was not found on this server. *****

I and other users CAN access wp-admin ( http://www.sitename/wp-admin/) , as if only the WordPress MU was working, and not all the Buddypress features.

I also installed a fresh copy of WP MU, and installed Buddy Press 1.1.3, as recommended, through the instal Plugin of the WP MU dashboard.

I had also installed a couple more plugins, the Buddypress SEO, Hashcash and a forum subscription plugin for BP, which I just deactivated to see if that helped. But it makes no difference.

Thanks for your advice…

I’d like to know this as well. You could probably put this on activate.php somehow.

Also the standard WPMU welcome email is sent on first login. That works via a function in wpmu-functions.php:

function wpmu_welcome_user_notification($user_id, $password, $meta = '') {

global $current_site;

...



wp_mail($user->user_email, $subject, $message, $message_headers);

return true;

}

I don’t see a hook in that function. It’s called/triggered from function wpmu_activate_signup in the same php file.

wpmu_activate_signup is called from function bp_core_screen_activation in bp-core-activation.php.

Perhaps you could add a redirect there to the mandatory extra fields? There are already some if statements there, one with this:

bp_core_redirect( $bp->root_domain . '/' . BP_ACTIVATION_SLUG );

You could add your own? Just guessing, wouldn’t know what it would look like…

What does that plugin do? It has some vague requirements:

Create three news fields that will be used by the plugins (ex. “Member name”, “Member firstname”,”Member bothnames”). I suggest “Member name” to be a required field.

Fill the values of those fields for your profile (the datas for at least one user are needed to setup the plugin options)

Where are you supposed to create those fields? xprofile? In addition to the existing fullname field? You can already do that without this plugin.

wp_usermeta is nowhere in the plugin. That is the table WP uses to store firstname and lastname. Any solution in Buddypress should leverage wp_usermeta or at least synchronize with it imho. This plugin solves nothing.

If you’ve got a repeatable case of BP changes not syncing to the WP profile, please create a bug ticket on https://trac.buddypress.org/.

The problem Dan Butcher described looks like standard Buddypress behavior to me. It’s not a bug, it’s a feature, based in Andy Peatling’s design decision that firstname + lastname would cause international incidents.

Below again my hack as I use it in my sites, minus creation + update of a fullname-derived username for user_login, user_nicename, user_url and integration with a mailing list script I use:

function synchro_wp_usermeta($user_id, $password, $meta) {

global $bp, $wpdb;



$uid = get_userdata($user_id);

$email = $uid->user_email;



$fullname = $meta[field_1];

$space = strpos( $fullname, ' ' );



if ( false === $space ) {

$firstname = $fullname;

$lastname = '';

} else {

$firstname = substr( $fullname, 0, $space );

$lastname = trim( substr( $fullname, $space, strlen($fullname) ) );

}



update_usermeta( $user_id, 'nickname', $fullname );

update_usermeta( $user_id, 'first_name', $firstname );

update_usermeta( $user_id, 'last_name', $lastname );



$wpdb->query( $wpdb->prepare( "UPDATE {$wpdb->users} SET display_name = %s WHERE ID = %d", $fullname, $user_id ) );



}

add_action( 'wpmu_activate_user', 'synchro_wp_usermeta', 10, 3);

I have this code in bp-custom.php or functions.php, not as a plugin. Adding a plugin header could have caused Dan Butcher’s error messages.

BTW, I’m still looking for code to validate the fullname input for at least a two part name, so make a space required. I now get a lot of users only entering a first name. In that case the lastname field in wp_usermeta will stay empty.

From what I’ve heard you won’t even notice. There will then be an option that activates the multiuser part and that’s it.

Thanks. That clears things up. The only other problem I’ve encountered is after I deactivate the BuddyPress plugin and re-activate it, I’ll get the follow db errors:

WordPress database error: [Duplicate key name ‘useritem’]

ALTER TABLE wp_bp_notifications ADD KEY useritem (user_id, is_new)

WordPress database error: [Table ‘wp_bp_activity’ already exists]

RENAME TABLE wp_bp_activity_user_activity_cached TO wp_bp_activity

WordPress database error: [Duplicate entry ‘1’ for key 1]

INSERT INTO wp_bp_xprofile_groups VALUES ( 1, ‘Base’, ”, 0 );

WordPress database error: [Duplicate entry ‘1’ for key 1]

INSERT INTO wp_bp_xprofile_fields ( id, group_id, parent_id, type, name, is_required, can_delete ) VALUES ( 1, 1, 0, ‘textbox’, ‘Name’, 1, 0 );

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

yeah, the Admin-Dashboard of WP / WPMU looks very complicated to people who have never used WordPress or really are not some sort of Publishers.

So an average person “writing his blog” will surely need a few days to understand the Dashboard and most likely would not need all the features it is offering.

An average user probably only wants to write some text and post an image or a video.

I am thinking of the Community I am trying to target which are people at the age of 50 and above. So I decided to de-activate “User-Blogs” from my installation, because I am sure my users will be confused with the backend-Dashboard.

I do hope that the Dashboard of WP will get a design-overhaul to make it easier to understand.

Gonna see how the “quick blog post form via the theme” from the “BP-Roadmap” will work out ? If this will be easy to use (without going into the Dashboard), then I might integrate the Blog-functionality back-in into my installation.

I have the exact same problem. Is there an easier way to fix this?

Can I just overwrite WPMU and Buddypress via FTP? Or do I really need to delete them all first? I just want a step by step, layman terms, of how to go about this. And I suppose I will need to remember my sql db access passwords..lol shame on me I know, but I might just create a new user for that SQL table and use that for access.

I tried just reinstalling Buddypress…deactivated, deleted the files, re-uploaded Buddypress via FTP – then reactived it…so doing that alone did not fix the problem. It still won’t let me select default theme. So I guess I need to do the same for WPMU.

I just don’t want to go through the trouble of deleting WPMU and then re-uploading it – plus all my plugins (which I have backuped).

But from now I I will just ignore the auto-update linky thingy.