Shield Security Automated Scans - Server Settings

Sadly for me automated scans are still not working with 7.0.4, whether on CP or WP. All other crons on the sites are running, and on crontrol I can see that the timing cycle resets itself every 24 hours as it should.

I could offer to provide admin and FTP access but I can’t provide access to raw Apache server logs, only the PHP error log.

When I get a moment I’m going to give it one more try by uninstalling Shield, clearing out its settings in the database and removing all its crons, then reinstalling 7.0.4 from scratch.

1 Like

So, if it’s both CP and WP it sounds like a problem at your server. Can your host have a look at the Apache server logs to see what is happening?

1 Like

My host is SiteGround (both sites are on a GoGeek package) and I’ve just spoken to SG, who have told me that there are NO entries in the error log for the sites in question.
Basically, on one CP site and one WP site, both using a very simple TwentyTwelve or TwentySixteen child theme, all crons are running EXCEPT the Shield ones. And no errors are being generated, either by Apache or PHP. Shield 7.0.4 is installed on both.

1 Like

If you go into crontrol and choose “run now” does it run?

Is it possible to add the command as a cron job in cpanel and test to see if it works that way?

1 Like


Okay, I’ve made a tweak to a bit of code in the hopes that this might solve it. Unfortunately without a view on any errors, this might be tricky to narrow down. Thanks for your patience while we work through it though!

If you’d like to test it, you can download the build here:

For a bit of background, one possible reason the scans aren’t running is if WordPress automatic updates is running on the same cron and executing before the scans get called (regardless of whether any updates occur). This clash would result in false results from the scans as there’d be a mismatch between versions and files. So, I’ve tweaked it such that it’ll only prevent the scans running if no actual updates were run during the auto-updates process.

So what you could do to really make sure there’s no interference from auto-updates, as well as install the test build above, is temporarily disabled WordPress automatic updates. You can do that within Shield itself.

If the scans run successfully overnight on that test build with auto-updates disabled, then for the next run, re-enable auto-updates inside Shield and it should still work.

Hopefully this may solve the issue.

Yes, if I trigger it manually from the crontrol cron events page, it runs, and the ‘time last run’ updates on the shield dashboard page.

I don’t know how to add a cron in CPanel - never had to before.

All WordPress auto updates (major, minor, etc) are disabled in all my sites.

This wont matter. The code that was there will still be affected whether they’re enabled or not. The change I’ve made works around it.

Hi Paul. Despite having said earlier the problem was solved for me, I’m still having problems.

I do a fresh install of Shield and the scan crons can be seen in WP Crontrol. I watch while it comes around to the time and it says they run, then changes to same time tomorrow, but there is nothing logged in the dashboard to show they have run.

Now here’s the weird part - if I edit the cron job to make it 5 minutes into the future, it runs again… and this time it correctly shows up in the dashboard with the revised time.

I’m just waiting now to see if it will work correctly again tomorrow at the new time.

Hopefully you can make some sense of this! :thinking:

Are you running the latest development version I mentioned a few days ago?

Actually I think I’m getting muddled with the versions. :roll_eyes:

Sorry. Leave it with me… still testing.

Hi Paul. Can confirm that automated scans are running for me. Sorry for the confusion… I was getting my versions mixed up! :exploding_head:
All good.


Hi again Paul,

Just FYI, I have upgraded to the new RC1 version and Shield is starting to send me “Warning - Unrecognised WordPress Files Detected” emails as it does the daily scans of files:

Hi !

The Shield Unrecognised File Scanner found files which you need to review.

It’s listing these 2 files:

Easy enough to flag them to ignore.

1 Like

Hi @ozfiddler, you can delete these two files. They were renamed/removed in 1.0.0-rc1. In future releases we’ll handle this situation during the update.

So I would say that Shield is working exactly as intended here. @Paul nice job, I am curious what kind of setup you are using to verify ClassicPress core files.


I can confirm the cron scans are now running automatically on CP and WP with the latest development version zip of Shield installed.

So hopefully the changes in this dev version will make it to a numbered release soon?

Thanks Paul for your efforts on this.


Great stuff, that looks promising that a new release was pushed and Shield saw the files as unrecognised.

Shield is operating as intended if a release changes the set of core files but doesn’t delete the old files upon upgrade - that literally means they’re files in the core directories that aren’t official (anymore)

Glad to hear it’s all working as normal via the crons, thanks for testing and your patience while we dug through the issue!


Thank you for your support too Paul. Very much appreciated. :clap::clap:

Thanks @james I’m just using the CP releases github repo to get the core files. Each individual site will cache the file hashes, but I’d hope to move to a central service once CP gets that in-place, or we build it ourselves.


We’ll be building a file-hashing service ourselves - @invisnet is the person who has done the most thinking and coding about this so far.

What you are doing now sounds right for our official releases.

There are actually two possible release repositories - if the classicpress_version() contains +migration or +nightly then you should look in instead.

These versions correspond to the slightly different ClassicPress builds used by the migration plugin to switch sites from WordPress, and nightly release builds, respectively.

I am happy to answer any questions about any of this. In the meantime here are some more technical details that I wrote up previously for another developer:

Here is how you can detect a ClassicPress version number and get the corresponding zipfile for that release:

  • If function_exists( 'classicpress_version' ) , call it to get the ClassicPress version number
  • Look up the full version number in the GitHub API under ClassicPress/ClassicPress-release (example URL). This will catch sites where ClassicPress was installed from scratch or upgraded to a new build after migrating from WordPress.
  • If not found there, look it up in ClassyBot/ClassicPress-nightly (example URL). This will cover sites that were migrated from WordPress to ClassicPress, or people who are running the ClassicPress nightly builds.
  • If the response key assets[0].browser_download_url is set, use it (only true for the +migration.YYYYMMDD builds from the ClassicPress-nightly repository). Otherwise, use the zipball_url response key.
  • If no release data was found, then the site is not using an official build of ClassicPress and this scanner is probably not the right tool to be using.

Any code checking the GitHub API should be able to handle redirects because we may transfer or rename these repositories in the future (especially the nightly builds). Other than that, we’ll always publish our releases to GitHub in this way, so you can rely on this structure for the future.

We have much more planned here, including documentation for people who are interested in verifying our existing chain of trust involving signed git tags, and providing and using a file-hash API ourselves. But that is for another day.


@james great, thanks for all the info. I’d say that, for the moment, we’d only be supporting official production builds/releases here until everything settles down and fixes. But it’s good to know how to detect what might not be an official version number.



A post was split to a new topic: Anti-Malware compatibility with ClassicPress