Removing Spammy Users from WordPress

I have a friend that set up a BuddyPress, WordPress website called MavenMall.com. She set it up years ago. It’s a great site for women who want to buy modest clothing. Everything was going great until one day, when her hosting company, HostGator, told her she was taking too many resources for her hosting package and shut not only Maven Mall down, but all other sites that she was hosting on the server. Not nice. (Once the issue was isolated, the other sites were brought back online while we worked on Maven Mall.)

There are a few things that led to the shut down. A lot of plugins were used on the site that eat resources. We cleaned that up so that the site was using only essential plugins. But that wasn’t enough. What we needed to do was to clean up all the bogus users that had accumulated over the years (over 77,000) and add measures so that new bogus users wouldn’t come back.

I found a few ways to delete users. None of them worked great because of the sheer number of users that needed to be deleted. Because there were so many, I kept having problems with the code timing out on me. Here is what I tried:

Using a plugin to delete users. I was hopeful when I tried this plugin, but it just kept hanging. Other people have found this plugin useful. It probably works as long as you have a normal number of users to delete.

Changing the screen options in the Users page in WordPress to show more users, and then doing a bulk delete. There were two problems with this. The maximum number of users that it will show at a time are 999. So I’d have to run it 77 times. But even when I tried to delete 999, it kept timing out.

The third thing that I tried to do was add code to functions.php to loop through all the subscribers, and delete them. When I first ran this code, it did nothing. After debugging it, I realized that it wasn’t working because it took too long to load the array of users before it actually started deleting anything. There were a couple of things that I could do for that. I could increase the time time to allow the code (page load time) to have more time to run. Since we were in this mess because of using too many resources, I didn’t want to take a chance with Hostgator shutting us down again, so I didn’t do that. Instead, I limited the numbers of subscribers to be deleted to something that it could manage and something that I wouldn’t mind running a bunch of times. I set to load 2000 subscribers into the array at a time. This worked nicely. To make sure that it was running, I queried the database to check on the count of records in the users table. As long as the number of users was going down, I was happy.

I thought about just deleting all the users from the database, but I didn’t want to take a chance that comments or other leftovers from these users might remain in the database because I didn’t use the correct WordPress function to delete them. WordPress is nice that it takes care and cleans up the mess for you.

After all this fun stuff was done, I optimized the database.

Even though I put on a bunch of different spam guards, like Akismet, WangGuard, Stop Spammer Registrations Plugin and SI Captcha Anit-Spam, bad users were still getting through. They couldn’t have been coming through the login page because the site was offline and password protected, yet these bots were still finding their way in. That rendered all of these plugins useless.

In the end, we had to block registrations.  Under Setting -> General -> Membership. I unchecked the checkbox for “Anyone can register”. By default, unless you need it to be open, make sure that it’s not. For a BuddyPress site, it can be a bit of a problem. You want people to join, but you only want real members.

My advice for anyone running a site that allows people to register is to make sure that all the software that it runs in up to date. There are mean people out there that look for ways of self promotion without caring about the damage that they do to other sites. By keeping your software up to date, you make sure that more of the holes that these people find are plugged. This is not only for WordPress, but for any content management system.

On one of my Wikis, MetWiki.com, we are running version 1.16. MediaWiki is now up to 1.21.1. Even though the site doesn’t get that much traffic yet, we are doing the upgrade. It will be painful because of all the changes that have happened in MediaWiki since 1.16, including a complete change to the template mechanism, but we will do it for the health of the site and the health of the other sites that run on that server.