WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#22944 closed defect (bug) (fixed)

Scheduled posts trigger the non-unfiltered_html filters (regression)

Reported by: Otto42 Owned by: nacin
Milestone: 3.5.1 Priority: high
Severity: critical Version: 3.5
Component: General Keywords: has-patch commit
Focuses: Cc:

Description

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.

Attachments (4)

22944.patch (827 bytes) - added by SergeyBiryukov 4 years ago.
22944.2.patch (1.0 KB) - added by SergeyBiryukov 4 years ago.
22944.3.patch (1.1 KB) - added by SergeyBiryukov 4 years ago.
22944.test.patch (967 bytes) - added by SergeyBiryukov 4 years ago.

Download all attachments as: .zip

Change History (24)

#1 @Otto42
4 years ago

  • Priority changed from normal to high
  • Severity changed from normal to major
  • Summary changed from Scheduled posts trigger the non-unfiltered_html filters to Scheduled posts trigger the non-unfiltered_html filters (regression)

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

#2 @markoheijnen
4 years ago

Isn't this then for milestone 3.5.1?

#3 @SergeyBiryukov
4 years ago

  • Milestone changed from Awaiting Review to 3.5.1

Moving for investigation.

#4 follow-up: @Otto42
4 years ago

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.

#5 @nacin
4 years ago

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.

#6 @esmi
4 years ago

  • Cc esmi@… added

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).

#7 in reply to: ↑ 4 @SergeyBiryukov
4 years ago

  • Keywords has-patch added

#8 follow-up: @nacin
4 years ago

  • Keywords needs-unit-tests added

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.

#9 @nacin
4 years ago

  • Keywords commit added
  • Severity changed from major to critical

#10 @georgestephanis
4 years ago

  • Keywords needs-docs added

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

#11 @SergeyBiryukov
4 years ago

  • Keywords needs-docs removed

#12 in reply to: ↑ 8 ; follow-up: @SergeyBiryukov
4 years ago

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.

#13 @toscho
4 years ago

  • Cc info@… added

#14 in reply to: ↑ 12 @nacin
4 years ago

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.

#15 @nacin
4 years ago

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.

#16 @nacin
4 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

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.

#17 @nacin
4 years ago

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.

#18 @nacin
4 years ago

  • Keywords needs-unit-tests removed

#19 @Japh
4 years ago

  • Cc japh@… added

#20 @jartes
4 years ago

  • Cc jartes added
Note: See TracTickets for help on using tickets.