If you tried to look at or order any shirts from Test Tube T-Shirts in the past 2 or 3 days you may have noticed that our /shirts sections was all jacked up.
I narrowed down the culprit to a PHP upgrade our host did. They upgraded from PHP 4.3.5 to 4.3.10 on January 26th. That’s especially important because I know for a fact that the page was working fine on the 25th and broken on the 27th.
So I knew it had something to do with PHP breaking and it was only affecting the page that made use of [DB_Dataobject]. However, simply working with the DB_Dataobject class wasn’t breaking the page. I didn’t realise it at the time, but it was stemming from telling DB_Dataobject to give me an class that let me work with our shirts table. Basically, what DB_Dataobject does is some sort of class overloading. There is probably some sort of base class that defines a table and the methods to access it and when you tell it to give you one customized for a certain table it extends it with table columns, etc.
I was poking around on the Pear-general mailing lists and came across this guy who was having a similar problem. Basically you instantiate your overloaded class and the minute you call one of its methods, the class destroys itself. Not very useful, eh? :)
He apparently found out that if you define this constant, DB_Dataobject won’t overload classes. I guess it then falls back to some sort of alternative method of producing class for me. In anycase, it works, and it stems from some change made in PHP versions [4.3.6], [4.3.7], [4.3.8], [4.3.9] or [4.3.10]. I poked around a bit in those changelogs but I didn’t see anything that screamed out as if they’d made some change to the way classes get overloaded.
tl;dr : PHP 4.3.10 breaks the way that the PEAR library, DB_Dataobjects overloads stuff and will break your code. Put this line before you define any DB_Dataobject objects and you’ll be good:
define('DB_DATAOBJECT_NO_OVERLOAD', 1);