Conversation
supportHi, I am using this plugin in multisite, network activated. It does a decent job of securing cron jobs, however it seems that it is declaring DOING_CRON on every single page load (even if it’s not a cron request). I have declared DISABLE_WP_CRON true and define(‘ALTERNATE_WP_CRON’, false); but I am still getting that on every page within the network. How can i stop this behaviour? (only happens when the plugin is active)
I just want to add… this seems to be a pretty serious issue, since many plugins (including ours) rely on being able to correctly determine whether we are being called from inside a cron task or not. The way to do this is by checking DOING_CRON… but defining DOING_CRON as “true” all the time, even when it’s not really a cron request, makes doing so impossible. In 4.8 WordPress added a new function wp_doing_cron() which also relies on checking DOING_CRON, so this core function would also be broken by WP-Cron Control. The problematic code is in validate_cron_request(): // for all other cases disable wp-cron.php and spawn_cron() by telling the system it's already running if ( !defined( 'DOING_CRON' ) ) define( 'DOING_CRON', true ); // and also disable the wp_cron() call execution if ( !defined( 'DISABLE_WP_CRON' ) ) define( 'DISABLE_WP_CRON', true ); Honestly I don’t see the reason for defining DOING_CRON here… I think that defining DISABLE_WP_CRON as true would be sufficient to prevent cron jobs running on their own. As a temporary workaround to anyone experiencing this issue, I would suggest you either comment out the “define( ‘DOING_CRON’, true );” line referenced above, or if you don’t want to modify the plugin file directly you could try adding the following snippet to your functions.php file: add_action( 'init', 'sliced_fix_wp_cron_control', 9 ); function sliced_fix_wp_cron_control() { if ( ! defined( 'DOING_CRON' ) ) { define( 'DOING_CRON', false ); } } What this does is it runs just before WP-Cron Control and defines DOING_CRON as “false”… preventing WP-Cron Control from defining it as “true”. Since PHP constants can only be defined one time, the later attempt will fail silently. (Or, depending on your PHP error reporting setting, it may emit a “Notice: Constant DOING_CRON already defined” message, but this is harmless.) If we actually *are* in a cron request, DOING_CRON will have already been defined true by WordPress (see wp-cron.php, line 22), and the above snippet won’t come into play. Thus we can check whether DOING_CRON is true or false and act accordingly. This is less than ideal, however, because many plugins may only check to see if DOING_CRON is defined… not whether it is true or false. In these cases the above code snippet won’t help. I hope that one of the authors of WP-Cron Control takes note and comes up with a permanent solution to this. If I can be of any assistance, please let me know. Regards, David Grant Developer of Sliced Invoices
Hi David, thank you so much for your support. I actually started this ticket on your helpdesk but I am really happy to see you go beyond to help out. I hope the plugin developers get wind of this issue and patch it in an upcoming release. In the meantime I have commented the line out and the issue seems to be resolved. I will update this ticket if I notice other issues with this fix
I just want to add… this seems to be a pretty serious issue, since many plugins (including ours) rely on being able to correctly determine whether we are being called from inside a cron task or not. The way to do this is by checking DOING_CRON… but defining DOING_CRON as “true” all the time, even when it’s not really a cron request, makes doing so impossible. In 4.8 WordPress added a new function wp_doing_cron() which also relies on checking DOING_CRON, so this core function would also be broken by WP-Cron Control. The problematic code is in validate_cron_request(): // for all other cases disable wp-cron.php and spawn_cron() by telling the system it's already running if ( !defined( 'DOING_CRON' ) ) define( 'DOING_CRON', true ); // and also disable the wp_cron() call execution if ( !defined( 'DISABLE_WP_CRON' ) ) define( 'DISABLE_WP_CRON', true ); Honestly I don’t see the reason for defining DOING_CRON here… I think that defining DISABLE_WP_CRON as true would be sufficient to prevent cron jobs running on their own. As a temporary workaround to anyone experiencing this issue, I would suggest you either comment out the “define( ‘DOING_CRON’, true );” line referenced above, or if you don’t want to modify the plugin file directly you could try adding the following snippet to your functions.php file: add_action( 'init', 'sliced_fix_wp_cron_control', 9 ); function sliced_fix_wp_cron_control() { if ( ! defined( 'DOING_CRON' ) ) { define( 'DOING_CRON', false ); } } What this does is it runs just before WP-Cron Control and defines DOING_CRON as “false”… preventing WP-Cron Control from defining it as “true”. Since PHP constants can only be defined one time, the later attempt will fail silently. (Or, depending on your PHP error reporting setting, it may emit a “Notice: Constant DOING_CRON already defined” message, but this is harmless.) If we actually *are* in a cron request, DOING_CRON will have already been defined true by WordPress (see wp-cron.php, line 22), and the above snippet won’t come into play. Thus we can check whether DOING_CRON is true or false and act accordingly. This is less than ideal, however, because many plugins may only check to see if DOING_CRON is defined… not whether it is true or false. In these cases the above code snippet won’t help. I hope that one of the authors of WP-Cron Control takes note and comes up with a permanent solution to this. If I can be of any assistance, please let me know. Regards, David Grant Developer of Sliced Invoices
Hi David, thank you so much for your support. I actually started this ticket on your helpdesk but I am really happy to see you go beyond to help out. I hope the plugin developers get wind of this issue and patch it in an upcoming release. In the meantime I have commented the line out and the issue seems to be resolved. I will update this ticket if I notice other issues with this fix