To autogenerate a temporary username put this function in bp-custom.php:
function randomusername() {
$length = 10; //length of string
$start = 65; //Where to start from on ascii table
$end = 90; //where to end on the table
for ($k = 0; $k < $length; $k++){
$randomname .= strtolower(chr(round(rand($start, $end))));
}
return $randomname;
}
Make this edit to the username input field on the form (hacking core file, should become easier in version 1.1):
<input name="user_name" type="text" id="user_name" value="'.$user_name = randomusername().'" maxlength="50" />
Test it if you want; you’ll see a random string in the username field that will be replace by the autogenerated username based on fullname on activation.
You can hide the username field on the signup form, without getting error messages for not giving it proper TLC, by using this CSS trick.
That requires another core file hack, since you need to add a id like username-form-field. Again, should become easier in version 1.1.
My registration form is now:
Name:
Email address:
And that’s it! Everything works. Full name is available as first and/or last name. The URL is the full name lower case without spaces. 
Only thing left to do is clean up the email messages etc. that still mention the username…
I’ve already done this and the custom language file works wonders!
Although you’ll have to learn the lingo all you mo-po’s out there! (bad joke, but anyway!)
In the current stable version of BuddyPress (1.0.3) changing the root blog from 1 to anything else still works in a few funky ways. There is a proposed fix for this (from me) in the trac but it is pending more bug fixes for 1.0.4 (which may get trumped by 1.1 at this rate.)
Basically what I imagine is happening, is that when users sign up, they are given access to the dashboard blog like you specify, but they are given the contributor rights to blog_id = 1 because BuddyPress assumes “1” instead of BP_ROOT_BLOG.
Basically, you’re stuck for the time being. You can apply my proposed fix but it’s pending testing and review so I’d suggest not using it live if you can help it.
Just to give a heads-up, after some thought, the next version of Achievements released will be for BuddyPress v1.1, so I have to wait for 1.1 to come out first.
Not sure how much time that gives me so don’t want to make any promises about new features
Temporary solution how to customize registration form until 1.1 arrives, FYI and my own reference:
Changed this line in function bp_show_register_page() in functions.php in my template:
require ( BP_PLUGIN_DIR . '/bp-core/bp-core-signup.php' );
to
require ( 'custom-signup.php' );
Copied bp-core-signup.php to the template folder, renamed to custom-signup.php.
Go customize!
Unfortunately the custom fields are generated by yet another core function:
do_action( 'signup_extra_fields', $errors );
This action is associated with the function xprofile_add_signup_fields in bp-xprofile/bp-xprofile-signup.php.
Copied the function to bp-custom.php, renamed action and function to custom_signup_extra_fields and custom_xprofile_add_signup_fields.
Used this CSS trick to hide the avatar upload. Will use the same trick to hide the username field.
OK, I figured the problem out but have no answer. After upgrade to wpmu 2.8.4a from 2.8.2 using buddypress 1.0.3, I noticed that when new users sign up, even though they apply for public privacy at the sign up page, when logged in, their blogs aren’t public, and as a test member, I have to go to settings >> privacy >> and choose a radio button for public privacy again, and afterward it works.
Seem to me the sign up page did not allow public privacy even though members wanted that option!
Any idea how to fix this?
I’ve noticed that you have an add_action only when WPMU activates a user… you should also do a check when someone tries to change the full name via BuddyPress – “My Account > Profile > Edit Profile”.
Not sure what the action would be for that.
This is the function that the regular wpmu registration process uses to add the user to wp_usermeta:
function update_usermeta( $user_id, $meta_key, $meta_value ) {
global $wpdb;
if ( !is_numeric( $user_id ) )
return false;
$meta_key = preg_replace('|[^a-z0-9_]|i', '', $meta_key);
/** @todo Might need fix because usermeta data is assumed to be already escaped */
if ( is_string($meta_value) )
$meta_value = stripslashes($meta_value);
$meta_value = maybe_serialize($meta_value);
if (empty($meta_value)) {
return delete_usermeta($user_id, $meta_key);
}
$cur = $wpdb->get_row( $wpdb->prepare("SELECT * FROM $wpdb->usermeta WHERE user_id = %d AND meta_key = %s", $user_id, $meta_key) );
if ( !$cur )
$wpdb->insert($wpdb->usermeta, compact('user_id', 'meta_key', 'meta_value') );
else if ( $cur->meta_value != $meta_value )
$wpdb->update($wpdb->usermeta, compact('meta_value'), compact('user_id', 'meta_key') );
else
return false;
wp_cache_delete($user_id, 'users');
return true;
}
Is this function also used by Buddypress or does Buddypress replace it with something else?
Where do meta_key and meta_value come from? Data from Buddypress xprofile field_1 is not included at this point…
What would happen if I just added $bp as global? Trying that now… EDIT: Does nothing.
I see xprofile_sync_wp_profile() uses this same function….
@morgenvrij
We need more detailed information about your setup. Please start a new thread by posting your issue and including answers to these questions.
That is a hard one to advise you on. But, read this thread — especially the two posts by Andy (the 4th and 16th posts). Perhaps that will give you sufficient information to make up your mind.
Rogercoathup, you can read the roadmap here:
https://buddypress.org/about/roadmap/
and new comings for 2009 here:
https://buddypress.org/about/ (at the bottom of the page)
* Deactivate plugin
* Rename ‘buddypress-group-blog’ to ‘bp-groupblog’
* Make sure the ‘groupblog’ folder is moved to your active member theme as explained in the readme.
P.s. The plugin accidentally was added to the wp repository under the wrong name. It is currently being rectified so that the path will actually be correct in regards to the plugin name, namely bp-groupblog.
test show that failed to open stream: No such file or directory in /var/www/vhosts/×××××××××/httpdocs/wp-content/plugins/buddypress-group-blog/bp-groupblog.php on line 26
Holy Mackeral! Thanks so much Jeff! It’s working great now.
You’re a BuddyPress site saver!
–Roy
I actually have the same problem.
I’ve tried this patch https://trac.buddypress.org/attachment/ticket/909/909-jjj.patch but it still doesn’t work: I can’t say yes or no, there’s no button, just the question. Is it still working with your BP install JJJ?
Thanks!
I’m running WordPress MU 2.8.4a + BuddyPress 1.0.3
You can either use the default BuddyPress parent theme (which is actually called bp-sn-framework) and child theme, use the default parent theme with your own child theme, or use the parent theme to make your own, custom parent theme and then add your own custom child themes.
<small><a href="<?php echo get_option('home') ?>/members/
<?php global $current_user;get_currentuserinfo();echo($current_user->user_login);
?>/messages/compose/?r=<?php echo get_user_name( get_post_author_id() ); ?>">Send Message</a></small>
okay that works…
With the structure that is going to be implemented, does that mean you’ll have to use the “default” buddy press theme, and do your own customizations, or can you upload your own theme, and integrate the buddypress layout into it?
I think if you find a basic but good Paypal plugin for WordPress, that’s half the battle. The API is a bit awkward to work with (in my experience).
Have you talked to the WP e-commerce guys (http://twitter.com/danmilward) about bringing e-commerce into BuddyPress as a group plugin? I saw Dan present at Wordcamp UK and he seems quite a friendly chappy.
@Ishimwe-
Posting in a thread that has not seen activity for more than 2 months will not get you anywhere. Please read this post.
I am not aware of any BP-specific plugins that enable such a feature. Perhaps you should make a request in the BuddyPress Features Group or offer to pay someone to build such a plugin on the BuddyPress Job Board.
@andrlind
Seeing how you have not received a response from mattyabsley, I suggest starting a new thread and answering these questions.
Roy, what I think happened is that your activity tables were rewritten when you installed the most recent BP trunk. If you’ve been using the tagged version of 1.0.3 ( the one that is available via the big, orange download button) and not the trunk version of 1.0.3, then this is what happened.
In the newest version of BP, two of the original three activity tables are eliminated. Going forward, only one table is required. When you upgraded your live site to trunk, it eliminated two of the tables. When you reinstalled the earlier version (the tagged version 1.0.3) it reinstalled the two tables that were eliminated. But, they would have no data to display–at least at first.
Look at bp-activity.php in your 1.0.3 reinsall. Does the first line say thing?
define ( 'BP_ACTIVITY_DB_VERSION', '1300' );
Now, look at the bp-activity.php file from the most recent trunk (r1643 at the time of this post). Do you see the change in the schema-especially these lines of code?
/* Drop the old sitewide and user activity tables */
$wpdb->query( "DROP TABLE IF EXISTS {$wpdb->base_prefix}bp_activity_user_activity" );
$wpdb->query( "DROP TABLE IF EXISTS {$wpdb->base_prefix}bp_activity_sitewide" );
With the older version now reinstalled, and data being written back to the old tables, are you starting to see activity being reported in the widget?
I think the only way you could have a 1-click option would be if… at some point… there were a buddypress.com like wordpress.com. That said… all of these projects are auttomatic projects… so maybe at some point in the future they will all merge into one product? Who knows.
