-1

I copied a site over to GoDaddy from LiquidWeb because LW experts were unhelpful even if more knowledgeable. GD is hit or miss.

On the Godaddy hosting I get 500 errors constantly when in admin panel of WordPress and click on various items: plugins, posts, tools, doesn't seem to matter what it is I click on. But when I refresh each time, I am then able to see the page or post that had just given me a 500 error. I know nothing about hosting troubleshooting. Can anyone tell me if this is an error with the WP environment or hosting (or combo of both)?

Some more from the errorlog:

mod_fcgid: read data timeout in 120 seconds
Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

Any help much appreciated.

sebix
  • 4,175
  • 2
  • 25
  • 45
Torque2
  • 1

1 Answers1

1

When moving from one Hosting Environment to another, the best course of action will always be to make sure that you're transferring to is either identical to the one you're leaving. I know that's of very little help right this second, but it's something to keep in mind for the future. That said, let's move on to the problems!

5xx Errors

These can pop up as a result of a number of things, though when it comes to WordPress & Shared Hosting, they generally pop up as a result of 1). An issue with your .htaccess file or 2). Your WordPress installation is hitting the oh-so-dreaded "resource-wall" that is common with shared hosting.

A "resource-wall" would be that which the web hosting provider has set to limit the amount of resources an account may consume in a period of time. This includes CPU & CPU Cycles, RAM/Memory, Input/Output (IO) Operations, INODES (number of files and/or directories an account may create/host), Bandwidth in Mbs or Kbs (Megabits per Second / Kilobits per Second). When this wall is hit, your account is forced to slow down by the server software. This either results in slow service or, more often than not, 503 errors (i.e. Service Unavailable).

Redirection Errors

