ITSEC_CRON (“Failed to Run”)

All scheduled events from the iTSec plugin are named itsec_cron. When scheduling the event there is an extra argument passed that identifies the event.
So based on the info provided in the Site Health there is no telling what cron job failed to run (backup, file_change, purge-log-entries etc).

Probably best to have a look in the iTSec plugin Logs page.

@nlpro ,

As always, thanks for your input. Yes, we did that but nothing related revealed.

However, in the larger scheme of things, we performed additional testing only to find out that WordPress’ Site Health tool is also flagging many other plugins, although our website is running great. Site Check is a new WP tool that is creating a lot of issues for many. Mainly:

(1) It creates several security holes by exposing potential website weaknesses.

(2) For those striving to have the “perfect website,” it’s driving many developers to fix inconsequential issues identified by WordPress’ Site Health tool thus creating other secondary, performance issues (in many cases). This article sheds more light on the topic (and many more out there).

So, in short, we decided to get rid of WordPress’ Site Health tool by adding the following code to our website (via the Code Snippets plugin, not our functions.php file):

// disable the site health menu

function escode_remove_site_health_menu() {

remove_submenu_page( ‘tools.php’, ‘site-health.php’ );

}

add_action( ‘admin_menu’, ‘escode_remove_site_health_menu’ );

// block the site health page screen

function escode_block_site_health_access() {

if ( is_admin() ) {

$screen = get_current_screen();

// if screen id is site health
if ( ‘site-health’ == $screen->id ) {
wp_redirect( admin_url() );
exit;
}

}

}

add_action( ‘current_screen’, ‘escode_block_site_health_access’ );

Done. No worries anymore. It we want to reactivate the tool, all we have to do it turn it back on via the Code Snippets toggle switch.

Cheers!

@jetxpert item 2 on your list seems reasonable, but to run Site Health, you need to be an administrator (or super admin on multisite), who already have full control over the site. How does it create any “security holes”?

After looking into the Site Health code I’m pretty sure this is a false positive and a possible side effect of disabling WP Cron in the wp-config.php file:

define('DISABLE_WP_CRON', 'true');

@galbaras ,

Security holes are (or can be) introduced via the following:

(1) Ability for plugin developers to add or remove their own tests to the tool. The code change could allow the developers to access critical website information (especially if a feedback code is embedded in the plugin).

(2) Plugin developers may add warnings that your site is insecure or poorly performing. This information could be logged in the error or debug logs and exposed through many channels.

(3) Guest Administrators (with malicious intentions) can use the tool to quickly identify website vulnerabilities.

Cheers!

@nlpro ,

Yes, it appears the WP Site Health tool depends 100% on WP CRON. We use a Real Cron Job (REAL CRON), so that’s why we keep getting the “errors.”

Interesting enough, we must still ask the question: Which cron reveals the most accurate Site Health check errors? WP CRON or REAL CRON? ??

Cheers!

@jetxpert again, plugin developers can already do everything they could before, as do admins. Site Health doesn’t give either of them any more ACCESS, which is what a security hole is.

Consider Jetpack, which can already manage your site remotely and keeps synchronising stuff with another system you don’t own. They’ve been doing it since way before Site Health came around.

BTW, the core team knows about the problem with using an alternative cron. See https://core.trac.www.ads-software.com/ticket/47223

• This reply was modified 5 years, 9 months ago by Gal Baras.

@galbaras ,

Thanks for sharing. Glad to know the WP Core Team is aware of this problem (Real Cron Job conflict). Looking forward to their fix.

Cheers!