Hide backend causes 500 error

This worked for me:

– Rename the plugin directory with FTP
– Login the website and go to plugin section
– Rename the plugin directory to original name
– Refresh plugin section

@jaap de Wit
Yes! This magic works. Thank You very much!

I’m having the same issue, but unfortunately the steps noted by @hitec4ever don’t work for me. Maybe I’m missing something.

– Is iThemes supposed to be active or inactive when you change the directory name?
– Am I supposed to be changing “better-wp-security”, or do you want me to change the actual “plugins” folder?
– Is the Hide Backend feature supposed to be enabled or disabled before trying any of this?

I just want to add that while I get the 500 Error Chrome, I don’t get the error when running under incognito view.

More details that I should have added to begin with:
– This only effects sites that have recently been upgraded to WordPress 4.8. It doesn’t happen to any other sites.
– The 500 error happens in Chrome and IE, but not in Chrome Incognito or Firefox.
– Each time I reload Chrome while the 500 Error is displayed, large “core” dump files are created in my root directory. They are large enough to fill my allocated hosting.

@mattkslx I’ve noticed that it only happens the moment I’m trying to go to the custom login url of the website. And yes, it also seems to happen only with WP 4.8 sites.

To answer your questions:

– iThemes is still active since it triggers the error. When I get the error I change the directory name to ithemes-security-pro.old (so not the plugins dir). Then login through the normal url /wp-admin.
– Go to plugins section, you will see the ithemes plugin is disabled
– Rename the directory back to it’s original name with FTP
– Refresh plugins section, ithemes plugin should be enabled again.
– The hide backend feature is still enabled during the process. Probably another workaround for this issue is to disable it in the correct database table.

Hope this will help.

@marekrz

Ok, so the @hitec4ever workaround helped you get back into the WordPress Dashboard.
BUT its not a solution for the root cause.

We don’t even know what the root cause is … Obviously its related to the Hide Backend feature. But that’s all we know. We don’t know what web server (version) and PHP version is being used. And we don’t know what plugin entries are added in the .htaccess (Apache) or nginx.conf (Nginx) file.
Last but not least we don’t know what extra info is available in the web server error_log.

So if you want to continue using the Hide Backend feature without hitting the 500 Internal Error msg you’ll need to investigate this a little bit further and/or provide ALL info that will enable people (like me) to identify the root cause.

Correct me if I’m wrong but this seems to be specific for certain 4.8 sites.
So it doesn’t seem to be generic even though several people have confirmed to hit a similar/identical issue.

@pronl I’ve openend a support ticket with iThemes last week since I have a subscription. Curious what they can find out. I’ve also discovered the problem happens in Chrome only and can also be solved by clearing the cache.

Further details:

– WP 4.8
– iThemes security pro 3.9.0 with hide backend enabled
– PHP 7

In the logs I see:

On apache:
[Mon Jun 19 06:49:39.824088 2017] [proxy_fcgi:error] [pid 8312] [client 127.0.0.1:45415] AH01067: Failed to read FastCGI header
[Mon Jun 19 06:49:39.824154 2017] [proxy_fcgi:error] [pid 8312] (104)Connection reset by peer: [client 127.0.0.1:45415] AH01075: Error dispatching request to :

On Nginx it’s this error:
2017/06/15 12:10:12 [error] 13221#0: *5102088 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xx.xxx.xxx.xx, server: https://www.websiteurl.nl, request: “GET / HTTP/1.1”, upstream: “fastcgi://unix:/var/run/php/php7.0-fpm.sock:”, host: “www.websiteurl.nl”

@hitec4ever

Ok, that’s something I can work with.

A quick Google search on the Apache “AH01067: Failed to read FastCGI header” msg seems to point in the direction of the PHP OPcache module.

If PHP OPcache is enabled on the problematic env(s) its worth to try and disable it.
Not a solution but it will help determin whether this is also a PHP OPcache related issue.

If not we can rule OPcache out ??

@hitec4ever Thanks for the extra info. What you suggested is what I did after reading your first post, but it didn’t work.

Turns out it wasn’t just sites on WordPress 4.8 that had the 500 error. I was actually able to fix it by just clearing the cookies in my browser (I usually just clear the cache). I don’t know why that worked, but it did.

Yes, deleting the site’s cookies solves the problem but temporarily, only 1 time.
After that the issue re-appears again and you’ll have to delete them again, and again…

@hitec4ever
Your solution with renaming the folder seems to also work but there is something I don’t well understand: when you rename the plugin’s folder, the plugin just gets de-activated and then you need to re-activate it again once your revert the folder’s name to the initial state.

Why then just not simply de-activate and re-activate the plugin?

iThemes fixed this issue yesterday in ithemes security pro version 4.0.0. Changelog:

4.0.0 – 2017-06-21 – Chris Jean & Timothy Jacobs
Bug Fix: Fixed an infinite loop that could occur when expiring a cookie and Hide Backend is enabled.

@hitec4ever
Thanks for this, waiting for the free version update.

Any news when the update for the free version will be published?

Being a developer myself, I can’t understand why a developer would not patch a serious bug like this in all versions as the core code would be the same.

I like iThemes Security because I have other security (CSF LFD Firewall) and needed a solution that I can configure to be lightweight and not duplicate security functions I already have but to be honest I have seen many strange themes with this plugin in the 5 months I’ve used it like this error being discussed and periodically (no pattern) getting database backup emails, 5 in a row, when I have database backup disabled and have not made any settings changes. It is worrisome when a security plugin is behaving inconsistently and even more worrisome that they are not applying bug fixes consistently across all versions.

• This reply was modified 7 years, 4 months ago by consultant1027.