wp_insert_post & wysiwyg editor conflict

[cagdasdag]

Describe the bug As you know WooCommerce has a duplicate option for products. I've a Gutenberg block that is created with ACF and I'm using WYSIWYG editor in one of the fields. When I try to duplicate the post, the HTML tags in the editor looks broken because wp_insert_post using wp_unslash inside it.

To Reproduce

1. Create a Custom Block with a WYSIWYG editor in it
2. Create a product and use tag in the editor for example
3. Try to duplicate product you will see will look like : u003cstrongu003e

Screenshots or Video The correct page;

The duplicated page;

Additional context I checked a bit and looks like the problem is wp_insert_post has wp_unslash inside and it cause the problem.

Before wp_unslash the data is : plans_0_description\":\"u003cstrongu003e ......

And after the wp_unslash the data is: plans_0_description":"u003cstrongu003e ......

It is not just happening on duplicating, when you complete an order, woocommerce update the post. And it also broke the product page. So we can't use ACF Gutenberg blocks inside the WooCommerce products right now. Any suggestion?

[lgladdy]

Hey there,

What plugin are you using to duplicate the post? We've seen a few issues with plugins trying to do their own parsing which isn't compatible with blocks, but the issue isn't ACF specific.

[cagdasdag]

Hi @lgladdy ,

There is no plugin actually, it is default feature of WooCommerce. The action name is duplicate_product and you can see it in here : https://github.com/woocommerce/woocommerce/blob/e52d11a87ef3b3bd76540e0c94145369a4711c9c/plugins/woocommerce/includes/admin/class-wc-admin-duplicate-product.php#L97

So the problem is when you edit the product and update inside the Gutenberg UI, ACF parsing all the blocks and updating the payload. For example, if it is a \u003cstrong, it makes it \\u003cstrong and it looks fine even after wp_unslash because it is already adding one more backslash.

But if something trigger the wp_insert_post like WooCommerce order complete, or WooCommerce duplicate it brokes the content because it is only \u003cstrong and it goes u003cstrong after wp_unslash... That's the problem

[lgladdy]

@cagdasdag In the other instances we've had this, duplication plugins have had to add a wp_slash before the wp_insert_post, which is what WordPress's documentation says you need to do for any data passed into wp_insert_post. (https://developer.wordpress.org/reference/functions/wp_insert_post/#comment-2319)

I don't think this is something ACF can fix, as we need to correctly slash and unslash our data because ACF Blocks contain unicode. This problem will exist with any other block that stores unicode data in it a block comment.

I'd recommend raising this on the WooCommerce repo directly and see what they say. If they do refer you back to us, let me know and we can look further into it our side.

[cagdasdag]

@lgladdy I'm able to find a solution for myself. The main purpose of this ticket just to report a bug. Also they have already worked on this one time: https://github.com/woocommerce/woocommerce/issues/15808 and not sure what is broken again.

ACF is handling slash and unslash if you use UI update. But you are not handling if it is updated programmatically via insert_post. If ACF data goes to insert_post without slash that's something ACF need to fix IMO.

It is not just related to WooCommerce even if they fix it your clients will be able to see this error in another scenario with another plugin.

So I think you should be able to use the wp_insert_post_data filter and check if there is an ACF value in the content, you should be able to check are the slashes correct. If not you can easily use wp_slash or you can create a helper method like acf_serialize_block_attributes to avoid this for all the possible issues in the future.

[lgladdy]

We don't have any control of what happens inside native calls - wp_insert_post doesn't interact with ACF in anyway.

We also can't modify block content on wp_insert_post_data because plugins which are already correctly handling this will end up with invalid data. We're also not responsible for the content (the specific block content) generated by the block editor, as we're using the native block editor APIs to store and retrieve that data.

Thanks for the bug report - we'll follow this up on the WooCommerce side to suggest a fix, but I'm pretty sure there is no sensible solution we could ship in ACF for this I'm afraid.