Generic HTTP errors: Turning off Plugins & Themes

Occasionally you’ll go to a website and get a very general HTTP error 500 like the one shown above. Aside from “This page isn’t working” (well, duh) there really isn’t much to go off of. Naturally, the next chain of events would be to log into the WordPress dashboard and figure out what’s going on, but a lot of times that’s broken as well. So as a starting point, defining an HTTP error 500 can be helpful before understanding how it relates specifically to a single site.

HTTP error 500: The server encountered an unexpected condition which prevented it from fulfilling the request.

While that doesn’t sound like much for pointing us in the right direction, it’s more helpful than you think. It tells us what errors are not happening. For example, we know that there aren’t any temporary redirects on the site (error 307), we know that there wasn’t a network timeout (error 599), and we know that there’s definitely content at the URL, the server just doesn’t know what to do with it (error 404). P.s. if you’re ever in need of a full list of HTTP Error codes, this one is great.

So where can we get more information about what IS going on? The Error Log.

Log into cPanel & go to File Manager:

Navigate to the website directory. If this is the primary domain and the user hasn’t done any dramatic configuring, this will almost always be in the public_html folder. For addon domains, subdomains, and subdirectories, you’ll want to navigate to the specific website folder– it may look like public_html/subdomain. Click on the file called error_log and then (depending on how big the file is) click edit or view.

You’ll want to scroll to the bottom where the most recent errors are kept. Here are two different versions of examples that you might see:

Example 1:

^What we know: The error occurred on August 29th at about 4 PM. The error is coming from the chromatic theme, and there’s an unexpected ‘.’ on line 137 of the template-helpers.php file.

Example 2:

 [12-Sep-2017 19:35:37 UTC] PHP Fatal error:  require_once(): Failed opening required '/home/***/public_html/nursing401/wp-includes/class-wp-feed-cache.php' (include_path='.:/opt/cpanel/ea-php56/root/usr/share/pear') in /home/***/public_html/nursing401/wp-content/plugins/feedwordpress/feedwordpress.php on line 100

^What we know: There’s a PHP confliction with the FeedWordPress plugin, specifically on line 100 of feedwordpress.php.

In both instances, you could go down a rabbit hole following the vague directions from the error logs, but in my experience, removing the period in Example 1 wouldn’t fix the problem– it would add another line in the logs suggesting that there’s an extra quotation mark on line 53. These errors suggest that there’s a larger problem at hand: perhaps there’s a confliction between two plugins, or perhaps a theme doesn’t like the new WordPress update. From a support standpoint, it isn’t our job to fix the theme– that’s the responsibility of the theme developer. But it is our job to remove the errors and get the user back into their WordPress dashboard.

To do that, go back into the File Manager > Website Directory. Navigate to corrupted file or folder. So for example 1, I’d go to public_html > wp-content > themes. You’ll want to turn the chromatic theme off, which can be done by renaming the folder to “chromatic_off” or something of that nature.

This method works great for temporarily disabling a feature that may be causing problems without deleting it. Temporarily turning off themes & plugins can be a great troubleshooting method as well if you’ve exhausted all other resources. But in the above case, turning off the chromatic theme by renaming it worked. I then confirmed that the HTTP error 500 was removed from the domain, and I could access the WordPress dashboard once more. At that point, it’s just about sending a response to the user suggesting that they reach out to the developer as to why there was a confliction, and/or recommend that they use another theme/plugin.