[wp-trac] [WordPress Trac] #60645: Add pre-fire hook for cron

[WordPress Trac]

#60645: Add pre-fire hook for cron
-------------------------------------------------+-------------------------
 Reporter:  kkmuffme                             |       Owner:  audrasjb
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.6
Component:  Cron API                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-docs   |     Focuses:
  dev-feedback                                   |
-------------------------------------------------+-------------------------

Comment (by kkmuffme):

 >Detecting cron jobs without any callbacks registered can be done via the
 pre_reschedule_event filter. If no callbacks are registerd then the hook
 can be removed and rescheduling overridden.

 Thanks for the suggestion, but it can't be used because:
 - the function can be called from arbitrary locations
 - there are tons of hooks that will run after that (all of which cannot be
 used for this, since those hooks are also called in various other cases,
 not only in processing) that could add an add_action

 >I think the hooked function for the cron job loading the files is the
 correct approach as each callback should be self-sufficient in the event
 it is fired directly.

 I think that's a misunderstanding from my original text (it sounds
 differently in my last comment, which is probably why): the hook is used
 to LOAD the callback in the first place. (the add action which will run on
 the cron event isn't loaded at all but only loaded by this new action)
 Without the new hook, there's no callback.

 This avoids having to instantiate 1000s of classes that may potentially
 have an add action in cron on every cron request - instead the class will
 only be instantied if the event using the class/file is actually executed.
 Leading to
 a) faster cron execution (since that is an issue already, since cron
 starts to time lag extremely quickly)  b) lower PHP memory consumption and
 c) avoids executing old code (which has been an issue in CD for us in some
 cases, since we have a cron timeout of 15 minutes, and some
 plugins/classes were updated in the meantime, leading to the execution of
 old code)

 Another thing we started to use this hook is to continuously re-check
 environment conditions - e.g. wp_die if the site suddenly switched to
 maintenance mode, the DB version changed,... to avoid corrupting data or
 producing tons of notices as those are regular issues that happen when
 using an actual PHP-CLI cron.

 >There are also some backward/forward compatibility issues with WP-CLI to
 consider

 The existing hooks cron_reschedule_event_error and
 cron_unschedule_event_error are missing in CLI already too, so that
 wouldn't be an issue.

 ---

 Are there any downsides to adding this action?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60645#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform