For some reason, get_option()
started to fail when returning binary results when I moved my website from localhost to the web server. I migrated my WordPress using an upload of the files on the FTP
Everything else works perfectly however. Even the wp-admin
works right: I can edit, post, etc. It’s just a single line of code that is giving me the blues. It comes from a theme I’m using, but there is no theme-specific behavior: it crashes way before that. That line of code tries to do this:
$sqbtn_1 = unserialize(get_option('magaling_ads_468060_1')); //returns null.
$sqbtn_1 = $sqbtn_1->is_empty() ? $ad_def : $sqbtn_1; //CRASHES: is_empty on a non-object.
If I create a simple PHP file, I can prove myself that the data comes correctly from MySQL. I have the ‘magaling_ads_468060_1’ field in my WordPress options table and here is what it contains:
mysql_query('SET NAMES utf8');
$result = mysql_query("select * from wp_options WHERE option_name = 'magaling_ads_468060_1'");
//prints out the following value of the option_value field:
s:376:"O:18:"Padd_Advertisement":5:{s:27:"Padd_Advertisementimg_url";s:88:"http://www.echysttas.org/wp-content/themes/magaling/images/advertisement-468x060_1.jpg";s:28:"Padd_Advertisementalt_desc";s:15:"Axonn Echysttas";s:27:"Padd_Advertisementweb_url";s:24:"http://www.echysttas.org";s:26:"Padd_Advertisementtarget";s:4:"_new";s:29:"Padd_Advertisementcss_class";s:0:"";}";
So the MySQL returns the data! However, get_option returns nothing. I echo-ed it and it’s empty. On the other side…
get_option('magaling_installed'); //works and returns "1"
Everything else works fine, even returning other theme-specific (integer or string) values.
var_dump( get_option('magaling_ads_468060_1') ); //shows bool(false)
var_dump( get_option('magaling_installed') ); //shows string(1) "1"
var_dump( get_option('blogname') ); //string(9) "Echysttas"
Found the problem. And A WORD OF WARNING to people MIGRATING their WordPress Installations. Read this to understand how get_option is going to start failing when
unserializing
binary data from the DB.What I did was to migrate my WordPress the hardcore way: copy all files to the web server, restore the full SQL database script.
Prior to the restore, I did a mass replace in the SQL database to change the URLs from local to web server. And that’s where the problem lies.
There were PHP serialized objects in the database. Where a string is serialized, its length is prepended. And, you can guess the clusterfuck I got myself into: since I mass-replaced the host-name, I should have modified string lengths of serialized objects everywhere I had serialized host names.
Using a default WordPress installation this would not be a problem because WordPress doesn’t use such features. But if you use Plugins or Themes and you use this method for migrating your blog, you’re asking for problems.
Luckily I have very few formerly-local URLs inside serialized objects, only two, to be precise.
I hope my 7 hours of battle with this problem will serve somebody.