500 internal server error

@liquidcross

Probably an issue in the .htaccess file …

NO matter which Save All Settings button you click on ALL settings are saved …
Restore the .htaccess file from a recent backup and compare it with your current .htaccess file …

Also check your Apache error_log for errors …

dwinden

Gotcha. I couldn’t see what had changed in that .htaccess file; if I remove all of the iThemes stuff from it, will the plugin rewrite it correctly the next time I save settings?

Yup.

dwinden

Tried that, and the good news is that the site loaded immediately once I uploaded the new htaccess file. Bad news: after saving settings in iThemes Security (WITHOUT making any changes), it immediately breaks the site again and returns the 500 error. I don’t know what in the htaccess file could have caused it.

After completely uninstalling the plugin, then reinstalling and checking off preferences one by one, I’ve found that the 500 error was caused if either of these two options are checked:

Banned Users: Hackrepair check
System Tweaks: Disable PHP in Uploads

Once those settings are written to the htaccess file…the 500 error shows up after the site is refreshed. The odd part is that BOTH of these options have ALWAYS been checked, from the first time I installed the plugin ages ago. The change I made this morning (the WPtouch exclusion noted above) actually did NOT add anything to the htaccess file. Just the very act of saving the file without changes was enough to do it, since the Hackrepair and Disable PHP functions were in there. I’ve since gotten the plugin settings back to where they were minus those two, and everything works fine after multiple saves to htaccess.

Makes no sense to me; any ideas? I’m contacting my webhost about this, too.

@liquidcross

The iTSec plugin HackRepair.com template files (*.inc) were fairly recently updated. Not a positive change so I recommend to disable the feature till iThemes produces a fixed copy …
(Don’t hold your breath …)

There also was a recent change to the Disable PHP in Uploads feature. There is more info in this topic.

And finally you are absolutely correct the WPtouch exclusion itself does not add any specific changes to the .htaccess file.
Any changes to this setting are stored as an option in the database.

I guess one of the recent iTSec plugin update(s) (4.8\4.9\5.0.1) broke your specific configuration…

dwinden

Thanks so much, that explains a lot. Strange that the Disable PHP in Uploads feature is listed as “fixed” in that other thread, when it sure as hell broke mine!

@liquidcross

The weird thing is that the line added to the .htaccess by the Disable PHP in Uploads setting does not break my env …

I did not rename my wp-content folder.
Even if I did, I don’t see how that could be a problem (assuming the bug as described in the other topic is indeed fixed).
Did you change your wp-content folder ?
Could you copy\paste the .htaccess line added by the Disable PHP in Uploads setting into the topic ?

Also I’m using Apache 2.4.x. What web server are you using ?

dwinden

My .htaccess entry looks like this and it is perfectly valid:

<IfModule mod_rewrite.c>
RewriteEngine On

# PHP Uitschakelen in Uploads – Beveiliging > Instellingen > Systeem Tweaks > Uploads
RewriteRule ^wp\-content/uploads/.*\.(?:php[1-6]?|pht|phtml?)$ – [NC,F]
</IfModule>

dwinden

It turns out the .htaccess RewriteRule for the Disable PHP in Uploads setting completely changed when updating from the 4.6.13 to the 4.8.0 release …

However there is no mention of this change in the 4.7.0\4.8.0 changelog…
(4.7.0 is an internal build and was never released to the public).

dwinden

It turns out the .htaccess RewriteRule for the Disable PHP in Uploads setting completely changed when updating from the 4.6.13 to the 4.8.0 release …

should be:

It turns out the .htaccess RewriteRule for the Disable PHP in Uploads setting completely changed when updating from the 4.6.13 (or older) to the 4.8.0 (or newer) release …

dwinden

I’m running Apache (not sure which version); and I did not rename my wp-content folder.

The Disable PHP in Uploads entry in my htaccess file looks like this:

# Disable PHP in Uploads – Security > Settings > System Tweaks > Uploads
RewriteRule ^wp-content/uploads/.*\.(?:php[1-6]?|pht|phtml?)$ – [NC,F]

And I confirmed once more that it results in a 500 error on my site. Removing it brings the site back to normal.

Only difference is the unescaped dash in wp-content.
I removed the \ in front of the dash from my .htaccess, but it still works. Could you manually add the \ in front of the dash and test to see whether it makes any difference in your env ?

Too bad you don’t know the Apache version … could also be relevant.

There must be an error in the Apache error_log that will tell us more …
Contact your hosting provider …

There really is nothing wrong with the RewriteRule (apart from not escaping the dash in wp-content).
But somehow your Apache env doesn’t like the RewriteRule …

dwinden

In the error_log, I’m seeing a lot of this (changed IP and usernames to fakes, of course):

[Thu Oct 8 07:38:04 2015] [alert] [client xxx.xxx.xxx.xxx] /hsphere/local/home/user/blog.URL.com/.htaccess: RewriteRule: cannot compile regular expression ‘^wp-content/uploads/.*\\.(?:php[1-6]?|pht|phtml?)$’\n

Would that have anything to do with it?

(Also seeing a lot “mod_security: Access denied” listings resulting from xmlrpc.php. Maybe I need to turn mod_security off with a line in htaccess? I had done that in the past, but I went with a “clean” htaccess file when trying to get to the bottom of the 500 errors.)

Yessss, that error msg in the Apache error_log is what we were looking for …

It actually confirms what I was already suspecting.

Your Apache regular expression compiler does not like something in the RewriteRule regular expression …

I had already come to the conclusion it might be the (?:) part which is known as Passive (non-c-apt-uring) group.
The (:?) is only used in the Disable PHP in Uploads setting and … yep the Ban Users HackRepair.com template !

A bit of Googling seems to confirm this:

You are probably using a different Apache version with a different regular expression engine. The Apache versions since 1.3 use POSIX ERE while the versions since 2.0 use PCRE. And only PCRE support the non-capturing group (?:expr)

So get your Apache version from the hosting provider and we are probably done chasing this rabbit ??
I would not be surprised if you are using Apache 1.3.x …

dwinden