Importing WXR breaks serialized postmeta value

[JonathanRogers]

Because custom field values are passed through the poorly named maybe_serialize() when importing, any values that already contain serialized strings are serialized again, making them useless. Although it would make more sense to me to eliminate the bizarre behavior of maybe_serialize() that may break something else, so I fixed this problem by turning off maybe_serialize() for WXR import.

[JonathanRogers]

Disables maybe_serialize() when importing custom field values from WXR

[westi]

Not sure this is the best solution here.

May be better to unserialise and pass to add_meta as that is what it expects.

[JonathanRogers]

Replying to westi:

Not sure this is the best solution here.

May be better to unserialise and pass to add_meta as that is what it expects.

You mean it may be better to unserialize every custom field value when importing? Is it correct to unserialize values that aren't serialized?

I don't think my solution is the best either. I think that either add_post_meta() shouldn't pass the value through maybe_serialize() or maybe_serialize() shouldn't serialize values that are already serialized. What's the value of serializing something twice? However, I didn't do that because the comments on maybe_serialize() implied that there was some reason for its bizarre and extremely surprising behavior.

[johncoswell]

I just got bitten by this bug in a WPMU->WPMU import, so here's my two cents. Theoretically, you should be able to run already-serialized values through maybe_unserialize(), because if it's not determined to be serialized data, it simply returns the original data. I'm fine with unserializing the data before passing into add_post_meta(), since if you're working with serializable data structures in the first place, you'd expect to be feeding those same structures back into add_post_meta().

[beaulebens]

I have to agree with johncoswell here, I think if something is passed to maybe_serialize which is already serialized, then the answer should be "don't serialize (again)" and the already-serialized value should be sent back.

[znarfor]

Alternative patch

[znarfor]

Actually, I think westi was right, we just need to unserialize the data before importing it. My patch above simply does this.

[westi]

I think znafor's patch is the best solution here.

On export we put the raw data from the db into the xml file.

Normally when getting the post meta we would have called maybe_unserialize on the value before returning - therefore we should replicate that here before passing to add post meta so that we have the same consistent behaviour.

Could someone generate a small WXR file with some post meta in to test this with and report back on sucess/failure

[johncoswell]

Test WXR file with serialized postmeta value

[johncoswell]

I made that change to a local copy of WP 2.8.4 and it worked as expected. The meta data was properly stored in the database as a serialized string.

[westi]

We also have the issue outlined in #9633 we will look at both of these early in 3.0

[westi]

Replying to johncoswell:

I made that change to a local copy of WP 2.8.4 and it worked as expected. The meta data was properly stored in the database as a serialized string.

Thank you for the sample file.

I have included it as test data into the wordpress-tests repository and started writing some unit tests against it for this issue.

[westi]

(In [12495]) Use maybe_unserialized on all post_meta values on import to ensure we don't end up with double serialized data in the database. Fixes #10619 props znarfor.