Importing WXR breaks serialized postmeta value

[takayukister]

When importing WordPress eXtended RSS (WXR), every element content get escaped by addslashes() in get_tag(). This is good for usual string. But when the content is serialized string like postmeta values, this breaks the serialized format and make WordPress disable to unserialize them.

[takayukister]

I wrote a patch whitch try to unserialize.

[ryan]

Actually, nothing passed to add_post_meta should be escaped. Unlike most other functions, add_post_meta does it's own escaping. I think we just need to stripslashes() all postmeta values before handing off to add_post_meta.

[ryan]

(In [5249]) Stripslashes post meta values before handing off to add_post_meta. Use wpdb::escape instead of addslashes. Props takayukister. fixes #4028

[JonathanRogers]

Unfortunately, this bug seems to have been re-introduced by Ticket #7347. Now, serialized post meta values are doubly serialized after importing. Since Ticket #7347 indicates there might be some reason for maybe_serialize() to doubly serialize (though I can't fathom what it might be) and add_post_meta() calls maybe_serialize(), I'm not sure where this should be fixed.

[JonathanRogers]

Avoids serializing meta values when importing from WXR

[dd32]

I think this would be better off in a new ticket JonathanRogers.

I'm going to reclose this, Could you open a new ticket related to it in the current version?

[JonathanRogers]

OK, the new one is Ticket #10619

Similar to #4028, updates the repository to NodeJS 20, which is now the current active LTS. Would supersede #5515 once v20 is on the build server!

Some of the Gutenberg failures above are because it's not yet on version 20 either.