Scheduled posts trigger the non-unfiltered_html filters (regression)

[Otto42]

To reproduce:

• Create a post
• Put some iframe or embed or whatever code in it, like a youtube iframe:

<iframe width="420" height="315" src="http://www.youtube.com/embed/oHg5SJYRHA0?rel=0" frameborder="0" allowfullscreen></iframe>

• Schedule the post for the future. One minute in the future will do.

When the post publishes, the iframe will be gone.

Something about the future-post triggers the kses filters. Since the user making the post (wp-cron) is unauthenticated, the unfiltered_html cap is not applied, and the filters engage, cleaning the post before it publishes.

Problem found in 3.5. Have not checked 3.4.2 yet to see if this is a regression.

Confirmed this as a regression, problem does not exist in 3.4.2.

Isn't this then for milestone 3.5.1?

Moving for investigation.

Note that the act of publishing by the cron job also appears to create a revision with a post_author of zero. This also didn't happen in 3.4.2.

This is wp_publish_post(). We should restore it to a straight DB call.

It's a shame. wp_insert_post() is our lowest level API, but it just has too much crap in it. We need something lower.

If WP 3.5.1 isn't going to be out for a few weeks, is there any chance of a fix being dropped into the Hotfix plugin? This hitting more than iframe markup. I'm seeing support post complaining that it's hitting script and even div tags (although that's one I haven't confirmed yet).

Related: [21942], ticket:11399:20, ticket:11399:22

Unit tests should cover two situations:

• A future-dated post should be forcibly moved to publish with wp_publish_post().
• A post should not get its content touched by kses when wp_publish_post() is called.

The PHPDoc was changed in [21942] -- after the patch it no longer @uses wp_update_post()

22944.test.patch​ is an attempt at the unit test.

Replying to nacin:

A future-dated post should be forcibly moved to publish with wp_publish_post().

This currently doesn't happen due to the check in wp_insert_post():
http://core.trac.wordpress.org/browser/tags/3.5/wp-includes/post.php#L2817

22944.2.patch​ fixes that, however it turned out that clean_post_cache() is also needed for the test to pass. Added in 22944.3.patch​. Not sure if the test should call it or wp_publish_post() itself.

Replying to SergeyBiryukov:

22944.2.patch​ fixes that, however it turned out that clean_post_cache() is also needed for the test to pass. Added in 22944.3.patch​. Not sure if the test should call it or wp_publish_post() itself.

wp_publish_post() needs to call clean_post_cache() on its own. It did it implicitly in 3.5 via the save_post hook, but that meant we were calling it twice on wp_insert_post(), and that made no sense.

In 1174/tests:

Unit tests for wp_publish_post(). Ensure that:

• A future-dated post is forcibly moved to publish when wp_publish_post() is called.
• A post should not get filtered by kses when wp_publish_post() is called.

see #22944.

In 23206:

Revert [21942] and have wp_publish_post() deal with the database directly. clean_post_cache() is now also called directly due to [21943].

fixes #22944 for trunk.
Unit tests: [1174/tests].

see #11399. see #21963.

In 23207:

Revert [21942] and have wp_publish_post() deal with the database directly. clean_post_cache() is now also called directly due to [21943].

Ports [23206] to the 3.5 branch.
fixes #22944.