Tag Archives: WordPress

On upgrading WordPress (and WordPress plugins) automatically over SSH/SFTP

For the most part, I love managing my own server. Even though it requires digging into the muck of Linux configuration files with my bare hands (so to speak), and if it goes down, I have no one to blame (or call on for help) but myself, it’s great to have full control and flexibility.

One downside I discovered as a WordPress user, however, is that the super-slick automatic upgrade feature of WordPress was broken on my server. WordPress only supports FTP and the (as I see it) somewhat pointless FTPS. Insecure as it is, my old host supported regular ol’ FTP, and that made WordPress upgrades painless.

There’s no way I’m going to implement FTP on my own server. It’s easy enough to install the package at the command line (really, it is), but I just see no reason to open myself up to the security risks. Granted, there aren’t really that many security risks (beyond one very big one — intercepted passwords) with a well-configured FTP server. But I don’t care to investigate the steps necessary to ensure an FTP server is well-configured.

The obvious choice is to use SFTP/SSH, but at first it looked to me as if WordPress simply didn’t support it. But as I’ve learned (and since proven with my own server), WordPress does support it if your PHP installation has the proper extensions installed. And here’s a guide to get you started.

Once your PHP install is upgraded to support SSH connections, the option will automatically become available in the WordPress upgrade tools, and it works perfectly!

The growing problem of registration spam in WordPress

WordPressNow, this is odd.

A few months back I wrote a plug-in for WordPress called RegisTrap. It’s beyond basic, and has one simple purpose: to block registration spam on my WordPress-based website.

Registration spam, for those of you who don’t know, is when a “bot” (a computer program written to seek out and exploit poorly-written web forms to send floods of spam email messages) signs up as a “user” on your site. These “users” can’t really do anything on the site, but they clutter up your database nonetheless.

I had a feeling that RegisTrap was really only going to work reliably if I kept it to myself. And I was right: after submitting it to the official WordPress plug-in repository, it eventually stopped working, as the bots adapted to avoid its “traps.” It might have happened eventually anyway, but I’m sure that the publicity it received from being in the repository, and the hundred or so people who downloaded it (many of whom, I suspect on reflection, were probably bot developers looking to dissect its workings), accelerated its demise.

As I announced here a few days ago, I turned RegisTrap off on my site, and I also turned off registration altogether. But that hasn’t stopped the flood of new bot registrations. There are 14 of them sitting there in my database right now (well, there were before I just deleted them), all added after I turned off the ability to register altogether.

I suppose, since the bots don’t actually visit the site and fill in the form, they just submit the right data directly to the right URL, whether it’s “browsable” or not, it doesn’t even really matter if your site is set up to reject registrations. Still, it’s a bit dismaying that WordPress is processing those registrations even with registration turned off. Apparently it stops at making the registration page inaccessible via links; it doesn’t actually turn off the code that processes registrations. Boo. Perhaps that should be my next plugin: “Stop All Registrations 4 Realz.”

But maybe I won’t call it that.

RegisTrap seems to be losing its effectiveness

I suspected this might happen once I released RegisTrap to the public. I had four new spam user registrations on my site when I checked it today (having last checked it maybe two or three days ago). Previously I’d only see about one a week with RegisTrap running.

It was bound to happen. The rules RegisTrap employs are fairly simple, and the “bots” are constantly being modified. I have no idea how many registrations RegisTrap has blocked in the time it’s been running — perhaps my next step in developing it is to add a logging feature. If there were only four (or even maybe a dozen or so) spam attempts on my site during this time period, then RegisTrap seems pretty ineffectual. But if it actually blocked a ton (metaphorically speaking) of spam registrations, then four sneaking through doesn’t seem so bad.

If anyone out there is using RegisTrap and cares to comment on ways I could improve it, let me know! Meanwhile, as time allows I am going to pursue the logging functionality, if only for my own edification. As valuable as the logging feature would be, it goes against the spirit of simplicity inherent in the plugin. I really don’t want to write anything to the database or filesystem.

RegisTrap 0.4 released

Luckily the bug in RegisTrap I discovered yesterday after upgrading to WordPress 2.7 turned out to be a very minor one. I just had to move the return $errors; line outside of a conditional in my function to ensure that it’s always returned, even if no error value was set. In the previous version of WordPress, it didn’t matter that if there were no errors the function was returning… well, nothing… but in the new version it seems you can’t apply an error handling filter without returning a WP_Error object.

Anyway… it works now, and you can download version 0.4 right now from my site. I’ve also checked it into the main WordPress Subversion repository, so it should be showing up on the official site sometime fairly soon. Enjoy!

Special thanks to Jenny for happening to try registering for the site within about 8 hours after I had upgraded, and bringing the problem to my attention. Otherwise I might have gone days or weeks without knowing the plugin was broken!

It’s definitely still necessary though, because in about a day of running my site without the plugin I had already received over a half dozen spam registrations.