Fatal error: Unknown: Failed opening required

Same problem here.

This was the fix for me: https://premium.wpmudev.org/forums/topic/wordfence-firewall-issue-with-file-wordfence-wafphp

Hi,

You can, alternatively, re-create the file if you know the full path of your hosting account directory. The file belongs in your website’s root folder (where wp-config.php, index.php, etc. reside), and consists of the following:

<?php
// Before removing this file, please verify the PHP ini setting 'auto_prepend_file' does not point to this.

if (file_exists('<full/path/to/directory>/wp-content/plugins/wordfence/waf/bootstrap.php')) {
    define("WFWAF_LOG_PATH", '<full/path/to/directory>/wp-content/wflogs/');
    include_once '<full/path/to/directory>/wp-content/plugins/wordfence/waf/bootstrap.php';
}
?>

Hi digitalchild,

Sorry for the trouble. I cannot think of a situation where this would happen during a Wordfence plugin update. Unless something happened where the web server permissions changed after the last plugin update. Typically this happens when a server path has changed. For example during a site migration. Wordfence uses WordPress built-in functionality to update and should not change server configurations. We are working on some migration documentation that should be in the Wiki soon.

You believe this happened during a Wordfence update? Not during an install, activation, or site migration?

A Wordfence firewall activation is different than an update since it is potentially adding and modifying files. Because of the complexity of the firewall it is more likely an error like this could occur during the initial activation. Especially if the server has an abnormal setup.

You would also see this error if your host moved your site that changed your site’s absolute path.

The Wordfence firewall is still a relatively new feature and we are working out the bugs as fast as we can. Please provide as much information as possible to help us troubleshoot.

Thanks.

I have had the same issue on a client site, though it was only affecting /wp-admin. The issue also started 2 or 3 days ago, but is not related to any updates or changes in the firewall AFAIK, since the client has restricted permissions— unless there was an auto-update.

I was also able to fix it using the solution @et linked to. I’m posting it below for future searchers (to save scrolling through to the comment with the fix):

1. Look for a file in your root WordPress directory (the one with wp-config.php) named .user.ini Now, either:

2a. rename, or backup and delete that file or

2b. edit the file and either comment out or delete the lines:

; Wordfence WAF
auto_prepend_file = '/home/dezi3014/public_html/wordfence-waf.php'
; END Wordfence WAF

If that doesn’t work, look for those same lines in .htaccess and php.ini (location of the latter will vary from server to server)

All that said, it would be nice to know what is actually causing the error, since the call is to a file that actually *does* exist. Knowing the problem will help me know how to prevent it from happening again.

Hi Guys,

What web hosts are you using? We have not had many reports of this issue, outside of site migrations, and need as much information as you can provide.

For reference, similar to @pensato’s directions, here are the steps to uninstall the Wordfence Firewall from the Wordfence documentation: https://docs.wordfence.com/en/Web_Application_Firewall_FAQ#How_can_I_remove_the_firewall_setup_manually.3F and some documentation on Wordfence Migrations: https://docs.wordfence.com/en/Migrating_wordfence

Hello,

This was on mediatemple hosting. I had removed the references from the files mentioned in that domains folder and thought that was it. But it appears that Wordfence has search and destroy and will modify EVERY ini file it finds up the directory tree till it can’t go any higher which is extremely dangerous. It modified the global account ini file that you cannot access via the FTP account. This took out not only this domain but EVERY domain on the account due to how the web root is laid out. I would suggest limiting how and where it modifies the ini files.

Can you add some check code to not do this? That would be great ??

So note to those that have all your domains in the same webroot, be sure to search EVERY ini file above the domain that is toast.

cheers,

Jamie.

Why would all domains be on the same webroot in the first place? Isn’t that highly insecure in that a vulnerability affecting one domain/site would easily spill out into another?

(not arguing – just asking why it would be set up this way – what’s the benefit?)