WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#4710 closed defect (bug) (fixed)

A small patch to fix future posting

Reported by: donncha Owned by: markjaquith
Milestone: 2.3 Priority: high
Severity: critical Version: 2.3
Component: Administration Keywords: futureposting
Focuses: Cc:

Description (last modified by markjaquith)

Barry figured out that the cron entry the scheduler created was simply appended to the blog cron option. He suggested clearing the schedule before making a new one.
I verified this, and attached is a small patch that calls wp_clear_scheduled_hook() before creating the new schedule entry.

I tried adding wp_clear_scheduled_hook( $hook, $args ) to wp_schedule_single_event() but it didn't work. When $args is an array it doesn't seem to work.
You'll see from the patch I pass $post->ID directly as an int to the clear function. I'm not sure why that didn't work as an array.


Barry's description:

How to replicate:

1) Publish a post with a date in the future

2) Edit that post and change the timestamp to a date further in the future and save the post

If you check the database, you will see that the timestamps have been updated correctly in the posts table, but in the options table, the cron option contains 2 objects in the array -- one with the old timestamp and one with the new one. When wp-cron runs, it checks that option and sees the older timestamp and therefore publishes the post at the incorrect time.

What should happen:

When the timestamp of a future post is changed, the entry in the cron option should be replaced, not appended to.


Attachments (1)

future_posts.diff (453 bytes) - added by donncha 8 years ago.

Download all attachments as: .zip

Change History (10)

@donncha8 years ago

comment:1 @donncha8 years ago

Oh yeah, I should point out that Barry did all the heavy lifting and I followed his directions. If it works he gets the credit, if it breaks, we'll call it a bug! :)

comment:2 @Otto428 years ago

  • Priority changed from high to normal
  • Severity changed from critical to normal

I don't see how, exactly, this would make any difference.

Also, future posting isn't broken. It works for me. So, why do we need this again?

comment:3 @donncha8 years ago

It's broken on WordPress.com and as we share most of the same code I presumed there might be a problem with WordPress.org too. Ignore and feel free to close then!

comment:4 @barry8 years ago

I just tested this against trunk and it is also broken. Seems to work ok in 2.2.2. How to replicate:

1) Publish a post with a date in the future

2) Edit that post and change the timestamp to a date further in the future and save the post

If you check the database, you will see that the timestamps have been updated correctly in the posts table, but in the options table, the cron option contains 2 objects in the array -- one with the old timestamp and one with the new one. When wp-cron runs, it checks that option and sees the older timestamp and therefore publishes the post at the incorrect time.

What should happen:

When the timestamp of a future post is changed, the entry in the cron option should be replaced, not appended to.

comment:5 @markjaquith8 years ago

  • Description modified (diff)
  • Milestone set to 2.3 (trunk)
  • Owner changed from anonymous to markjaquith
  • Priority changed from normal to high
  • Severity changed from normal to critical
  • Status changed from new to assigned
  • Version set to 2.3

comment:6 @markjaquith8 years ago

Donncha neglected to mention the symptom. Snoozing during my talk at WordCamp? ;-)

comment:7 @markjaquith8 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [5853]) Clear old future post cron entry before creating the authoritative one. Props Barry. fixes #4710

comment:8 @westi8 years ago

I guess this also highlights a different bug/feature in the future posting code.

wp_publish_post assumes that the post is ready to be published no check is made on the date on the post at all - shouldn't the hook call a function which checks that the post is actually ready to post?

comment:9 @Otto428 years ago

westi: Problem with that is that if any sort of failure occurs in checking that date, it could stick the post into "future" limbo forever. If the wp-cron job doesn't cause it to publish, it won't get another chance.

wp-cron is already being fired off at the time that the post is supposed to publish. What we have here is a data desync, the time on the post and the time the cron job publishes it are (were) not in sync.

An extra redundant date/time check would have indeed prevented this problem, but it would probably have caused more problems as well.

Note: See TracTickets for help on using tickets.