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.
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.
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!
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.
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.
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:
wp-includes/images/classicpress-logo-dashicon-style.svg
wp-includes/images/ClassicPress-icon-blue-600.png
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.
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!
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 Releases · ClassyBot/ClassicPress-nightly · GitHub 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.
