Open mattoperry opened 7 years ago
Great point. I'd favor filters around all three 'exception' situations (WP_CRON
, WP_CLI
, WP_IMPORTING
) so each can be overridden.
For what it's worth, the way it's setup is deliberately flexible enough to override in a plugin or theme:
if ( defined( 'WP_CRON' ) && WP_CRON && class_exists( 'LTCU_Plugin' ) ) {
add_action( 'init', array( 'LTCU_Plugin', 'instance' ) );
}
For what it's worth, the way it's setup is deliberately flexible enough to override in a plugin or theme:
Hmm maybe I'm looking in the wrong place but I can't find that bit of code?
Apologies for the confusion, that's an example of how the plugin can be enabled during cron jobs. The plugin only excludes wp-cli, cron, and imports by not hooking onto init
. All a plugin or theme has to do is hook that up and it will work.
Ahhh got it. Yes makes total sense.
The code would actually be the following to enable for CRON -- hopefully this gets into standard in WP 3.9 :) Saved literally 10's of hours from an mass update routine, so thank you <3
if (defined( 'DOING_CRON' ) && DOING_CRON && class_exists( 'LTCU_Plugin' )) {
add_action( 'init', array( 'LTCU_Plugin', 'instance' ) );
}
On some very large sites, we've had issues with heavy queries due to counting even if those queries are offloaded to cron. One example is a site with lots of future-published posts which transition to publish at the same moment, a large number of term relationships and lots of terms per transitioning post. Even in cron this caused problems, and it'd be great if we could allow this behavior in that context too.
I'm thinking probably adding a filter is the right way to handle this, though it would need to be pretty early to affect the plugin's setup.