New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert to custom table #89
Conversation
Moving out of posts, into a table with appropriate indices and unique key constraints
Updates all of the plugin's core classes to use the new event store, primarily through the helper functions I should've introduced in the first place. Still need to update tests and CLI commands
Core resets the option before its tests, so we perform the equivalent. Addressing #90 will make the non-Core approach unnecessary.
… centralization FTW
When running events, lookups will be simplified with this already in the DB
…ip status infinitely
…butes This logic became spread across various classes during initial development, and it's time to consolidate.
Considerable cleanup and simplification along the way
`get_event()` method was removed earlier
The `WP_Query` approach is excessive
When events are capped in this way, if they don't appear in the reconstructed array, they can be continually rescheduled. With the introduction of the block on existing-event creation introduced in 61597bc, this approach should longer be necessary. The creation of duplicates is also greatly reduced by the table's unique key. Fixes #94
…en it will run Race conditions are a concern, so it'd be better not to create the table without some control over when it happens.
…alled site, create table in limited circumstances
…it from the DB version
PHPUnit doesn't load the plugin until after it's called `wp_install()`, which blocks normal table creation and disables the plugin.
…ocess or other need to check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a minor note about possible improvement on how namespaces are referenced in the code.
I still worry a bit about the dynamic table creation, but I think the protections we have in place now will probably be good enough.
remove_filter( 'schedule_event', '__return_false' ); | ||
add_filter( 'pre_option_cron', array( \Automattic\WP\Cron_Control\Events_Store::instance(), 'get_option' ) ); | ||
add_filter( 'pre_update_option_cron', array( \Automattic\WP\Cron_Control\Events_Store::instance(), 'update_option' ), 10, 2 ); | ||
add_filter( 'schedule_event', array( \Automattic\WP\Cron_Control\Events_Store::instance(), 'block_creation_if_job_exists' ) ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: if we add use \Automattic\WP\Cron_Control\Events_Store
to the top of this file, we can simplify the calls to this namespace:
add_filter( 'pre_update_option_cron', array( Events_Store::instance(), 'update_option' ), 10, 2 );
add_filter( 'schedule_event', array( Events_Store::instance(), 'block_creation_if_job_exists' ) );
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I honestly don't know why I didn't use use
anywhere in the tests or CLI classes.
By introducing a custom table with columns and indices specific to the plugin's needs, issues with duplicate events, race conditions that create excessive events, and stale caches are all alleviated. Additionally, by adding a number of utility functions, the plugin's internal consistency is greatly improved.
Some of the changes herein:
Outstanding concerns:
is_admin()
, though, as WP will keep trying to create entriesFixes #24
Fixes #39
Fixes #63
Fixes #64
See #84
Fixes #85
Fixes #90
Fixes #91
Fixes #94