I thought I was making my life easy and being future-conscious by saving some content as bits of JSON in custom post_meta fields. Unfortunately, WordPress doesn’t agree and is making my life incredibly difficult.
I have a JSON string that looks essentially like this. This is just one bit, and the comment string is just some dummy unicode entities. The whole thing is generated w/ json_encode.
{
"0": {
"name": "Chris",
"url": "testdomain.com",
"comment": "u00a5 u00b7 u00a3 u00b7 u20ac u00b7 u00b7 u00a2 u00b7 u20a1 u00b7 u20a2 u00b7 u20a3 u00b7 u20a4 u00b7 u20a5 u00b7 u20a6 u00b7 u20a7 u00b7 u20a8 u00b7 u20a9 u00b7 u20aa u00b7 u20ab u00b7 u20ad u00b7 u20ae u00b7 u20af u00b7 u20b9"
}
}
Unfortunately after I save it with update_post_meta
, it comes out looking like this:
{
"0": {
"name": "Chris",
"url": "testdomain.com",
"comment": "u00a5 u00b7 u00a3 u00b7 u20ac u00b7 u00b7 u00a2 u00b7 u20a1 u00b7 u20a2 u00b7 u20a3 u00b7 u20a4 u00b7 u20a5 u00b7 u20a6 u00b7 u20a7 u00b7 u20a8 u00b7 u20a9 u00b7 u20aa u00b7 u20ab u00b7 u20ad u00b7 u20ae u00b7 u20af u00b7 u20b9"
}
}
And with the slashes stripped, it can’t be json_decode
d back into useful content.
Any ideas why WordPress might be doing this, and if there is a way to avoid it? I can’t use the JSON_UNESCAPED_UNICODE flag because this is a PHP 5.3.x install, and I’ve already tried encoding with htmlentities
before the content is passed to json_encode
, but that only captures a small subset of UTF-8 entities.
Thanks in advance!
(EDIT: FWIW, I know I could just save an array directly to post_meta and it’d be serialized and magic would happen but I just like the idea of having the data stored as JSON. If there isn’t an easy, elegant solution I’ll cave, but I’m very much hoping there is an easy, elegant solution!)
Doesn’t look like there’s any way to avoid it.
The update_metadata() function, which is ultimately responsible for saving the meta, explicitly runs a stripslashes_deep() on the meta value. This function will even strip slashes from array elements, if the value were an array.
Theres a filter that’s run AFTER that called sanitize_meta, which you could hook in to. But at that point, your slashes have already been stripped, so you can’t reliably determine where they needed to be added back in (or at least, I don’t know how you would tell the difference between quoting legitimate JSON delimiters vs bits of values).
Can’t speak to why it does this, but it does. Probably because it’s eventually run through wpdb->update, which needs the strings unescaped.
As you feared, you’re probably better off just storing the value as an array, which’ll get serialized (as you said). If you want it as JSON later, you can just run it through json_encode().
There is an elegant way to handle this!
Pass the JSON encoded string through
wp_slash()
. That function will escape the leading slash of each encoded unicode character, which will preventupdate_metadata()
from stripping them.You can cheat to wordpress with something like this:
This is that easy *elegant solution*…
This function does the transformation using preg_replace:
Before each “uXXXX” (X=0..F, hexadecimal) sequence it adds backslash. Before submitting to DB, call this function.
For anyone still struggling with saving a json encoded unicode string via wp_update_post, the following worked for me. Found in class-wp-rest-posts-controller.php
Here’s an example:
An interest way around this is to encode to base64 see example below.
You can use the WordPress stripslashes_deep() function.
For reference visit here