[wp-trac] [WordPress Trac] #37542: Taxonomies in cron jobs cause problems

[WordPress Trac]

#37542: Taxonomies in cron jobs cause problems
--------------------------+--------------------
 Reporter:  blatan        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.8
Component:  Cron API      |     Version:  4.5.3
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+--------------------
Changes (by dd32):

 * keywords:  reporter-feedback => needs-patch
 * component:  Taxonomy => Cron API
 * milestone:  Awaiting Review => 4.8


Comment:

 Hey @jrfoell

 Thanks for your demo plugin, and mention of `ALTERNATE_WP_CRON` - It makes
 a lot more sense now!

 `wp_cron()` is hooked on `init` at default; when `ALTERNATE_WP_CRON` is
 defined cron jobs are processed within that function.
 Due to the order of action registration, if a plugin registers something
 on `init` at the default `10` it'll run after the cron has already
 spawned.

 A temporary fix for plugin authors would be to enqueue on `init` at an
 earlier priority - such as `9` or to register them on an earlier hook such
 as `after_setup_theme` (Note: many WordPress functionalities are not
 available before `init`, such as capabilities for users, etc).

 I think we should move `wp_cron()` to being fired on something later -
 `wp_loaded` looks like a better spot. It's after `init` and before
 template functionality. However, it's after the multisite suspended
 checks, so it we'd no longer be spawning cron for suspended multisites..
 which is what #20537 wants anyway. (FYI @jeremyfelt)

 A safer bet, would be to simply move `wp_cron` to running much later on
 `init`, at say priority 100.

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