Plan for the upgrade and pick a time when your site traffic is low.
Let your users know ahead of time that you’ll be down for maintenance. Even with just a few users, letting them know is a courtesy, because if they do visit while you’re upgrading and they don’t know what’s going on, they may eventually leave because they think things break all the time.
Yes, we backup ahead of time. Really. With large site where it would be impossible to ftp things without it taking all day, just backup files in a different location on the server. Optimize & clean up the db while you’re at it. Who wants to back up spam?
Some of us with large sites do not deactivate all plugins and then reactivate later. With hundreds or thousands of blogs, it’d be a nightmare.
At some point when your site is very large, you’re just going to have to get used to doing some things command line (ssh). In many ways, it’s easier.
The moving of the them only occurred during BP 1.1. Shouldn’t have to do it next time. But! Paying attention to core changes helps you anticipate these things in advance. You have to do your homework.
The maintenance mode plugin may not work properly in MU. My fave trick, if I*really* wanna keep people out, is to toss an index.html file in the root. I can still get in the backend, but many users just can’t figure out they can type in these things without a link there. 
Man, this means I have to write up a blog post about it now, doesn’t it?
I just tried that as I am out of alternatives…
Just noticed when testing the new signup slug that the user gets an email with the following text:
“You can log in to the administrator account with the following information:
Username: test
Password: bd36dc14
Login Here: http://test.biketravellers.com/wp-login.php”
? : Why does the user get a random password sent as he alreaady chose a non-random one? This random one does not work by the way.
Is this a result of the spam procedures or a regular bug?
Cheers, Bike
Glad to hear it, levin! Hopefully that’ll hold the floodwaters back until the next generation of bots finds a way around it.
Tried @stwc change register-slugs suggestion, zero spam registration in a week! thanks alot!
I have had total cessation for the last two weeks without using plugins, using the procedure I outlined here.
Would be good if you could post ideas and solutions here too: https://buddypress.org/groups/fighting-spam-splogs
There’s already a few plugins etc mentioned there that might help you out too.
Andy, the username/email gets randomly made with every signup, so that won’t work.
Maybe this’ll help too: http://perishablepress.com/press/2009/03/16/the-perishable-press-4g-blacklist/
Also – make sure you are marking the users as spam not deleting them. This will block the username/email from logging in and/or signing up again.
They should just use activation mail again, works the best.
There already exists a topic concerning these spam sign-ups. Haven’t had any problem with this yet, but that’s most likely because I have my wpmu/buddypress/bbpress in dutch..
@Andrea_r No joy. Tried the # BEGIN ANTISPAMBLOG… code and just got another bot registration “terrancecline1973” a moment ago.
Thanks Sven, I will try to install this and have a look……
I changed the mail address from noreplay to a real one.
That fixed the spam problem for me.
See this plugin:
https://wordpress.org/extend/plugins/mail-from/
Thank you !
But what is the name of the file at which I can change and customize the text of the “confirmation e-mail ?
Customise the email message with specific text for your site so it is less likely to be identified as spam?
Thanks so much.
I’m using the object-cache.php file from Donncha as the only caching that I’ve installed. This seems to be the much of the space – If I drop these, will performace be slower, or will data be lost? Would you suggest the wp-super-cache instead?
I don’t have many blogs – one, basically, (the main BP blog, but it has 10,000 posts, but they’re not really posts, long story). It’s a complicated integration where I’m using BP for the community side of a larger site with 123,000 members migrated into WPMU/BP.
There isn’t much spam do deal with, thankfully.
Thanks again for the info.
You shoudl back it all up, yes. But you don’t necessarily need to ftp it down to your computer. I normally make a copy of the folder right on the server.
If you are double-sure you have cache files, you can clean them out. What are you using the cache? Because wp-super-cache has a cleanout button back there on the admin screen.
It’s not unusually large, no, dpeending on how may users and/or visitors you have. Lots of users, lots of hits, means lots of cache files & loads of upload files if they like to post pics to their blogs like you’re Flickr. (Hi mom!)
Yes, you’ll want to backup the db as well. Optimize those tables, and if you’re really feeling frisky, clean out the spam.
Remember that with the BP upgrade, the theme changes location. The MU part should be smoother.
Pick a time when your site traffic is low, like the weekend.
@stwc
Thanks for your effort, i just put it into my site, hope it can stop the spam registration.
Cross-posting this here from another thread. It’s now about a week since I’ve had anymore of the firstnamesurname19xx signups.
Well, I don’t know — I seem to have lucked out, or it’s just that my site is too new and so-far untrafficked, but the few very simple, small changes I made last week seem to have stopped the firstnamelastname19xx signups.
1) I changed the some of the text on the /register page.
2) I removed the “powered by” text in footer.php of my child theme (someone mentioned that it was being searched for)
3) I changed the register slug in wp-config.php
4) Added a functions.php file in my custom childtheme with the following code to redirect signups for all blogs to the Buddypress register page
function rk_signup_redirect() {
if (strpos($_SERVER['REQUEST_URI'], 'wp-signup.php') !== false ) {
$url = 'http://mydomain.com/customregisterslug';
wp_redirect($url);
exit;
}
}
add_action('init', 'rk_signup_redirect');
where mydomain.com is, you know, my domain, and customregisterslug is the slug I changed in step 3.
I don’t think I changed anything else — no captchas or anything — and I’ve received zero splog signups in the 5 days since, after getting a few a day before that. Fingers crossed.
@Andrea_r
thanks for your handy information, do you know is it work for sub-domain configuration too?
We modded D’Arcy Norman’s solution above so it would work on BuddyPress. At least it did a while back. Someone wanna give this a whirl again?
Spam blogs and Buddypress
# BEGIN ANTISPAMBLOG REGISTRATION
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .yourbpsignupslug*
RewriteCond %{HTTP_REFERER} !.*yourhomedomain.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://die-spammers.com/ [R=301,L]
# END ANTISPAMBLOG REGISTRATION
Hmmm – I installed the Plugin from Dennis Morhard “Invitation Code Checker” (https://wordpress.org/extend/plugins/invitation-code-checker) and changed the text a bit, so that my users know, which the code is when they register. Since then (a couple days now) ZERO spam signups… I hope it stays like that and the plugin is not too upset, that I misuse it 
Hello.
I do have spam user registrations even with registration option set to:
[*] Only logged in users can create new blogs.
I understand this option to say that new user registrations are DISABLED but registered users may create blogs. Unfortunatly the “Register”-Button appears in the welcome widget with that setting — even though clicking it will redirect back to the homepage.
To disable the above option also disables the blog creation — which I do NOT want.
For an unkown reason I do see spam registrations (a couple per week) but it seems those users are not able to login and create blogs (or comment). I also do NOT get the usual notification mails for new user registrations.
It seems like a bug to me.
I have the same problem but it’s not so much the issue of spammers coming to the site than non-working defense measures.
I have failed to find any reasoning behind the dropping of wp-signup.php and replacing it with /register (what’s the .php file for that btw?) in BuddyPress but that’s the reason for a lot of spam problems.
When you install a number of WP and WPMU anti-spam plugins, they add their own features to the signup page – which in WP and WPMU is wp-signup.php.
Now as it has been pointed out in about all spam-related posts, people even delete that file with no success to the spam issue. This confirms the problem that I believe could reduce the spamming significantly:
– WP and WPMU anti-spam plugins do *not* have any affect on the BuddyPress /register page.
Is it because some hooks are missing? I’m not sure as I’m not that deep into it but I think so.
My request to solve this problem and address the spam issue:
– either BuddyPress will return to use wp-signup.php, or
– makes sure that anything added by plugins to wp-signup.php is also added to whatever page is serving the /register URL.
No matter hashcash, captcha or security question (all nice and working (with wp-signup.php) plugins), they can’t add their stuff to the BuddyPress signup page.
Why I don’t use wp-signup.php manually (like redirect URL to there)? Because it’s a blank page (told to die somewhere in BuddyPress if I remember right).
