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.

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 :)

  • 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.

  • I knew there had to be a good reason :) thanks @rarst – ptim Aug 8 '12 at 1:04

See here for a good discussion on the reasoning behind not changing it to JSON:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.