[wp-trac] [WordPress Trac] #32656: Add hooks to allow hijacking cron implementation

[WordPress Trac]

#32656: Add hooks to allow hijacking cron implementation
-----------------------------+-----------------------------
 Reporter:  rmccue           |      Owner:
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Cron API         |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 Right now, it's partially possible to hijack wp-cron via the
 `schedule_event` filter. However, there's a couple of problems with it.

 === Cannot Skip Default Behaviour ===
 It's not possible to change the default behaviour of wp-cron safely. If
 you filter on `schedule_event` and return an empty value, the cron
 function (`wp_schedule_event` etc that was originally called) will return
 false immediately.

 While this ''does'' cancel the default behaviour, it causes the function
 to return false rather than the default `null`. In well-written plugins,
 this will cause them to think the event wasn't scheduled or an error
 occurred.

 === Inconsistent Usage ===
 While `wp_schedule_event` and `wp_schedule_single_event` both call out to
 `schedule_event`, the other functions (`wp_reschedule_event`,
 `wp_unschedule_event`, `wp_clear_scheduled_hook`, `wp_next_scheduled`)
 don't. This means that you need to filter at a very low level
 (`pre_option_cron`) to be able to catch these, at which point you may be
 missing the data needed to work out what changed.

 == Proposal ==
 I'd like to introduce a few new hooks here:
 * `pre_schedule_event` to run at the top of `wp_schedule_event` and
 `wp_schedule_single_event`
 * `pre_reschedule_event` to run at the top of `wp_reschedule_event`
 * `unschedule_event` to run at the top of `wp_unschedule_event`
 * `clear_scheduled_hook` to run at the top of `wp_clear_scheduled_hook`
 * `next_scheduled` to run at the top of `wp_next_scheduled`

 These would all take `false` as their first parameter/filterable value,
 and act in the same way as `pre_option_{$option}` -- that is, you can
 return a non-false value, and the function would return that immediately.

 This would make the entire system pluggable, and allow swapping out the
 pseudo-cron for a real jobs system much more easily.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32656>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform