Wordfence (WordPress) type E_ERROR error in line 22

Username (e.g. epiz_XXX) or Website URL

epiz_24445062/remi-theriault.com

Error Message

An error of type E_ERROR was caused in line 22 of the file /home/vol5_4/epizy.com/epiz_24445062/remi-theriault.com/htdocs/wp-content/plugins/wordfence/modules/login-security/classes/controller/whitelist.php. Error message: Uncaught Error: Class ‘WordfenceLS\Model_IP’ not found in /home/vol5_4/epizy.com/epiz_24445062/remi-theriault.com/htdocs/wp-content/plugins/wordfence/modules/login-security/classes/controller/whitelist.php:22

Other Information

Wordfence support asks to check with my host provider, please see full discussion here: “An error of type E_ERROR was caused in line 22 of the file “ | WordPress.org

Notably:

Some of the issues look like a possible enforced SSL issue we’ve seen before, but your host may be able to help solve that for you. Even without Wordfence, the cron jobs like the plugin updater will continue to be stuck if the site can’t connect to itself correctly.

Since the SERVER_ADDR displays as 127.0.0.1 , there’s another kind of proxy running locally in addition to Cloudflare, so it’s possible something isn’t right with HTTPS and/or HTTP there.

Towards the top of phpinfo, IPv6 Support is disabled. It’s possible Cloudflare using IPv6 addresses is causing problems too. Your host would ideally need to rebuild PHP with that enabled.

This honestly looks like code corruption, not a network configuration issue.

WordPress Flexible SSL tends to cause issues if it’s not configured correctly.

Please make sure you’re configured your website like this, because this is the only confirmed working method to run WordPress behind Flexible SSL:

Alternatively, you could try working without Cloudflare and see if that solves the issue.

Our servers don’t have IPv6 networking, so Cloudflare can’t connect to us with IPv6 addresses.

Again, if you believe this may be an issue, try going without Cloudflare. Or disable IPv6 mode in Cloudflare.

2 Likes

First, thank you very much for your answer!

Here’s some more info. I did follow InfinityFree instructions for Flexible SSL. I am using the Really Simple SSL plugin, etc. On Cloudflare, my SSL/TLS encryption mode is set to Flexible. The following options were set ON (after setting up Really Simple SSL): SSL/TLS Recommender, Always Use HTTPS, and Automatic HTTPS Rewrites.

Once connected to my admin site and going to the settings of Really Simple SSL, I can see the following message:

The mixed content fixer could not be detected due to a cURL error: cURL error 35: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error. cURL errors are often caused by an outdated version of PHP or cURL and don’t affect the front-end of your site. Contact your hosting provider for a fix

Does that mean that I would need to, for example, uninstall the Really Simple SSL plugin, disconnect CloudFlare, and restart from scratch? Or is there a better way?

Furthermore, on the Really Simple SSL plugin, Enable WordPress 301 redirect is ON, but Enable 301 .htaccess redirect is OFF. Should I switch those two?

Finally, I checked IPv6 mode in Cloudflare and it is disabled (greyed out so I can’t change that).

Thank you!

1 Like

Please turn this one off, it tends to cause weird issues. Automatic HTTPS Rewrites if useful if your website code really won’t let you setup HTTPS URLs in the site itself. Because if that’s an option, you should always use it instead of configuring your site incorrectly and hoping Cloudflare will fix it. Because in spite of the impressive attempt, it doesn’t always work.

This is caused by the way our servers work. If you try to connect from your website to your website, the connection doesn’t go through Cloudflare, it goes straight to our server.

Which setting is this? The Mixed Content Fixer or something like that? If so, you can just skip that setting.

.htaccess redirects should be turned on, they are more efficient than WordPress redirects. Really Simple SSL should also recommend this to you.

2 Likes

Ok, great, thanks! I have turned Automatic HTTPS Rewrites OFF.

I’m now getting a new Wordfence message on WordPress (no idea if it’s related):

The Wordfence Web Application Firewall needs a configuration update. It is not currently in extended protection mode but was configured to use an older version of PHP and may have become deactivated when PHP was updated. You may perform the configuration update automatically by clicking here or use the “Optimize the Wordfence Firewall” button on the Firewall Options page.

I did perform the configuration update automatically by clicking on their button.

I also turned Enable 301 .htaccess redirect ON, and Enable WordPress 301 redirect OFF. However, then I could see a message saying that “No 301 redirect is set. Enable the WordPress 301 redirect in the settings to get a 301 permanent redirect.” So I turned Enable WordPress 301 redirect back ON. Therefore both are ON right now (is that bad?).

Not sure which setting the mixed content fixer message refers to (all messages are together at the top and don’t directly indicate to what they refer). However, I also saw the following option in the Settings menu: “Fire mixed content fixer with different method”. Hovering over the question mark produces the following message:

If this option is set to true, the mixed content fixer will fire on the init hook instead of the template_redirect hook. Only use this option when you experience problems with the mixed content fixer.

I believe I actually am experiencing problems with the mixed content fixer, so I just turned this ON too. Finally, I noticed another option in the Settings: “Mixed content fixer”:

In most cases you need to leave this enabled, to prevent mixed content issues on your site.

I did not touch this one (left it ON).

Edit: After making those changes, I just received yet another email with the same error (~1h after posting).

I think that’s fine. The WordPress redirect won’t do anything when the .htaccess redirect is already redirecting all visitors. So I don’t think it’s a problem to leave both on.

Do you get the emails fairly consistently? If so, you could try turning the mixed content fixer off and see if that stops the emails. In my experience you usually don’t need the mixed content fixer. Once your website is setup correctly, you should not have any mixed content issues anymore.

2 Likes

Alright, good. Let me check: I receive about 7 such emails a month, so I’d say it’s fairly consistent. Ok, perfect, I’ve turned the mixed content fixer OFF now! I don’t use mixed content anyway. I’ll let you know if I receive any new email like this!

Just received the same email again yesterday afternoon. Wordfence support forum says to try disabling the plugins one by one see if it helps. I guess I’ll try that at this point.

Hi there, so after some more troubleshooting with Wordfence support (disabling all the plugins did not help, I still receive the emails), they said the following:

The host needs to solve the issue where the server can’t connect back to itself while Cloudflare is enabled since this is breaking WordPress cron jobs to update plugins etc., not just Wordfence.

The error regarding \WordfenceLS\Model_IP looks to be related to IPv6 support being disabled in PHP. You could try to discover what’s happening in the access logs at the timestamp this the error message occurs.

However, this is still weird as surely I am not the only one using WordPress with Wordfence on InfinityFree… So why would it only happen to me and not all other users out there? That’s the strange thing.

Well, this does seem it would affect everyone using WordPress, WordFence and Cloudflare. And all of those things are quite popular, also among InfinityFree users.

The host needs to solve the issue where the server can’t connect back to itself while Cloudflare is enabled since this is breaking WordPress cron jobs to update plugins etc., not just Wordfence.

It’s a known error from the Site Health plugin too. But so far, I don’t know of any cases where this has had actual, verifiable consequences on a website.

For starters, we don’t (and never have) formally supported using third party nameservers. We’ve condoned it, especially because Cloudflare was the best/only way to get SSL on our hosting. But officially, using our nameservers is the only supported way to host a domain name with us.

If this was a trivial fix, we could probably get it done. But fixing this not a simple bug we can patch, but rather a limitation in the platform architecture. In other words: it’s far from trivial.

Funny enough, for all the issues of our own Cloudflare integration, it doesn’t suffer from this issue because it injects the Cloudflare records into our own nameservers.

Actually, that’s something you could try. Could you enable Cloudflare in our control panel and access your website that way?

The error regarding \WordfenceLS\Model_IP looks to be related to IPv6 support being disabled in PHP. You could try to discover what’s happening in the access logs at the timestamp this the error message occurs.

I have honestly no idea where they get this idea from.

First of all, the error message clearly says: the PHP class Model_IP is missing. As far as I can tell, it’s a custom PHP class from the WordFence code. And if a custom class is missing, that’s usually caused by missing files or a problem with the class loader or something like that. It’s a problem with the code or the specific installation, not a PHP or server issue.

And to my knowledge, there is no such thing as “IPv6 support” for PHP. I’d be happy to consider it if the error can be traced to a native PHP function misbehaving. But again, this issue is traced by a WordFence class not being loaded at that point in the code for some reason, which is completely unrelated to networking.

4 Likes

Alright, so here’s what I’ve done so far: disabled https redirect on Really Simple SSL (both options) and Cloudflare (for now). I’ve changed my DNS nameservers from Cloudflare to InfinityFree on my domain name provider. Then, I tried to activate Cloudflare integration from InfinityFree control panel. I am now getting this message:

CLOUDFLARE ERROR : Sorry there was a problem activating cloudflare for this domain or the email address XXXX@XXXXX, this is normally caused by the email address or domain name already existing on the Cloudflare system.

This error seems clear but in reality, isn’t that intuitive. I suspect it’s because it takes 48 hours for changes to propagate? Or is it because I used the same email address for both InfinityFree and Cloudflare (why would that be the case though? Doesn’t seem like logical behaviour)? If that’s the case, what are my options? Simply change my email address associated with my Cloudflare account?

And just to be clear, this approach will still allow me to benefit from Cloudflare’s SSL, right?

Yep, this is the issue.

The control panel Cloudflare integration also creates a Cloudflare account for you to attach the domain to. While it’s theoretically possible to link an existing Cloudflare account to a hosting provider integration, our panel doesn’t support it.

So you can either change the email address of your hosting account or your Cloudflare account to enable it.

