@Elemsee
A simple fix for you, might be from site admin… options:
Set ‘allow new registrations’ to ‘only user accounts can be created’.
That should remove all the blog stuff.
Thank you, Jason. I’ve cleared my cache, as well as had two other people try this (restarting server not an option, unless my host can be asked to do so….)
Let me walk through what I’ve done:
- In wpmu site admin, “Only user account can be created” is enabled.
- Within bp-core-adminbar.php, I replaced this code:
echo '<li' . $alt . '>';
echo '<a>loggedin_user->domain . $bp->blogs->slug . '/create-a-blog">' . __('Create a Blog!', 'buddypress') . '</a>';
echo '';
- With this code from the patch:
if ( bp_blog_signup_enabled() ) {
echo '<li' . $alt . '>';
echo '<a>loggedin_user->domain . $bp->blogs->slug . '/create-a-blog">' . __('Create a Blog!', 'buddypress') . '</a>';
echo '';
}
- Saved and re-uploaded to buddypress/bp-core
- We created a new subscriber account to test. New user sees:
— “My Account” in admin bar, with “Create a blog” on flyout
— “You haven’t created any blogs yet, create one” on [profile] > Blogs > My Blogs
— “Blog registration is currently disabled” on [profile] > Blogs > Create a Blog
All “Create a blog” references should be gone, no?
Any obvious misstep?
You could make a custom login page with BP trunk like…
define('BP_LOGIN_SLUG', 'login');
function bp_show_login_page() {
global $bp, $current_blog;
if ( $bp->current_component == BP_LOGIN_SLUG && $bp->current_action == '' ) {
bp_core_load_template( 'registration/login', true );
}
}
add_action( 'wp', 'bp_show_login_page', 2 );
Then put a template file named “login.php” in your frameworks registration folder and steal some code from the buddypress login form to help with getting started…
There’s a few examples online on how to redirect the WordPress login page with .htaccess. Could give that a shot too?
If that means what I hope it does, I offer myself as a life-long fan 
And can now gratefully retire from hunting where I can edit the text “Blog registration is currently disabled”
This is going nowhere. I’ll just hack core file; replace wp-login.php and wp-admin/profile.php with copies on login.php and account/profile.php (?) and then search/replace all links.
I f***ing hate WordPress registration/member management!
I see the html for the xprofile input fields is in function get_edit_html in bp-xprofile-classes.php:
switch ( $this->type ) {
case 'textbox':
$html .= '<div class="signup-field">';
$html .= '<label class="signup-label" for="field_' . $this->id . '">' . $asterisk . $this->name . ':</label>';
$html .= $this->message . '<input type="text" name="field_' . $this->id . '" id="field_' . $this->id . '" value="' . attribute_escape( $this->data->value ) . '" />';
$html .= '<span class="signup-description">' . $this->desc . '</span>';
$html .= '</div>';
break;
So I guess I could add onkeyup=”copyinput()” there, but then all xprofile fields will get that. Would that mess up the system? The Javascript refers to the fields by ID.
According to Jeff Sayre this method will be deprecated in version 1.1, but I need a temporary solution before I make the switch.
Trying that now…
I would try to prevent member registration through .htaccess:
http://wpmututorials.com/how-to/spam-blogs-and-buddypress/
If not .htaccess, then try WP Hashcash, but I prefer the simplistic method of blocking through .htaccess. This will block most spam signups, but of course you can’t block everything! 
Thanks to Darcy Norman for the original tip!
I’ve noticed the imported users have also been added to the mailing list via my bp-custom.php function.
So the plugin actually “runs” the regular registration processes, including wpmu_activate_user? Whatever member registration custom code or plugin you have inbetween, this plugin takes it into account?
That is pretty cool.
As Peter said, with the bp-sn-framework, is simpler, you need to add in the style.css at the top in the comment-header
/*
[….]
Template: bp-sn-framework
*/
deactive your current theme and reactive it again. (Remember it works only with 1.1-svn version).
You have to put css you want in your style.css and they will be applied on the default registration page.
Or you can copy from the bp-sn-framework the register.php to your theme dir, and edit html if needed
Nicola
Styling the signup form is supposed to become a lot easier in the upcoming version 1.1.
To get my signup form somewhat in line with the rest of the site I had to hack core files. Details of my attempts here.
Like I said, at this question on the WPMU forums / search on the WPMU forums.
Back when BP was pre-beta, I used to use the following code on a test installation. I post it here just to try to counteract this notion that it is “impossible” to change the welcome text email. Please note I am not supporting this code and I’m not even saying that it will still work. YMMV.
http://buddypress.pastebin.com/f284e0aab
Original posters:
a) Yes, but please discuss this on https://buddypress.org/forums/topic/modified-mail-message-registration.
b) Yes I believe so, but this is a WPMU question so you are best searching on the WPMU forums
c) Yes, it’s in the theme files. You can edit these at the moment and it might be easier to do in BP 1.1/trunk.
This is not only resurrecting a 4 month old thread – of which you yourself have found several duplicates – this is more a WPMU question that BP. Use https://buddypress.org/forums/topic/modified-mail-message-registration for discussion on this area, i’m closing this thread.
I got a reply from Ron over at WPMUTutorials.com.
If you’re interested in our discussion, head on over to:
http://wpmututorials.com/how-to/blog-categories/
A summary of what Ron wrote:
1- BP is enabled on a WPMU site basis so when running multiple site, BP can be enabled on one site and not another.
2- The same applies to site options/settings like registration.
3- BP does not filter a user’s blog list on the member profile by WPMU site. So, if you had 5 sites and a user had a blog in 4 of them then all 4 blogs would be listed.
One way you could accomplish the multisite setup where BP is on the main site and blogs on the additional sites is
Enable BP only on the main site.
On the main site set registration to users only.
On the additional sites set registration to only users can create blogs.
Create an info page on the main site that provides links to each of the other sites’ signup page.
This is a little bit involved and I’m a little pressed for time; I would at some point like to tackle this… but then I’d have to worry about redirecting /copying over blogs and permalinks on the existing WPMU setup… (sigh).
—
@Jeff and Jason – Thanks for the info.
Donncha’s Domain Mapping plugin wouldn’t work in my situation because I’ve setup WPMU with subdirectories and not subdomains.
Re: the Multi-site plugin on WPMUDev. That one is different than the one that Ron has developed. So I’m not sure if XMLRPC will work with Ron’s version… a good question to ask him!
What is now the recommended approach for editing the activation/signup emails?
Other threads about this:
Modified mail message registration
Use full name in confirmation emails
control of new user activation email
get_edit_html() is a method in the BP_XProfile_Field Class. You will not be able to stick it into bp-custom.php and expect it to work. That is not how methods function.
Also, this method will be deprecated in v1.1. I would recommend that you look at the v1.1 code in trunk. Otherwise, your custom coding may not function the way you expect when you upgrade.
The html of the custom xprofile fields is generated by yet another function; get_edit_html() in bp-xprofile-classes.php. So if you want to change anything in the custom fields, including the * for required fields, you’ll need to copy/rename that function to bp-custom.php as well.
EDIT: …which is not straightforward:
Fatal error: Call to undefined method BP_XProfile_Field::custom_get_edit_html() in /serverpath/wp-content/mu-plugins/bp-custom.php on line 256
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…
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.
Thanks for the suggestion r-a-y.
The autogenerated username should behave pretty much as the normal username; it shouldn’t be possible to change the username. The URL to the profile page should stay the same, even if the user decides to change his name – which would be a bit unusual anyway.
Or am I missing some other consequences…?
Next problem to solve is what to do with the username field on the registration form. It should get an autogenerated temporary value, to be replaced by the function on activation, and be hidden from the user. I found this code to generate a random string:
$len = 16;
$base='ABCDEFGHKLMNOPQRSTWXYZabcdefghjkmnpqrstwxyz123456789';
$max=strlen($base)-1;
$activatecode='';
mt_srand((double)microtime()*1000000);
while (strlen($activatecode)<$len+1)
$activatecode.=$base{mt_rand(0,$max)};
echo $activatecode;
To add that as value on the registration form I probably have to hack core file. Moving my attention to rearranging the signup form next…
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….
@Mike Pratt, I’ve tried the honey approach in the past. I’m not even counting on responses anymore. I post my attempts here to keep track of what I’m doing and hopefully in the end the thread becomes useful for others in my situation.
@DJPaul, thanks for the additional clue. I think I need to go back to that “flowchart of registration events in wpmu” and get a better insight what happens where in the process.
Thanks for the additional info Jeff Sayre! Now at least I know I’m not wasting my time.
@Peterverkooijen-
As far as I know, there will not be any underlying changes to WPMU’s database schema (design). Therefore, it will be the same old issues you’re trying to address. But, being able to design a custom registration page will help to address some of the current systems short comings.
This all comes back to what we have discussed in the past. WPMU–in its current incarnation–is blog-centric, not user-centric. Until that gets addressed, the only option is to custom code work arounds.
