A small patch to fix future posting

[donncha]

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.

---

[donncha]

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! :)

[Otto42]

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?

[donncha]

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!

[barry]

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.

[markjaquith]

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

[markjaquith]

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

[westi]

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?

[Otto42]

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.