Chazz the Elder

Thank you, but that’s not quite what I was looking for. My working assumption at the moment is that the file system was disturbed, but the database seems to have been unscathed. In the case of Wordfence, removing only its working directory (wflogs) and allowing it to repopulate resolved the issue. Rather than completely removing and reinstalling the Yoast SEO plugin, I was thinking that if Yoast had a similar area where it kept files, clearing that and allowing it to repopulate might solve the issue there as well. Does Yoast keep all its working information in the database?

The only way to get the site back on line was to rename the wflogs folder and create a new one, which WordFence started populating as soon as site access was regained. We had been using Wordfence without issue for several years before that, and the issue has not recurred in the two weeks or so that we’ve been back on line; so I’m not sure of the value of switching to database access at this point. I’m reasonably certain that reverting to the saved wflogs directory will result in the problem reappearing. If the issue does reappear, we’ll definitely try the mysqli approach as a recovery technique.

I’m sorry, I should have responded sooner with a bit of detail. It would appear that the message being logged was from something else, because while it seems to occur with approximately the same frequency, the timing is not quite the same. Annoyingly, the failure seems to generate no log message at all.

And I’m certain at this point that it is WordFence failing, because the eventual cure was to remove the wp-content/wflogs directory. Of course, that also put the WordFence firewall back into learning mode, but even learning mode is better than nothing, particularly as evidence suggests mine is one site that’s targeted in a current brute-force attack.

If there is useful diagnosis that can be done using the wflogs directory at this point, I have saved its contents; I can zip that up and forward it if that would be useful.

The thing is, if I rename the folder back to “wordfence”, the “Access denied” message returns on every page of the site. If I have it renamed “wordfence-“, I can access the admin pages of the site, and from there I can select Add Plugin, and retrieve a fresh copy of the Wordfence plugin from the repository; it does not complain while installing, which would suggest thatpermissions are correct; and as soon as I activate the new plugin, the site returns to Access Denied status again. I don’t have CLI or SSH access to the site – it’s shared hosting using cPanel – so checking ownership of files and folders is a long and onerous process involving several mouse-clicks on each and every file in the Wordfence distribution. But as the site dies given an absolutely fresh and error-free installation of the plug-in’s code, I believe I’m safe in assuming that the directory permissions are set correctly.

My current working hypothesis is that a database issue resulted in some data – WordFence Network block info perhaps – being only partially loaded into the database, and the resulting inconsistency is resulting in the WAF blocking all site access. Why that would generate “Access denied” (plain black text on a white screen, nothing else) I don’t know, unless that’s what the host has decided to show for a 500 range error. An error is generated; what I’m seeing is:

PHP Fatal error: Cannot redeclare get_blog_permalink() (previously declared in /home/comme854/public_html/wp-content/mu-plugins/theme-functions/post.php:41) in /home/comme854/public_html/wp-includes/ms-functions.php on line 328

But why that would be generated on a WAF data problem I cannot for the life of me figure out.