Redirection Errors can generally be narrowed down to two things, 1). The .htaccess file or 2). A Plugin/Theme isn't playing nicely with GoDaddy's hosting environment (and most likely isn't going to).

How Can I Fix & Prevent This From Happening?

You'll need to find your root directory. Most likely this is either ./public, ./htdocs or ./public_html (most common). This is the directory where your main index.php file will be and it's also where you'll find your .htaccess file.

  1. Download a Backup Copy of your .htaccess.
  2. Delete the .htaccess file inside of your root directory.
  3. Head to yoursite.ext/wp-admin/ and try to log-in.

If you're successful, look to the left sidebar menu and find Permalinks. All you need to do is click the link and then click submit (found towards the bottom of the page); no need to change any of the settings. Why? Just by clicking on submit, WordPress will automatically regenerate a cleaned up .htaccess file for you and place it in your web root. This ensures that you now have the most up to date & accurate .htaccess file for your installation.

If the errors persist beyond this point, look to the web root once more and see if an "error.log" file has been generated (or a file with a similar name). If so, follow up with the last 10-15 lines starting from the bottom of the file and moving towards the top. That'll often provide specifics as to what file, or what files are causing issues. We can then either disable the plugin(s) associated to see if that fixes the issue, or take another course of action.

WordPress Plugins & Disabling Them All

Typing, when there's an issue, it's best to simply disable all plugins and enable them one-by-one until you find the one that is causing issues (more so for when you can't find the exact cause from looking through the error log). This can be time-consuming, though it'll provide definite information.

To do this, you simply need to move everything in the ./wp-content/plugins/ folder elsewhere. You don't have to delete the files, simply move them using your S/FTP program, or using the File Manager that should be available through GoDaddy's control panel (which is cPanel IIRC). Once you've moved the files, refresh any page and that should deactivate them all. You won't lose any data as a result as this doesn't delete theme, nor the data associated with their installation, it simply marks them as disabled, meaning they won't run when you access your site.

As a result, depending on what you have installed, things may look a little odd and other errors may pop up (especially if you're using a theme that relies on functionality from one of the plugins), but seeing errors as a result of need instead of incompatibility or worse, something unknown, is a good thing. These can be resolved by simply moving the plugin folder for that plugin back to ./wp-content/plugins/. Ultimately, you'll refresh, move, refresh, move, rinse and repeat until things stop working.

When they stop, you stop moving folders. Identify the last plugin you moved and it should be safe to mark that one as an issue. Move the problem plugin back out, refresh to make sure that fixes the issue and then continue with the rest until you hit another problem.

Hopefully you either won't have to do that too much, or better, hopefully we'll be able to find the issue with the error log or the issue is resolved once a new .htaccess file is generated :).

Jonathan
  • 11
  • 2
  • Jonathan, thanks so much for the clearly explained, detailed answer. Before posting here I had copied the htaccess file and then tossed the current one out. Reset the permalinks. I had also disabled all the plugins (though I didn't move them out so that's a thought) and did the old death by a thousand paper cuts trying to determine which one(s) were acting up. Turns out the answer keeps changing. But question on the hosting environment: so from a propa host to shared host will cause trouble. If I had a more robust plan with GD, likely that I wouldn't have the time out errors? – Torque2 Jun 28 '15 at 20:17
  • @Torque2 GoDaddy is what I like to call a CPJ Provider (Cram, Pack, Jam), meaning they keep their prices low by simply cramming, packing and jamming the servers full of clients. Overly restrictive limits are placed on CPU, RAM, IO and Inodes (Files & Directories) which instantly renders any offer of "unlimited" void. It's all marketing (and IMO, it's false marketing). I see that their WP plans carry defined limits, though given their alternative shared plans fall in to the common unlimited/oversold scheme, my honest recommendation would be another honest provider. – Jonathan Jun 29 '15 at 05:28
  • I'm not sure what your budget is, though my recommendation would be to go with someone such as WPEngine.com, Kinstra.com, or GetFlywheel.com if you need managed service (such as help with scenarios such as this one - these providers would actually fix the issue for you). If you are, or become able to manage a server on your own, I'd recommend going with Linode.com, DigitalOcean.com or Vultr.com - deploy a VPS, install NGINX, MariaDB (MySQL Fork), PHP-FPM and if needed, Memcached so you're able to cache to RAM using W3 Total Cache or a similar plugin, instead of relying on disk cache. – Jonathan Jun 29 '15 at 05:34
  • The only reason why I moved it to GoDaddy was so I could break the site down to bits to see why it was acting up / buggy. I have throw away accounts at a few different hosting plans just to see what there is to see, but I've heard the complaints about GD in the past. Your explanation is actually much clearer. I recently ran across a nice tutorial on setting up with DigitalOcean, and have that on the back burner to play around with when I get some time. What do you recommend re: learning about W3 Total Cache? Works on some sites fine; others totally not. – Torque2 Jun 29 '15 at 12:03
  • @Torque2 Unfortunately, many hosts fall in to the same category (some of which used to be *really* good - HostGator is another one - mentioned only because I was actually helping someone using them 5m ago). As far as DO goes, they're excellent You can spin up a 512MB Droplet and install NGINX, PHP-FPM and MariaDB in about 5 minutes (simply using apt-get on Debian/Ubuntu or yum on CentOS). That's initial setup, not configuration (NGINX *will* require configuration, for sure). As far as W3TC, in most all cases, you set 3-4 options and leave the rest alone unless you have an explicit need. – Jonathan Jun 29 '15 at 12:17
  • The short of it, download & activate; activate "Enhanced Page Caching", "Object Caching" and test the waters with "DB Caching" (for some, it will actually slow things down, for others, it can speed things up - the server config plays a role in how well it works). Page Caching will be as slow as the disks used on the server, though pages less than 1MB are going to load pretty quickly regardless, so whether it's a SATA, SCSI, or SSD, you should be fine unless the host allows huge IO Wait. Beyond that, nothing else (last I recall), is all that useful until you start using Memcached or Redis. – Jonathan Jun 29 '15 at 12:20
  • So, so helpful. I really appreciate it. I followed a couple of video tutorials on setting up W3TC, but the instructions were slightly out of date, so I adlibbed. Trouble. – Torque2 Jun 30 '15 at 04:11
  • @Torque2 What issues did you run in to? I've ran in to pretty much every issue I can think of with W3TC, so I'm more than happy to help :-) (note: that doesn't mean it's a bad plugin - it's not by far, but it is complex and with complexity comes issues from time to time). – Jonathan Jul 02 '15 at 19:39
  • Good question. I am going to have to dig up notes because it's been a while. I have tiptoed around a couple sites that seem ok with w3tc. But I had to chuck out on some others because ... something. – Torque2 Jul 04 '15 at 21:20