WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 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 10 years ago.

Download all attachments as: .zip

Change History (10)

#1 @donncha
10 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! :)

#2 @Otto42
10 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?

#3 @donncha
10 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!

#4 @barry
10 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.

#5 @markjaquith
10 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

#6 @markjaquith
10 years ago

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

#7 @markjaquith
10 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

#8 @westi
10 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?

#9 @Otto42
10 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.