You can probably keep using Cloudflare’s nameservers. Our Cloudflare integration is a bit funky, so using Cloudflare’s nameservers is probably a safe bet.

That said, this is uncharted territory for me too.

Yes, Cloudflare provides SSL on your domain if you use Cloudflare, regardless of whether you use Cloudflare’s nameservers or ours.

2 Likes

I’ve changed my address on Cloudflare and tried again on the Control Panel and now am getting this:

CLOUDFLARE ERROR : CloudFlare is already activated for “remi-theriault.com” under a different account. If you want to enable CloudFlare through this partner, please ;

(the message does not appear completely). So I went and removed the site completely from my original Cloudflare account, and it finally worked in the Control Panel.

I then went to my WordPress and tried to activate SSL with the Really Simple SSL plugin and I had this message: “No SSL detected.” Reloading over https fails: “This site can’t provide a secure connection”.

Then, after seeing your response, I went back and changed the servernames from InfinityFree to Cloudflare again. Problem with SSL didn’t change yet though. Might be DNS propagation (edit: “Cloudflare takes 24 hours to set up a certificate” so since this is technically a new certificate, it should be working tomorrow).

PS: I don’t know if this is related, but I’ve always had difficulty updating WordPress. It keeps failing and sometimes work, it’s a lot of trouble. Having this issue right now too.

2 Likes

Yep, that’s my guess too.

This is unrelated. Updating WordPress and installing/updating big plugins has been an issue for many people here for a long time. We’ve tried many things to make this work, but so far without consistent success.

3 Likes

Hey, just a small update. It’s been over 24 hours now and Really Simple SSL isn’t detecting a certificate so far. On the Cloudflare help page, it says:

If Cloudflare is your authoritative DNS provider, Universal SSL certificates typically issue within 15 minutes of domain activation at Cloudflare and do not require further customer action after domain activation.

So I don’t know if something is wrong (because Cloudflare is my authoritative DNS provider since I point to their nameservers, right?) or if I’m missing something obvious? I thought I didn’t need to take any additional steps to use the SSL certificate before. But by now going through the cPanel instead, do I actually need to do the manual certificate activation now? I tried using the Cloudflare Origin CA certificate but when trying to add it in cPanel (after uploading the files to my site), I got the following message:

The certificate uploaded is NOT for the domain name remi-theriault.com (CloudFlare Origin Certificate was seen).

So I take it to mean that InfinityFree isn’t compatible with the Cloudflare Origin CA certificate right? I can only use the Universal one?

Also, I checked DNS propagation on mxtoolbox and it says: TTL: 5 min. Not sure how to interpret this. Does this mean it’s only supposed to take 5 min for DNS propagation?

Edit: Or do you think maybe I actually have to point my nameservers to InfinityFree instead of Cloudflare in order for this to work? Because when I try to check the Cloudflare nameservers from my Cloudflare account, I actually get this message:

Partner hosted zone

Your DNS zone file is hosted by Byethost, a Cloudflare partner. Manage your DNS records at their website.

Was a bit confused at first because of this:

You can probably keep using Cloudflare’s nameservers. Our Cloudflare integration is a bit funky, so using Cloudflare’s nameservers is probably a safe bet. Yes, Cloudflare provides SSL on your domain if you use Cloudflare, regardless of whether you use Cloudflare’s nameservers or ours.

But then I changed the nameservers to InfinityFree again in the hope that it fixes the issue after seeing this:

Ergastolator1

You can’t use the free SSL without changing the nameservers to our ones.

OK, the SSL is working this morning! I guess I had to wait 48 instead of 24 hours and use InfinityFree namerservers :slight_smile:

Thanks so much for your help and patience. Now that this is done, I will let you know if I keep receiving the original error emails!

Welp, I guess my idea didn’t work. It was an experiment. But I should have anticipated that Cloudflare wouldn’t issue a certificate on a domain name that didn’t resolve to the right namesevers.

Yes, that will work. Although then you’re dealing with the funky Cloudflare control panel integration, so be warned.

Universal SSL encrypts the connection between your visitors and Cloudflare. The Origin Certificate encrypts the connection between Cloudflare and the hosting server. They are different certificates for different purposes.

But yes, our panel doesn’t accept Origin Certificates. It only accepts certificates which are trusted by browsers, and Cloudflare’s Origin Certificates are only trusted by Cloudflare.

4 Likes

Alas, I received another type E_ERROR error in line 22. Do you know if that excludes the possibility of “the site not being able to connect to itself” issue as the cause of this error? Should I go back to Wordfence and say that this was not the issue?

Or perhaps I should just give up haha, as besides the emails there is no noticeable issue with my site :3

They may still claim that IPv6 support is the issue, which wasn’t “fixed”. I still think it’s a problem in the code. You can try to contact them again, of course, but they may not budge on their original standpoint.

That’s also a good point to consider! I can’t make that decision for you. But if your site works, then it works.

2 Likes

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.