iThemes conflict(?) causing random 500 errors on Chrome

[MarioKnight]

Over the past couple of weeks, I have been getting reports of different people getting random 500 errors on a couple of sites. At the time, I believe it to just be Chrome, and even put in a ticket at https://bugs.chromium.org/p/chromium/issues/detail?id=607572 about it. In attempts to troubleshoot what I could on my end, I have been able to determine that there is something with the combination of Comet Cache (Pro?) and iThemes Security causing this.

I have kept the non-working tab open to properly test. When deactivating iThemes on a different machine and refreshing the non-working tab on my laptop, the page loads with no issues. Reactivating the plugin and refreshing on my laptop, the 500 error returns. I have had colleagues and clients come to me before I got this confirmed, and I see the common links between the sites are that they run up to date WordPress installs with up to date active iThemes Security and active Comet Cache Pro. After doing the above, I also deactivated Comet Cache Pro, got the site back, but on re-activation, the site did not return to 500.

In searching for any sort of potential previous reports of the issue, I came across this thread - https://wordpress.org/support/topic/ithemes-security-throwing-semi-random-internal-server-500-error?replies=13 - with no real resolution, despite a fair amount of research and information. Continuing on from that thread, these sites have not had the file change detection function active at any point. The .htaccess files of all contain the stock WordPress code, the iThemes add-ons, GZIP compression, and some basic redirect rules.

For server logs, the apache error logs for the reported sites only show blocks as such:

[Tue May 03 13:04:32 2016] [error] [client 162.158.126.23] Premature end of script headers: index.php
[Tue May 03 13:13:19 2016] [error] [client 162.158.126.23] Premature end of script headers: index.php
[Tue May 03 13:13:49 2016] [error] [client 162.158.126.23] Premature end of script headers: index.php
[Tue May 03 13:14:04 2016] [error] [client 162.158.126.23] Premature end of script headers: index.php

The access logs also don't really show detail:

162.158.126.23 - - [03/May/2016:13:13:18 -0400] "GET / HTTP/1.1" 500 632
162.158.126.23 - - [03/May/2016:13:13:47 -0400] "GET / HTTP/1.1" 500 632

I'm not sure what else I can really check at this point. The logs sadly did not give much information. It seems that something is happening with the combination of the two plugins but I don't really have the know-how to put together the final pieces in this. Any assistance would be greatly appreciated (though now that my confirmed unworking tab is working, I don't know how well I can test), and if there's anything i can do on my end to help further, please let me know.

[KTS915]

@MarioKnight: I very much doubt that this has anything to do with Comet Cache. iThemes Security has had this problem for years: see https://wordpress.org/support/topic/500-internal-server-error-199?replies=3

That thread is three years old. What exactly are you using iThemes Security for? I suspect there's a much better alternative available.

[MarioKnight]

@KTS915 I doubt this really has anything to do with Comet Cache either, after going crazy trying to determine the scenarios causing the issue, I submitted this here and there for hopes of some resolution. I at least know the team here is very responsive which gives me some glimmer of hope.

Seeing now-multiple threads on how iThemes Security seems to essentially ignore and/or pass the blame on 500 errors is definitely a cause of concern, especially when they are given details on what has been found to cause this specific scenario. If this is something I should expect, then I agree, I'd rather explore alternatives. I like their ability to easily change the login URL, their protection of all areas of sites through their different options, and the ability to control the access/usage of xmlrpc.php . It was already in use on a number of sites when I took my current job, and was working well enough for it to be rolled out on current and new client sites (this also led me to start using it on a couple of my own). However the randomness of 500s appearing out of nowhere a couple of weeks ago is something that can't be ignored. I'd hate to have to replace it on so many sites, but if iThemes chooses to ignore, I guess I will have to.

Like I mentioned, I don't know if Comet Cache can come up with a potential resolution on their end with iThemes Security cookies. If so, awesome in that a big headache can be saved. If not, this ticket can be closed and it would be time to go to the drawing board on my end for alternatives.

[KTS915]

@MarioKnight: I'll be honest; I'm not a fan of iThemes as a company, because I have found all their products to be over-hyped and underperforming. So I would say that what you're seeing is what I'd expect.

For replacements, I'd start by suggesting Jeff Starr's 6G Firewall: https://perishablepress.com/6g/ That's free, but he also sells a plugin if you would prefer.

For easy management of xml-rpc, there are quite a few free plugins on wordpress.org that do just that, or you could use Disabler: https://wordpress.org/plugins/disabler/ Disabler makes it possible to turn off quite a few other things too. Don't be put off by the fact that it hasn't been updated for a while. Its author is Mika Epstein, who's the senior plugins moderator on wordpress.org

As for redirecting the login page, I can just give you some code that you can add to your (child) theme's functions.php file, or you could use it as an mu-plugin.

[MarioKnight]

@KTS915 If you have code for either functions.php or as a mu-plugin, that would definitely be greatly appreciated. This just happened on one of my sites again to one of my friends helping run it, so it's safe for me to "hotshot" alternatives there currently. (Plus it's supposed to start doing some sales next week so I really can't have this behavior)

[KTS915]

@MarioKnight: Sure! This is what I use in my functions.php file on several sites to redirect the login page to nameofsite.com/login/

Just edit '/login/'as necessary (or delete it altogether if you want to login from the home page).

<?php
function possibly_redirect() {
  global $pagenow;
  if( 'wp-login.php' == $pagenow ) {
    if ( isset( $_POST['wp-submit'] ) ||   // in case of LOGIN
      ( isset($_GET['action']) && $_GET['action']=='logout') ||   // in case of LOGOUT
      ( isset($_GET['checkemail']) && $_GET['checkemail']=='confirm') ||   // in case of LOST PASSWORD
      ( isset($_GET['checkemail']) && $_GET['checkemail']=='registered') ) return;    // in case of REGISTER
    else wp_redirect( home_url('/login/') );
    exit();
  }
}
add_action('init','possibly_redirect');

[raamdev]

@MarioKnight The "500 Internal Server Error" is generally caused by problems with .htaccess files (including file permissions for that file that the web server doesn't like), or something pushing over the PHP memory limit.

I don't want to "pass the blame" but this does seem more like an iThemes Security issue, namely because Comet Cache has never had any consistent reports of 500 errors that I can recall and iThemes Security does a lot more "invasive" stuff than Comet Cache does (i.e., it adds a lot more to the .htaccess, modifies the default behavior of WordPress in many ways, etc.

[MarioKnight]

@KTS915 I apparently forgot to thank you for the code, so thank you for that as well as your recommendations. =)

@raamdev I agree, my initial post here was mostly a copy and paste from my submission to them as I was in a rush. I was moreso hoping for the very slim chance that something could be identified here and potentially make some sort of fix that they cannot. It's been crazy trying to get this figured out while putting in tickets to any moving part for this scenario, and frustrating to see that the main cause (iThemes Security) is literally the only place where the issue is refused to be acknowledged. =(

Thank you for at least taking the time to respond with possible suggestions, the support here is great which is one of the reasons I'm happy having two licenses (one for personal use and one for my employer). On my site that was showing the issue, I replaced iThemes Security with WordFence and alternate login URL hiding where the issue has not come back. It looks like I'll have to do that with our client sites as well, since we obviously can't risk random errors. Thanks again, and I'm going to close this issue out here.

[raamdev]

Thanks for the update and for closing this, @MarioKnight. :-) I also wanted to say +1 for Wordfence. They seem like a great company who stays on top of things, which is exactly what you'd want to see from a security-focused business.