Jeremy’s Blog

For a good portion of the day, I’ve been working with friend and co-worker Steven Harris on some new PHP 5 code. We’ve uncovered a few “Gotcha’s” that I think it would be best to share with everyone so that you won’t be as infuriated as we were about this whole thing.

First of all, and this is completely unrelated, if you’re doing tests with cookies, don’t allow your cookies to be set with “localhost” as the domain if you’re testing locally. I wasn’t aware before now that this didn’t work as intended, so there was a lot of headache with some code we’ve been fighting with.

Update: By the way, another co-worker recommended Microsoft Fiddler to me for debugging HTTP Traffic, and that’s how I rooted out the above problem. It’s definitely a wonderful tool, and I recommend it to anyone who might need to see exactly what’s getting passed over HTTP. There is one downside to it, though. It only works with Internet Explorer.

Our first PHP 5 Gotcha: Removed the E_STRICT deprecation notice from “var”. (PHP 5.1.3 Changelog)

This one tripped us up pretty badly today. Of course, it’s probably our fault for not reading the changelogs, but this was a bit of a nuisance. For a good long while I thought our error handler just wasn’t catching or passing errors along like it should’ve been, because we weren’t getting the E_STRICT deprecation notices that we’ve all come to love and adore. I wish someone would do me a favor and tell me why this notice was removed. Logically, it doesn’t make sense to me.

Next PHP 5 Gotcha: If date.timezone is not set in php.ini, you get an E_STRICT notice

I know this is desired functionality, but let me take a moment to let you know why this “got us” … And it has a lot to do with the above Gotcha. (And honestly, I’m kind of glad this notice exists, because it proved that my code wasn’t broken. ;)) I’m going to just borrow Steven’s words here:

[23:07] Jeremy: Correct me if I’m wrong, but shouldn’t gmdate() NOT throw that timezone E_STRICT message?
[23:08] Steven: It would be stupid if it did, since there’s really only one timezone it should be concerned about, unless it needs current timezone info to get a difference (but that should already be handled by the OS)

Ways to circumvent this notice? Use date_default_timezone_set() if PHP >= 5.1. The date.timezone ini setting can also be changed at runtime, so use it if you’re on PHP < 5.1.

Our third and most annoying Gotcha: PHP bails out with class declaration nesting error when an error handler dynamically loads an error handling class during a class related E_STRICT warning. (PHP 5.1.1 Bug #35634)

Steven was testing on PHP 5.1.1 when we first started working on this code, and he caught this little gem. Luckily, the code we’re working on has support for text-only errors (it was loading the UI class that caused it to bail), so we may have to resort to that on PHP 5.1.1 (and possibly other versions, but I haven’t heard of this in any other version, so far), which would be a little annoying, but we’ll just have to deal with it, I guess. I’m also looking for an alternative work-around which I’ll share if I find anything.

Update 2: By the way, now that I’m looking over the code, it seems like Gotcha #2 is actually causing this problem for us. I’m going to see about fixing it to see if it fixes this problem, as well.

That’s all for now. I’m sure I’ll probably put some more together as we continue coding.

Note to self: Start reading the PHP Changelogs very closely and very often.