Debugging Tips for WordPress: Common Errors and How to Fix Them

The most disreputable issue to travel wrong with WordPress is that the White Screen Of Death. This is when you load your website and there’s nothing but a white screen. No code, no errors; nothing. It’s a disheartening thing to see. In this post, we’ll say a way to create WordPress speak to you in addition as a way to resolve most problems.

Making WordPress Communicate

It’s very common for themes and plugins to have code that is slightly outdated but still perfectly functional. When this happens, PHP issues a warning. By default, PHP warnings are sent to the browser, and appearance considerably like your website is de facto broken, when it’s not. For this reason, WordPress turns off that kind of reporting. On your production server, this is how things should be done. On a staging or development server, you want reporting turned on, so that you can see potential problems.

In production, one of the side effects of turning off all reporting is that when something really goes wrong, it doesn’t get reported in the browser, it simply renders a plain white screen. In WordPress, this is known as The White Screen Of Death. When this happens, ideally you’ll copy your production site to a development server and work there. In a pinch, you can turn on reporting in production and see the errors right there.

Let’s take a glance at a way to activate PHP Error reportage in WordPress.

Turning on PHP Error Reporting in WordPress

You’ll need to edit your wp-config.php file. You can either pull it down with FTP, edit, and push back, or use a cPanel editor, or even SSH to your server and edit in real time. Any of these methods will work.

Once you’ve got wp-config.php open, seek for this line:

define( ‘WP_DEBUG’, false );

That turns off all error reporting. Replace that one line with these lines:

// Enable PHP reporting
define( ‘WP_DEBUG’, true );

// Send error messages to the PHP log file
define( ‘WP_DEBUG_LOG’, true );

// Send error messages to the browser
define( ‘WP_DEBUG_DISPLAY’, true );

// Turn on the PHP config directive to send errors to the browser
@ini_set( ‘display_errors’, 1 );

Then load your browser and you should see something like this:

NOTE: Savvy readers will notice that this is from Siteground’s Optimizer. There’s nothing wrong with their plugin, I stony-broke it by design for this demonstration.

Reading PHP Messages

PHP reporting messages always have 4 parts:

1. The type of error. Below we have a syntax error, which would be like a grammar or spelling error in English.
2. The actual error. Below we have some unexpected text, “Siteground_Optimizer’
3. The file in which the problem exists
4. The line number inside that file where you can find the problem.

The four most common types of messages are

1. Fatal Error
2. Parse Error
3. Notice
4. Warning

Notices and Warnings will not stop your site from working and could be hidden by turning off WP_DEBUG. You should try to fix them if you can though, someday they may come back to haunt you.

Fatal Errors and Parse Errors mean something is really broken, and they prevent your site from functioning.

How To Recover

Deactivate

Your first step should always be to try to log into the backend of WordPress. Often the errors are in code that only runs on the front of the site, and you can log into the backend. If this is the case then you can simply deactivate the plugin or theme that’s causing the problem. This doesn’t truly fix the problem, but your site will come back, and that’s a big step.

In the WordPress admin, go to the Plugins folder, find the plugin that’s causing a problem and click the Deactivate link. Here’s an example:

Ask For Help

Many managed WordPress hosts will work to simply take care of this issue for you. Check with your host to see what your available support options are. They may not be able to actually fix the problem, but they’ll get your site front-end live again and help you understand the real problem so that you can move forward.

Remove with FTP

If you can’t log into the WordPress admin, you can log into your server with FTP. Follow the trail given within the error message and take away the plugin or theme inflicting the matter. I recommend downloading a copy first. The screenshot below uses the CyberDuck FTP client, and it’s pointing at the Jetpack plugin. From there, you could download that folder and then delete it.

Fixing the Real Problem

Once you’ve determined the error that broke your site and removed the problem code, you’ll probably want to find out why it broke, fix it, and put it back. You probably had that code for a reason.

If you did NOT have a good reason for having that code, then you should simply discard it move on.

Common reasons why code fails.

There was an update for the plugin or theme that introduced a bug.

Check to see what the latest version of the code is, and compare it to what you have. If it came out just yesterday then there very well could be a bug. You should contact the developer and explain the issue.

There was a network interruption during a regular update.

The internet being what it is sometimes updated simply break in the middle. Try downloading the plugin or theme and uploading it with FTP. If it fixes the problem then an interruption was almost certainly the problem.

Another plugin updated and introduced incompatible code.

This might also be indicated in the error message, but sometimes not. The plugin reporting the error might be perfectly fine, but some other plugin has introduced new code that collides with your good plugin. Perhaps you end up with two different functions named the same thing for example. In that case, you’ll want to look at the update times for all of your plugins, and check the newest ones.

In the case of a code collision, it’s not really a bug in either plugin, but most times plugin developers want to be compatible with each other, so you should make both authors aware of the issue. Then it’s a race to see who fixes it first.

You can’t tell

Sometimes you simply can’t figure it out, especially if you’re not a developer. It’s perfectly fine to contact support or the developer through whatever means they offer and explain the problem. Often they’ll be able to see the issue right away.

Staying on top of things

You can’t always know ahead of time when changes will be made, but if you have a detailed record of all changes then it goes a long way toward fixing things quickly. I recommend a plugin called WP Stream. It’s a free plugin that tracks every action in WordPress. Every login, every content update, every code update, everything. And it tells who did it, and when.

Summary

One of the most important things is getting good communication from WordPress. If you can read the log file, or make WordPress tell you the error, fixing the actual problem is almost always easy.

I recommend getting a local development environment like Local by Flywheel or DesktopServer and practice breaking things and making the server tell you what’s wrong. Once you get comfortable with broken sites, fixing them becomes a lot less scary.

9 Reasons Your WordPress Site Has Slow Response Time