Facilitate posts storing raw JSON in post_content by short-circuiting KSES and other filters

[westonruter]

When attempting to store arbitrary JSON in WordPress, the post_content field is the logical choice. Using post_content to store arbitrary JSON instead of postmeta is more performant and it also means that the JSON content will automatically get support for revisions.

Storing JSON is done in core now for customize_changeset posts and it is done in the widget_instance post type in the Customize Widgets Plus plugin. In both cases, however, there are challenges when storing the JSON due to filters that may apply on content_save_pre. In particular, the KSES filters will apply on the post_content and strip out markup that is intended to be contained within JSON strings. The solution taken by changesets is to wrap the updates to the customize_changeset post type by the \WP_Customize_Manager::save_changeset_post() method. Before this method calls wp_update_post()/wp_insert_post() it suspends the KSES filters temporarily:

<?php
$has_kses = ( false !== has_filter( 'content_save_pre', 'wp_filter_post_kses' ) );
if ( $has_kses ) {
        kses_remove_filters(); // Prevent KSES from corrupting JSON in post_content.
}
wp_update_post( /*...*/ );
if ( $has_kses ) {
        kses_init_filters();
}

This works, however it is ugly. It also means that post updates via WP-CLI and via the REST API won't work as expected because the filters won't be suspended as in this wrapper method.

One idea is that we could introduce a new post_type_support for json_content, and when the post type supports that, it could bypass any content_save_pre filters applying.

See also #15515.

[TobiasBg]

This would indeed be nice, I've been doing similar tricks in my TablePress plugin, which stores JSON-encoded two-dimensional arrays in post_content:
​https://github.com/TobiasBg/TablePress/blob/master/models/model-post.php#L157-L174

[desrosj]

@westonruter Is this still of interest to you? Are you able to take a first pass?

[westonruter]

@desrosj It's not a priority on my radar now, sorry!

[TobiasBg]

Also see #46316 on why this would be nice after #43187 added another filter on content_save_pre that needs to be removed to be able to store JSON content safely.

[SirLouen]

@westonruter are we still interested on this? It seems that apart from @TobiasBg, it has not had any traction for the last 7 years, so probably most people are fine with the kses workaround for this kind of things.

What do you think?

I'm marking this as close candidate for wontfix but feel free to give your opinion whenever possible, and we will see how to proceed.

[TobiasBg]

Yes, I agree that, given the limited interest and traction this ticket saw over many years, this is not something that is very relevant anymore and probably has potential for unexpected side effects.

[SirLouen]

OK @TobiasBg time to close it then.

@westonruter if you think otherwise, feel free to reopen it or comment, and i will take a second look.

[desrosj]

Just changing to maybelater since it's not something that shouldn't be done, more that there is no pressing need and the surrounding conditions currently don't show a clear benefit.

[westonruter]

I think this is still worth doing. It's something that both core and plugins have to work around. There are CPTs in core where I'm aware of KSES potentially corrupting valid post_content:

1. custom_css which contains CSS (for which KSES can corrupt valid CSS, as seen in #64418).
2. customize_changeset which contains JSON (which has a workaround to bypass KSES).
3. wp_global_styles which contains JSON (which has no KSES override, but Additional CSS appears to be disabled if the user can't do unfiltered_html).

See 64418#comment:16.