get_option() is not working even db contains the corresponding option_name and option_value

by

First of all, this is not a plugin specific problem. I wonder why this might happen? I am using @bainternet’s Tax Meta Class for saving Taxonomy Meta using the options table. I uploaded my contents from localhost (XAMPP Windows 5.5.19 environment ), I found my data in options table. Everything was working fine.

Now I uploaded my site to the server (Linux | PHP 5.2.17) and it’s failing retrieving the data from the options table.

$type_icon_array = get_tax_meta( $type->term_id, 'offer_type_icon' );
var_dump( $type->term_id ); //showing the id nicely
var_dump( $type_icon_array ); //showing null

The function failed retrieving data. How the function is:

//get term meta field
  public function get_tax_meta($term_id,$key,$multi = false){
    $t_id = (is_object($term_id))? $term_id->term_id: $term_id;
    $m = get_option( 'tax_meta_'.$t_id);  
    if (isset($m[$key])){
      return $m[$key];
    }else{
      return '';
    }
  }

I bypass the Tax Meta functions, and tried the WP rudimentary:

$tst1 = get_option( 'tax_meta_6' );
var_dump($tst1); //showing null

As you can see the database has the value in options table:
db has options value

But you can see what happened:
showing null

I then uploaded one image (while I’m on the remote server) in Taxonomy ID #2, and you can see the image is showing there.

What could happen here, that the value is in db, but get_option() is not having that value? (But it’s working while I’m updating the field in that particular environment) I even tried:

get_option( 'tax_meta_6', array() );

with no luck! 🙁

I know WordPress’ minimum requirement is PHP 5.2.4, but can that missing dev. version cause such a massacre?

Edit

I found a reason why this COULD/MIGHT happen: I checked both the local and server serialized data and found one little mismatch there, suppose my local data is:

a: 1: {
    s: 15: "offer_type_icon";
    a: 2: {
        s: 2: "id";
        s: 3: "428";
        s: 3: "url";
        s: 61: "http://localhost/example/wp-content/uploads/2015/04/image.png";
    }
}

When I’m uploading to the server replacing all the base URL, the sever data becomes:

a: 1: {
    s: 15: "offer_type_icon";
    a: 2: {
        s: 2: "id";
        s: 3: "428";
        s: 3: "url";
        s: 61: "http://example.com/wp-content/uploads/2015/04/image.png";
    }
}

The URL is changing but the string count for the changed URL remains same as of localhost. But it should be 44 because the new base URL is 17 character less.

If this is the cause, how can I solve such WP migration while the db has serialized data with site URL?

EDIT 2

YES, this IS the reason.

The serialized URL data is being changed but their string count isn’t.

1 Answer
1

Okay, at last found that, the serialized data, where there is a site_url exists, are causing the problem while I’m migrating the data from localhost to server replacing the local URL to server URL.

I found two solution, both are not tested yet:

  • PHP Serialization Fix for WordPress Migrations (& other applications like Expression Engine) by David Coveney
  • Fix-Serialization (Script to fix length attributes in serialized strings) – by Pau Iglesias

Need not to say that, try them with your own risk.

EDIT

BEFORE EVERYTHING
BACK UP YOUR DATABASE FIRST

Okay, I found the first one only specific to options table and not much flexible and not reliable too (WTFLicensed :p ). So I went with the second one by Pau Iglesias.

I found it working just fine. But as I’m a Windows user, couldn’t use shell script, so I forked his repo and made my own way using the same script:

  • serialization-fixer – Raw PHP way – github

Using my one is a bit sever-specific. You will need to put your exported string-replaced .sql file into the same folder where the serialization-fixer.php is. Then you need to open the file and change line#21 with your .sql file’s filename. After then you can simply run the file from your browser.

Thanks to Pau Iglesias for his nice scripts.

Leave a Comment