[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.7
Component:  Cron API                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-docs   |     Focuses:
  dev-feedback                                   |
-------------------------------------------------+-------------------------

Comment (by coquardcyr):

 Replying to [comment:11 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?


 I don’t see the value of this new action.

 This was justified by two use cases:
 The first one is solved by the filter @peterwilsoncc proposed.
 The second use case is not really clear.
 From what I understood, it seems to be a way to reduce memory consumption
 and avoid old code usage.
 However, I don't really see why checking for this right before firing the
 cron hook would change anything about theses points as it is exactly the
 same environment and we could instead directly use the cron hook to make
 theses checks.

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