Tag: WordPress - Page 19 - UNDERDOG of PERFECTION

WordPress 2.7 “Coltrane” is out!

The latest version (2.7) of WordPress, codenamed “Coltrane,” has just been released, and it looks like a winner!

I have obvious reasons for liking this version of WordPress for its codename alone, but I am also extremely impressed with the new enhancements to the Dashboard. It is a delight to use (design counts, both aesthetically and practically), and upgrading was seamless.

Well, almost.

I found out today that RegisTrap, my registration spam-busting plug-in, is broken in this new version. Broken as in it makes your registration form not work. So, if you happen to be one of the five or six other people in the known universe who are using it, and you upgrade to WP 2.7, you’ll want to deactivate the plug-in until I can update it. (For now I am just going to run the site without it and see if registration spam is even a problem anymore with this version.)

Overall though, more outstanding work from the WordPress dev team! Kudos!

Update, about 24 hours later: In the day (roughly) since I upgraded to WordPress 2.7 and deactivated RegisTrap, I’ve already received a half dozen spam registrations. I can’t possibly be unique in this, and my site doesn’t even draw very heavy traffic. How can the WordPress core team not be doing something about this problem? I’m kind of in disbelief, but I guess it just means I need to get to work on updating RegisTrap for WP 2.7 compatibility. I hope to get on that by next week.

New WordPress plugin: RegisTrap

Regis Trap? Not quite.

As I have trumpeted from the hilltops on many an occasion, I have happily been using WordPress to power this site going on two years now.

Mostly happily, anyway. There are a few things that don’t sit right with me, most prominently the persistence of spambot registrations, with little (good) help so far from the plugin development community.

What are spambot registrations, you ask? Well, blogs tend to have two doors that are open to spambots: comment forms and registration forms. Comment forms are certainly more common (since just about every blog accepts comments but most probably do not accept new user registrations), and much has been done to deal with the problem of comment spam. Most notably there is WordPress founder Matt Mullenweg’s own excellent comment spam blocking plugin, Akismet. But no comparable plugin exists for the WordPress registration form, and despite many requests from the community, Akismet has not yet been adapted for this purpose. Probably since registration spam is so far only a nuisance (albeit a potentially large one for the site administrator), it has not gotten the same kind of attention.

I did manage to find a few plugins to block registration spam, but most were half-baked, and the one I did end up using for a while, which clearly has been given a lot of attention by its developer, just seemed to be overkill to me. And while it did work to prevent spam registrations for the month or so that I used it, it also prevented my legitimate, registered users from logging in!

So a few days ago I turned it off, and within hours I was receiving spam registrations again. That’s when I decided to build my own spambot registration blocking plugin for WordPress: RegisTrap. The focus is on absolute simplicity: there are no visible changes to the registration form for users, and there’s no configuration for the site admin… just upload it, activate it, and you’re done.

I’ll admit mine is probably half-baked as well, but it’s only at version 0.3 so far. I may eventually need to add an administrative tool to allow the site owner to make changes if bots start to adapt to the default settings — I don’t really know how smart bots are. But I do know that I’ve had RegisTrap running on my own site for a couple of days now, definitely long enough to be able to determine whether or not it’s working, and since I installed it there has not been a single spambot registration on my site.

If you run a WordPress site, give RegisTrap a try!

Technology Large and Small

Here I sit in the living room, tentatively tapping out a blog entry on a tiny on-screen keyboard in the new iPhone version of WordPress. (So far, so good.) Meanwhile, the kids are watching a “Lazy Town” DVD on our new, gigantic 42-inch LCD HDTV, purchased last weekend. It’s an interesting study in technological contrasts. These days, everything’s profoundly huge or tiny, depending on the need for mobility. Nothing too deep, I know, but it’s cast in bold relief for me at the moment. Plus, it was a good excuse to test the iPhone app… and to post a photo of the giant television.

The most peculiar WordPress problem yet

I was beyond dismayed tonight to load up my browser and discover that my website, for whatever reason, just wasn’t working. Firefox would just bring up a completely blank screen. Safari returned a strange error:

Safari can’t open the page “http://room34.com/”. The error was: “Operation could not be completed. (kCFErrorDomainCFNetwork error 302.)” (kCFErrorDomainCFNetwork:302) Please choose Report Bugs to Apple from the Safari menu, note the error number, and describe what you did before you saw this message.

Uhh… OK.

Needless to say, it’s not something I’ve ever seen before, and if Google is any indication, (almost) no one else has either.

After inspecting my files and my data tables to see if anything had been altered (i.e. hacked — and no, it hadn’t), and watching The Colbert Report, I decided I had no choice but to confront the rat king and start stepping through all of the nested include files that comprise the WordPress application, hoping to find the exact point at which the whole thing was going kerblooey.

Eventually I did manage to find the precise line in the precise file where the site ceased to return any output to the browser. It happens to be line 20 in wp-includes/taxonomy.php, which goes something like this (minus the insistent tendency of WordPress to automatically insert smart quotes everywhere):

$wp_taxonomies[‘link_category’] = (object) array(‘name’ => ‘link_category’, ‘object_type’ => ‘link’, ‘hierarchical’ => false);

Having abandoned efforts to further dissect the innards of WordPress, I tried commenting out the line. No luck. Next I tried just sticking a return; at the top of the file, essentially scuttling everything it does. That did display the page, but without the functions in this file it was so riddled with error messages as to be unusable. Next, I returned to line 20 and emptied out that array it creates (commented it out, to be precise), leaving, in essence:

$wp_taxonomies[‘link_category’] = (object) array();

And, whaddayaknow… it freakin’ works! In fact, on cursory perusal of the site, I don’t even see any problems, so I’m not sure where this particular subarray gets used, or whether my own idiosyncratic taxonomic structure even needs it. And I’m sure within approximately 24 seconds of posting this entry, I’ll discover it. But for now, things seem good… although I hate having to settle for a “solution” like this, especially given the effort it took to pinpoint the problem.

Update, May 30, 2008: I was informed by my hosting provider that last night they performed a PHP upgrade, which seems to have been what precipitated this problem. So perhaps I have discovered a conflict between PHP 5.2.6 and WordPress 2.5.1.

Update, June 2, 2008: After working briefly with my ISP on this issue, they have modified a configuration setting on the server to solve this problem. Here’s what they had to say about the change: The server was previously configured to support PHP4 backwards compatibility via the following directive:

zend.ze1_compatibility_mode 1

They’ve removed that compatibility mode setting in the configuration for my virtual host, as such:

zend.ze1_compatibility_mode 0

This change on their part has solved my problem, as I have now reinstated the original WordPress code in taxonomy.php and the site is functioning properly.