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.

Yes, Virginia, there really is a difference between null and false

Fairly often, it’s necessary in PHP programming to write your code around the fact that, most of the time, PHP does not distinguish between null, false and 0, although there is, nonetheless, a distinction between all three.

Today I ran into one of the few instances where I was expecting PHP to treat them as equivalent, but it did not.

Often I am working with arrays, and I write conditionals that should only execute if there are elements in the array. Technically the proper check for the status of an array-type variable is the is_array() function, but most of the time I don’t use that. I may have initialized the array variable or not, but that’s irrelevant to me; what I care about is whether there’s anything in the array, so I just use count() instead.

These days I’m working on some object-oriented code, and I’ve been writing several “get” methods that return either an array of data or, as I had originally written them, a false value if no matching data exists.

Fine. But then I applied some of this new OO code to an existing page, and found that one of my count()-based conditionals was evaluating incorrectly. I checked the variable, whose value was set by one of the object methods, and as anticipated, its value was false. But strangely, the count() function was returning 1 rather than 0 when applied to the variable.

I resisted my initial temptation to switch from count() to is_array() because I don’t want to have to change every place where I use it. Then I tried changing the “failed” return value of the method from false to null and, what do you know, it worked!

So now I’ve gone through all of my various “get” methods and, on failure, they’re returning null instead of false.

T_PAAMAYIM_NEKUDOTAYIM

I am certainly accustomed to encountering PHP parser errors, but I was not expecting to see this: T_PAAMAYIM_NEKUDOTAYIM

And apparently I’m not alone. Even with an explanation (it’s Hebrew for “double colons”… and I leave for you to discover on your own why PHP constants might be named in transliterated Hebrew), it’s still a bit confusing, as the expected character should have been a dollar sign, not a double colon. Still awaiting an answer on that one…

A fix for a fix in WordPress 2.1

One thing that surprised me when I started using WordPress again is that its search function only searches on blog posts, not on static pages. I suppose if most WordPress sites are 99.9% blog posts, then it probably makes sense, but I have enough static pages on my site that I’d like to make searchable to warrant changing this.

Fortunately, someone has. Unfortunately this “Search Pages” plug-in is out of date and no longer works with current versions of WordPress. I dug in a bit and figured out why: the plug-in alters the SQL query that performs the search, but the substring it replaces in the query no longer exists! So I hunted down the place where the query occurs in the WordPress core, adjusted the plug-in as needed, and it works!

Here, then, is my hack of the Search Pages plug-in, modified to work with WordPress 2.1. (I’m not sure which other versions of WordPress it will or will not work with.)

[ search_pages.php.tar.gz ] [ search_pages.php.zip ]

More stupid web tricks coming your way…

I realize I’ve been working with PHP for too long when I get an idea like “I wonder exactly how birth rate affects population levels” and the first thing I think of is, “well why don’t I just build a PHP app to figure it out?”

This is the result of such thinking: Population Trajectory Calculator. It’s the newest addition to my Stupid Web Tricks page, and the first that’s not just JavaScript triggering an irritating pop-up.

This is probably just as pointless though, but it was a fun little exercise, and it’s starting to give me more ideas, which is always dangerous. Before long I’ll have built a web-based version of Oregon Trail.

I’m not kidding.

(Well, OK, I hope I am.)