fix: incorrect slashes in some json_encoded values for CustomPostTypeStorage

[nicolas-jaussaud]

Hi @zinigor!

It looks like we have an issue with the CustomPostTypeStorage, when saving a string that contains '

Screencast.From.2026-07-09.00-38-10.mp4

The cause seems to be that the saved JSON is not valid (it contains \'), so the value returned by json_decode() in find() and all() will be null

The value get corrupted during save because:

• wordpress apply add_magic_quotes by default on $_POST for every requests, which transfrom ' to \' (here)
• \' is not valid in JSON, and is escaped to \\' when we call wp_json_encode during save (here)
• update_post_meta apply wp_unslash on the meta value (here), which revert the escaped \\' to \' (so the final value will be invalid JSON)

The recommended approach seems to be to:

• revert the initial add_magic_quotes by applying wp_unslash on $_POST
• use wp_slash only when needed, for core function that expect it (wp_insert_post(), update_post_meta()... etc)

We already apply wp_unslash in our Request class (here), as we copied the core implementation from WP_REST_Server::serve_request()

However, we were still reading from the raw $_POST for saving, we should now use $request->get_body_params() instead

This PR also update the CustomPostTypeStorage class, and make sure to apply wp_slash where it's now needed (wp_insert_post, wp_update_post, update_post_meta)

So before this PR, the data was going through:

• add_magic_quotes -> wp_json_encode -> wp_unslash -> invalid json saved

And now it should be:

• add_magic_quotes -> wp_unslash -> wp_json_encode -> wp_slash -> wp_unslash -> valid json saved

This PR also remove the strip slashes for the repeater value, as it shouldn't be necessary anymore (we will now get an unslashed data from $request->get_body_params() there as well)

I also took the opportunity to generate some tests that simulate a POST request which saves an entity, to be sure we get the same value in each storage

[zinigor]

Looks good, my only worry is that the repeater field now expects an unslashed entry, so any other clients that may pass a slashed entry into the repeater will get garbled data. I don't know if it's a problem though, probably not?