#49520 closed defect (bug) (duplicate)
Feature request: Migrate cron from a single serialized wp_options entry to its own table
Reported by: | archon810 | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | major | Version: | 5.3.2 |
Component: | Cron API | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
For as long as I can remember using WordPress, its Achilles heel has been cron.
cron
is a single serialized entry in wp_options
, and on busy sites is subject to race conditions that oftentimes continuously overwrite the cron
value with outdated data, resulting in:
- completed events coming back (and thus running more than once)
- arguably worse,
schedule_single_event()
losing events because they're overwritten
The latter specifically has long been responsible for the infamous "missed schedule" issue in WordPress - a critical functionality of publishing posts at a certain time being completely unreliable.
https://github.com/humanmade/Cavalcade needed to be created to properly resolve this, but it's a 3rd party solution that isn't as trivial to set up as activating a plugin, and shouldn't be necessary in well-designed software. I see the cron problem as WordPress's biggest and most glaring flaw, and I'm sure many would agree.
So, what's the solution? Can cron be migrated into its own wp_cron table and the related functions made to interact with the migrated data transparently to the user? I know it'd be a pretty big project, but it's one of those bandaids that just needs to be finally ripped off.
#15148 was closed as wontfix
, but I hope the team can reconsider.
Thank you.
Change History (4)
#3
@
5 years ago
- Milestone Awaiting Review deleted
- Resolution set to duplicate
- Status changed from new to closed
I'm going to close this as a duplicate of #15148.
I still consider modifying the Cron storage mechanism plugin territory. For many typical WordPress sites, modifying the storage mechanism may result in a negative performance impact due to the additional database queries.
As you've pointed to Cavalcade, it's worth noting the plugin can be used to modify the storage mechanism without the need for the runner.
To continue using the WordPress loopback requests, you'd need to define define( 'DISABLE_WP_CRON', false );
in your wp-config file, I'd also suggest this mini-plugin as a little sugar to reverse a Cavalcade design decision.
Any thoughts so far?