Plugin Author
Paul
(@paultgoodchild)
I can’t explain this… if the file is there and your site has loaded this far, then everything is included as it should be. The only thing is that perhaps the server couldn’t read the file. The file is there, or you would be having a permanently serious error. I can only put this down to quirks with the new WP error detection system and/or webserver filesystems issues.
There absolutely nothing we can do to assist with these errors. If the plugin is installed, all files are there, then it’s up to the webserver to correctly locate and load these files. If that’s not the case, and the problem persists you’ll need to discuss this with your host.
Sorry we really can’t be of any further help than that…
Thanks Paul, but I’m not quite convinced, yet 😉
I just had a similar notice again on a shield-enabled local test site (with a .test TLD). After logging in (with ‘I’m a human’), the warning was shown in the browser (before the dashboard), and I received the email notice (see below). I reloaded the page. Even though I am using shield’s 2F email auth, I now did see the dashboard (w/o having entered the email verification code) – but with the verification form shown on top of the dashboard, (mostly?) unstyled (so it looked quite broken).
The exact error message did change, though (again, translated, original in German):
“””
An error of type E_ERROR occured on line 221 of file […]/cms/assets/plugins/wp-simple-firewall/src/common/icwp-foundation.php. Error message:
Uncaught Error: Class ‘ICWP_WPSF_WpUsers’ not found in […]/cms/assets/plugins/wp-simple-firewall/src/common/icwp-foundation.php:221
Stack trace:
#0 […]/cms/assets/plugins/wp-simple-firewall/src/processors/base_wpsf.php(53):
ICWP_WPSF_Foundation::loadWpUsers()
#1 […]/cms/assets/plugins/wp-simple-firewall/src/processors/loginprotect_intent.php(76):
ICWP_WPSF_Processor_BaseWpsf->isUserSubjectToLoginIntent()
#2 […]/cms/assets/plugins/wp-simple-firewall/src/processors/loginprotect_intent.php(44):
ICWP_WPSF_Processor_LoginProtect_Intent->setupLoginIntent()
#3 […]/cms/wp-includes/class-wp-hook.php(286): ICWP_WPSF_Processor_LoginProtect_Intent->onWpInit(”)
#4 […]/cms/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array)
#5 […]/cms/wp-includes/plugin.php(465): WP_Hook->do_action(
“””
Whether this is on the core or the shield side I cannot tell.
Plugin Author
Paul
(@paultgoodchild)
I’m honestly not sure what we can do as the plugin developer.
We provide a package that’s installed on your site. If all the files are there it works. If there’s a file missing, it throws an error.
But the file isn’t missing. It’s there. Other than that it being an issue with the site, it’s not a fault of our development. If it repeated with every page load, it would point to a problem with the plugin. Given that it’s intermittent, with the same set of files installed, then the problem is environmental.
I would LOVE to solve this problem… we see it with other people, but then we also see it with other plugins. If you can point to a way to replicate this I would love to investigate it. But fundamentally you’re looking at an environmental issue that we can’t mitigate, and which was probably there, going unnoticed for years, before the new wordpress error detection system…
So I was looking about for possible sources of this problem – turns out it *might* be caused by Opcache or APC cache issues/errors. Again, it’s a server/environment problem, not a code problem, which is only recently highlighted after WP 5.2 was released. You’ll want to test disabling these perhaps on your systems if that’s applicable…
