[wp-hackers] post_status = future and pseudo-cron

[Owen Winkler]

Ryan Boren wrote:
> Here's a quick brain storm.  I think we have this simply be a queue of 
> actions with timestamps.

<snip>

Rephrasing my understanding:

A user publishes a post for a future date.
The post page adds that as a post_type = 'future' and sets the date for 
the future.
The post page calls wp_schedule_event($post_date_gmt, 
'publish_future_post', $post_ID); to set up the event.

A few days later, elsewhere in the code...

wp_cron() gets called based on a check of a timestamp (against what?) 
from a location that is yet to be determined (shutdown?).
wp_cron() gets a list of the scheduled events (where was this stored?) 
that have an execution time <= time().
Foreach item in that list, call the assigned plugin hook, with the post_ID.
The plugin hook for 'publish_future_post' has a default sink function 
that publishes the specified post.

Ok.

Is the third parameter of wp_schedule_event() an all-purpose value?  Can 
it be things other than a post_ID?  Can there be more parameters 
(please)?  (I might like to schedule a check to see if a Link needed 
updating, rather than a post, for example.)

Will the pseudocron require that regularly recurring events be 
rescheduled during each execution?  Calling wp_remove_event() as 
described could be a problem for recurring events.

Also, while I'm thinking about it...  What existing hooks will be fired 
during all of this?  My thought is that save_post should fire on every 
save, whether on future posts whose time hasn't come or posts that have 
been published already.  publish_post should only ever be called once 
under normal circumstances - when changing from post_status 'draft' to 
'publish'.  I know others have opinions on this, and although I'm not 
personally concerned about it (thus not attached to this suggestion), 
it's a point for discussion.

Owen