Why does WordPress use serialize rather than json_encode for the options table?

2 Views

I have a basic understanding of serialize (I come across it often when I’m migrating WordPress installs) and I just discovered json_encode.

Given that serialize causes so much trouble with replacing strings in the database (eg. editing an optinos field directly), why does WordPress prefer serialize to (the
seemingly similar) json_encode, which doesn’t insert the string length into the stored value.

Read More

My first thought was that it may provide some security or error-checking benefits – WordPress will ignore the option if the string lengths are incorrect.. but I’m interested in a qualified explanation 🙂

Post Views: 2

Related posts

Leave a Reply

2 comments

    • serialize representation can be stored in text and reversed
    • JSON representation can be stored in text but cannot always be precisely reversed

    Run this example:

    $query = new WP_Query();
var_dump( $query );
var_dump( unserialize( serialize( $query ) ) );
var_dump( json_decode( json_encode( $query ) ) );
    • After going through serialize accurate WP_Query object is re-created.
    • After going through JSON you get stdClass object.

    In a nutshell serialize is native part of PHP and has a lot of synergy with manipulating data in it. JSON is language-agnostic format that is convenient for systems talking to each other, but far from comprehensive and cannot do things in PHP which serialize does without second thought.