ACF block attributes serialization is different in special cases

[CreativeDive]

Hey,

I've noticed some inconsistency with the ACF block attributes being serialized in special cases, and I'm wondering what is expected and what isn't.

I noticed that ACF uses the same serialization as WordPress with acf_serialize_block_attributes().

Here is my example: I have a field storing an SVG tag and in a normal way the serialized result is:

<!-- wp:acf/icon {"name":"acf/icon","data":{"icon":"\u003csvg class=\u0022library-icon ....

... even after the post has been manually saved.

BUT if a post was saved by an operation using wp_update_post() the serialization format is different:

<!-- wp:acf/icon {"name":"acf/icon","data":{"icon":"u003csvg class=u0022library-icon ...

In this case, the backslashes has been removed \u003csvg to u003csvg.

I don't think this should actually happen as it could potentially cause issues when rendering block fields.

Can you help me figure out which of these two ways is the expected way and why there are differences that really shouldn't exist?

[CreativeDive]

https://developer.wordpress.org/reference/functions/wp_update_post/

I can see wp_update_post() is calling wp_insert_post() which is using wp_unslash( $data ). This could be the reason why the backslashes has been removed.

So the question is why is the serialization different at all? What is the expected result \u003csvgor u003csvg?

[lgladdy]

I actually dealt with a case of this last week where a duplication plugin was breaking ACF Blocks.

You're expected to slash the data yourself before passing it to wp_update_post, so if you're manually sending the data, you need to wp_slash it before you send it.

That duplication plugin patched their plugin to solve this, as it's not something we can do.

[CreativeDive]

thank you for clarification.