There are tons of tutorials talking about how to troubleshoot a WordPress website, from installation to plug-ins and login errors. Why should you check our hangout? Maybe because it is a little bit different from what you can find online, focusing on very specific situations.
Good morning, Richard.
Thank you for joining me today. What I would like to ask you about is troubleshooting. I’ll give you an example: I’m your biggest WordPress customer facing a hosting issue. How can you help me?
There are a couple of things. Firstly, I need to get a proper error report from you. Although it can be challenging, trying to get hold of the person who reported the issue is the first thing I need to do, unless it’s very obvious what the problem is. Once I establish what the problem is, I need to establish whether it’s just for that person. For instance, somebody phones up and says that a website is down; nine times out of ten, that’s not accurate. It may very well be a problem with that machine, or it may be a networking issue. If it’s an issue between a particular site and a particular server, it might only be affecting that site.
Secondly, if the problem affects everybody, I need to confirm that. Let’s assume that a specific issue is affecting more users. In this situation, I’ll probably turn to the error log file. On a client account, I have direct access to machines, which means that I can easily find out what’s going on; in other environments, the error log remains the primary source of information for debugging. In this case, I need to know where the error log file is and how to get to it.
How do you fix the issue?
It depends on the level of impact the bug is having on a site. If it’s a very minor CSS tweak that’s not affecting the main flow of the site, I will set up its development area, fix it, show it to the customer, and then roll it out. Only if it’s a major bug, I’ll consider hot fixes. If I decide to do this, I’ll also get the customer involved. Additionally, the last thing a web developer wants to do with an e-commerce website is to go heavy-handed, potentially changing something that’s not going to fix the problem. Sometimes, it is better to find workarounds.
What tools do you use?
When working on the command line, I tend to use command line tools. The majority of problems can actually be worked out quite fast.
So, you’re using command line tools in UNIX and Linux to check IP traces. As well, you’re looking at websites’ general health, routes, and other things relating to the network condition. Is that correct?
That’s correct. Another tool I would mention is MTR. It’s absolutely fantastic! It’s basically a “ping” tool; most people know that these tools “ping” websites from one point to another. Similarly, MTR will “ping” every router between point A and point B. So, I can actually start to work out using MTR where site’s packets are being dropped. That’s really useful when I’m debugging things on the network.
Just so that we can wrap this up, are there any tips and takeaways that you could offer?
A very common WordPress issue is the WordPress “white screen of death”. When this happens, you need to be looking at what’s going on in your machine and what’s changed (Has someone changed something on the server? Has an automatic update or an update applied by your hosting company caused the particular issue? Is WordPress automatically updating?). There also are plug-ins such as the WordPress diagnostic tool, which will show you which files have changed. If you got the WordPress “white screen of death”, another thing you should do is to disable your plug-ins to see if you can get your website back up. It really is important knowing what’s happened to your machine, either by running a tripwire or a diagnostic plug-in, or talking to your hosting company.
Now, I would like to mention backups. Is it true that people should always backup their files?
Yes, people should backup their files every time. If something happens with a website, you can use your backups to compare files. It’ll give you a snapshot of what’s changed and when it’s changed. This is really useful when debugging.
Thank you, Richard. See you next time.
Thanks very much.