__PHP_Incomplete_Class
March 10th, 2009I stumbled across a brilliant bug today. I’ve been building an eCommerce site for a client, and had written a whole bunch of code that works flawlessly on my development server. However, as soon as I deployed to the production server, things went a bit Pete Tong.
Object of class __PHP_Incomplete_Class could not be converted to string
You can Google this phrase and find a million (approx) results for this, and it’s generally caused by people storing objects in a session variable, but not including the class definition before the session_start() statement. However, I was not doing this. I’m doing:
define("SESSION_CART", "cart");
$_SESSION[SESSION_CART] = serialize($cart);
After many hours of trying everything I could think of, tearing (what’s left) of my hair out, and generally throwing a programming tantrum, I finally resorted to the last ditch solution: renaming the variable to something stupid. Using this code fixed the problem:
define("SESSION_CART", "underpants");
$_SESSION[SESSION_CART] = serialize($cart);
So why should the name of a session variable make so much of a difference? I can only presume that the issue is caused by some third party shopping cart add-on software that’s hijacking the production server’s PHP configuration.
April 1st, 2010 at 1:30 pm
It’s much better and efficient to store in session only base values such as integers, floats or strings and then rebuild some objects using these on request. But thanks for an article, it was very helpful and I hope that I will remember not to do like You at first. ;]
April 4th, 2010 at 6:38 pm
Hi Tomasz,
Why is it better to store only primitive types in session variables? What’s wrong with serialising an object or an array and storing that as a session variable? After all, serialising an object just produces a string anyway…
May 27th, 2010 at 9:45 am
Storing primitives in the session and reconstructing an object graph adds complexity to your code. In other words forget what Thomasz said.