One of the hardest parts of troubleshooting WordPress errors is figuring out exactly what’s causing them. Some errors, such as the ‘White Screen of Death’ or 502 bad gateway, don’t provide you with much information to go on. This translates to wasted time narrowing down potential causes.
Fortunately, WordPress includes a feature that can make your life easier, although it’s not enabled by default. We’re talking about debugging and WordPress error logs. With these tools, troubleshooting the platform becomes a whole lot simpler.
In this article, we’ll talk more about error logs, how they work, and what they can do for you. Then we’ll teach you how to enable debugging and access your WordPress error log both manually and through plugins. Let’s get our hands dirty!
An Introduction to the WordPress Error Log and Debug Mode
WordPress error logs enable you to keep track of any bugs that pop up on your site. For example, if a theme fails to load an asset it needs to render a page, an entry should appear in your log. Then, you can take a quick look at it, and use the information to figure out which file is causing you problems.
By default, WordPress doesn’t keep error logs. However, the platform does include a built-in debugging feature you can enable if you want to begin. Here’s why you should consider enabling the feature on your website:
- It can help you troubleshoot WordPress issues. Having access to logs can help you narrow down the source of a lot of errors in a matter of minutes. Otherwise, you might be stuck trying multiple solutions until you strike gold.
- You can pinpoint the source of errors. The best thing about WordPress error logs is they tell you exactly which files are causing problems. Even better, they include the lines of code you need to take a look at.
To be fair, WordPress error logs can be hard to interpret, mainly if you don’t have a background in PHP. Each line in your log will explain what type of error it is, but it uses PHP terminology. However, they can provide you with more information on the files you need to take a look at, which is often everything you need to find the right troubleshooting guides, or even Google a fix.
Finally, learning how to use the WordPress debug mode is essential if you ever want to dip your toes into developing themes or plugins. In this scenario, error logs will tell you if you’re doing something wrong and help you polish your projects.
How to Enable the WordPress Debug Mode
As we mentioned earlier, WordPress’ debug mode is turned off by default. This means the platform will not create or store error logs until you enable it. Even then, your error log remains somewhat hidden. This means you need to know where to look for it (or which tool to use) to help you visualize its results.
Before we go any further though, it’s important to note that as a 000webhost user, you don’t have access to the WordPress debug mode. To improve performance for our clients, we customize your wp-config.php files ourselves. Adding the code necessary to enable the WordPress debug mode and create error logs results in an error that won’t enable you to access your website.
To be clear, you can still enable error logs if you’re a Hostinger user. Likewise, if you run into an error using 000Webhost, we’ll be more than happy to help you troubleshoot it – we provide an extensive list of guides to fix the most common WordPress errors.
To turn on WordPress’ debug mode, you need to tweak your wp-config.php file. This is one of your WordPress core files, which makes it possible for the platform to work. For example, allows your website to connect to its database, which is obviously critical.
To access your wp-config.php file, you’ll need two things – an FTP client and a set of credentials to connect to your website. Most web hosts (including 000Webhost) will provide you with the latter when you sign up with them. To find yours, log into your 000Webhost account and go into the Settings > General page. Inside, look for the FTP Details section at the top of the screen:
The credentials you need are Host Name, Username, and Password, and the last one is the same one you use to log into your control panel. Take note of all three for now. Next up, you’ll need to download an FTP client. We recommend FileZilla since it’s both easy to use and features a healthy selection of features.
Download, install and run the program as you would any other. When you launch it, you’ll notice three empty fields at the top of the window, called Host, Username, and Password. Fill them out using the credentials you took note of earlier and click on the Quickconnect button:
Now FileZilla will establish an FTP connection to your website. This will enable you to transfer files back and forth securely, as well as access and edit them. Once the connection is established, two new folders should appear (it may be more or less depending on your host) on the bottom-right corner of your FileZilla window. The one we care about is called public_html and is also known as your WordPress root folder:
Your entire WordPress setup resides within this folder, so make sure not to delete, tweak, or move any files if you’re not sure what they do. For now, open the public_html folder by double-clicking on it, and look for the wp-config.php file right within:
Now right-click the file and choose the View/Edit option. This will prompt FileZilla to ask you which text editor you want to use to open it. Once you’ve made a choice, the file will open and you’ll be able to edit it locally. The wp-config.php file can be intimidating if you don’t have too much experience with coding, but it’s fairly easy to modify. Just scroll down and look for the /* That’s all, stop editing! Happy blogging. */ line. Any code you add to the file needs to go before that line (with very few exceptions) for it to work. In this case, here’s the snippet you need to copy and paste within your wp-config.php file:
define( 'WP_DEBUG', true ); define('WP_DEBUG_LOG', true);
Now save the changes to your wp-config.php file and close it. FileZilla will ask you if you want to overwrite the previous version of the file on your server with the new one you just created. Say yes and you’re off to the races. Now let’s talk about how to find your WordPress error log, and interpret its results.
How to Use a WordPress Error Log for Troubleshooting Purposes
If you followed the instructions on the last section, a new debug.log file should’ve appeared within your /wp-content/ directory. To get there, return to the public_html folder and look for wp-content right within. Open the folder and debug.log should be one of the only files inside. As always, open it though FileZilla using your local text editor. Here’s an example of what you might find within:
[02-Jan-2018 01:57:53 UTC] PHP Notice: Undefined index: SERVER_SOFTWARE in phar:///usr/local/bin/wp/php/WP_CLI/Runner.php(1020) : eval()'d code on line 75 [02-Jan-2018 01:57:54 UTC] PHP Notice: Undefined index: SERVER_SOFTWARE in phar:///usr/local/bin/wp/php/WP_CLI/Runner.php(1020) : eval()'d code on line 75 [24-Nov-2017 15:04:05 UTC] PHP Warning: Cannot modify header information - headers already sent by (output started at /www/wp-includes/formatting.php:5087) in /www/wp-includes/pluggable.php on line 916 [24-Nov-2017 15:04:05 UTC] PHP Warning: Cannot modify header information - headers already sent by (output started at /www/wp-includes/formatting.php:5087) in /www/wp-includes/pluggable.php on line 1210 [25-Nov-2017 02:19:28 UTC] PHP Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method DHDO::cron_schedules() should not be called statically in /www/wp-includes/class-wp-hook.php on line 298
Don’t panic if the above doesn’t make any sense. Those are examples of five small error events logged in the file. The only parts we care about for now are the timestamps and the files each event points towards. As for the remaining code, it tells you what type of error you’re dealing with, but introducing all the potential causes would require you to be acquainted with PHP. More importantly, you can ignore most error events within your debug.log file unless they’re identified as fatal errors. One example of a fatal error is when WordPress runs out of memory, preventing it from executing scripts or rendering pages.
Moving on, it’s possible to use this information to troubleshoot your website even if you’re not a PHP wizard. When you run into a critical or fatal error, simply take a peek at your debug.log file and look at the latest entries for clues on what might’ve caused it. For example, in this case, you know the problem lies within the Twenty Fifteen theme’s content.php file:
[16-Nov-2017 00:12:37 UTC] PHP Fatal error: Call to undefined function the_id() in /www/wp-content/themes/twentyfifteen/content.php on line 13
If you have some experience developing or troubleshooting themes, you can try to dig into that file – line 13, to be specific – and figure out what’s wrong. Otherwise, you can either try to Google the specific error, which in this case would be ‘call to undefined function’ or look through our troubleshooting guides to find any relevant articles. In any case, having to Google how to fix an error is all too common, even for users with plenty of WordPress experience, so don’t feel bad if you have to resort to it.
If you don’t feel comfortable digging into your backend to access your WordPress error log, there are alternative approaches. For example, you can use a plugin such as Error Log Monitor, which enables you to check out the latest lines in your debug.log file from your dashboard:
To use the plugin, go to the Plugins > Add New tab and type its name on the search bar to the right of the screen. Wait until the plugin shows up on the list below, click on the Install Now button next to its name, then activate it:
Next, you can click on your Dashboard > Home tab and look for the new PHP Error Log widget at the bottom of the screen:
The widget will automatically display the latest 20 lines of your debug.log file and it can be a lifesaver if you don’t have an FTP client set up. Likewise, it also shows the timestamps for each error and enables you to clear the entire file with a single click if you want to.
Another option if you like WordPress error logs is the WP Security Audit Log plugin. This tool takes a different approach to the one we discussed a moment ago, though. Instead of enabling you to access your WordPress debug.log file, it keeps independent logs of all important security events, such as when someone deletes or updates themes and plugins:
To be specific, plugins such as WP Security Audit Log fulfill a different function than the WordPress debug mode. They don’t keep track of individual errors but enable you to track different types of events. Ideally, you should enable both WordPress’ debug mode and use a plugin such as this one, so you’re aware of everything that goes on in the background of your website, particularly if you have other people helping you run it.
Debugging sounds complicated. However, WordPress makes the process simple. By enabling the platform’s debugging and logging features, you’ll have access to in-depth reports for every error that occurs on your website (which shouldn’t be many). What’s more, interpreting a WordPress error log is simpler than you might imagine.
Before we wrap things up, let’s recap the two ways you can access a WordPress error log:
- Locate the debug.log file within your /wp-content/ folder.
- Use a plugin such as the Error Log Monitor.
Do you have any questions about how to access or read WordPress error logs? Let’s talk about them in the comments section below!