Conversation
supportHi John, this is about the plugin “WP Statistics”. I’ve checked on a number of sites, and on all of them WP Crontrol says that these hooks have no associated action: wp_statistics_add_visit_hook wp_statistics_dbmaint_hook wp_statistics_referrerspam_hook wp_statistics_referrals_db_hook I submitted a support request to its authors here on wp.org, and received this friendly reply: Each of these is already connected to its corresponding function in the plugin’s codebase. WP Crontrol might not display the internal connections established by the plugin, but rest assured, everything is working as expected behind the scenes. So either that information is incorrect, OR WP Crontrol is not finding, or not able to find, the associated action. Here’s their code: // Add the add visit table row schedule if it does exist and it should. if (!wp_next_scheduled('wp_statistics_add_visit_hook')) { wp_schedule_event(time(), 'daily', 'wp_statistics_add_visit_hook'); } // After construct add_action('wp_statistics_add_visit_hook', array($this, 'add_visit_event')); I’m unsettled as to what’s happening here and would be most greatful if you could shed some light on things! With many thanks, Tim
Thanks for the report. This is due to the WP Statistics plugin only adding callbacks for its cron events when the request is not a request to the admin area. In the code you posted above, the calls to add_action are contained within a guard condition so the code only runs when !Request::isFrom('admin') is true. This means that when you look at the Cron Events screen in the admin area, those events don’t actually have any actions registered and WP Crontrol is correct. Only when the code runs in a request that isn’t to the admin area do those events have callbacks registered. This is covered by the “Conditionally registered actions” section in the WP Crontrol documentation , although this is the first time I’ve ever seen a plugin use a conditional check for an admin area request. That was a long way of saying that WP Statistics should move those add_action calls out of the !Request::isFrom('admin') guard condition. There’s no reason for that code to be conditional.
Thanks so much John for taking the time to explain!
Thanks for the report. This is due to the WP Statistics plugin only adding callbacks for its cron events when the request is not a request to the admin area. In the code you posted above, the calls to add_action are contained within a guard condition so the code only runs when !Request::isFrom('admin') is true. This means that when you look at the Cron Events screen in the admin area, those events don’t actually have any actions registered and WP Crontrol is correct. Only when the code runs in a request that isn’t to the admin area do those events have callbacks registered. This is covered by the “Conditionally registered actions” section in the WP Crontrol documentation , although this is the first time I’ve ever seen a plugin use a conditional check for an admin area request. That was a long way of saying that WP Statistics should move those add_action calls out of the !Request::isFrom('admin') guard condition. There’s no reason for that code to be conditional.
Thanks so much John for taking the time to explain!