WordPress log files are one of the most important aspects of the entire WP ecosystem that you may have never heard of. Or at least, may have never thought of. Log files are essentially records of everything that your website and server has done over its life (or a specific time frame). Unfortunately, many people see log files as being hard to understand and use. We want to break through that misconception and show you how to use WordPress log files and what that knowledge can do to improve your website.
What Can You Do with WordPress Log Files?
The use of WordPress log files differs depending on your role. A user will find different things useful than an admin would than a developer would and so on. But there are a number of things that these very same log files do, and many of the purposes can overlap.
- finding errors
- aid troubleshooting
- auditing security
- assessing accessibility standards
- monitoring user experience and customer journey
- track user activity
- check plugin performance
- explore themes
And a lot more. Plus, there are a lot of different kind of log files. Some are specific to WordPress itself, while others may be generated by individual plugins. Let’s look at some of them in particular to see what you can expect.
WordPress Debug Log Files
Strangely enough, the default WordPress log file itself is disabled for new WP installations. You have to go into the wp-config.php file and manually enable it. The debug logs are disabled by default because logging everything that your WP installation does takes some of your server resources. Instead of running the site, it’s logging how it runs the site.
We recommend that you enable logging only for a short period as issues arise to fix them. Unless you’re working in a development environment, of course.
Now, you can enable logs in multiple ways. Via FTP using a program like FileZilla and editing the file in a code editor. By cPanel, or even via a plugin such as WP File Manager. Regardless, the process is simple. You are going to find the wp-config.php file in your installation’s root directory and add two lines of code to it.
- define( ‘WP_DEBUG’, true );
- define( ‘WP_DEBUG_LOG’, true );
Step 1: Finding wp-config.php
Wherever your root directory is, connect there. Most likely it will be under /public_html/example.com/ (the .com part may or may not be there).
Step 2: Editing wp-config.php
Once there, open it up in your editor of choice. Sublime Text, VS Code, and Atom are all popular choices. Scroll until you find the line that reads /* That’s all, stop editing! Happy blogging. */ Once there,paste the two lines of code above directly above it. You might even have one marked false already in the file.
The top line enables debugging to occur, while the second generates the log file itself. In this format, the snippet saves the WordPress log file to wp-content/debug.log, but you can replace true with a relative path in single quotes to specify a different place. For example, define( ‘WP_DEBUG_LOG’, ‘/tmp/wp-errors.log’ ); as specified in the WordPress Codex entry on debug logs.
Step 3: Finding, Reading, and Understanding the Log File
Be aware, your log file might not appear immediately. It is not a real-time log of the server’s activities, but a log of the errors that occur within it. Hence why we recommended earlier that you only enable it when something is going wrong. So if the debug.log file doesn’t exist yet, give it time. Something will break, eventually.
When you finally get the debug.log file, you can open it either in the file manager or in the code editor of your choice. But you will see something similar to this.
For a typical WordPress user, this looks like gobbledygook. For a developer, though, they would see the PHP issues in a couple of plugins being unable to perform certain tasks.
Step 4: Get Help
As we said above, most WP users would have no idea what to do with these errors. However, when your site isn’t performing optimally, you need these thing fixed. That’s when you have to find someone to help you.
You have a few choices in this particular path, the most obvious of which is to download the entire debug.log file and send it via Slack or email to your systems administrator. Most of the time, this is the best choice. Even if you’re a dev and have this log, you’ll probably be sending it up the chain (or maybe down it, if you’re a senior dev and delegating tasks).
But if you’re not part of a team, you will also likely need to take the file and send it somewhere. But where? Stack Overflow. Or maybe even more specifically, WordPress Stack Exchange (the subforum from SO based around WP). If you can’t get an answer on Stack Overflow or Stack Exchange about your tech problem, you should go buy a lottery ticket. Because those are some crazy odds.
Additionally, you could send the debug logs to the developers of the plugin directly, or even post on the official WordPress help forums over at WordPress.org. While the issues may be with individual plugins, the logs are from WP and folks have likely run into these particular issues before.
On top of that, there are plugin support pages on each plugin’s repo page.
These take you to the direct support forum on WP.org for that specific plugin.
Using these forums can get some individualized help for your problems.
As you can see, WordPress error logs are incredibly dense. They can be intimidating, and even getting them set up (outside of using a plugin) can be scary for some folks. But if you keep the debugging limited to either a development environment or shut it off after grabbing the logs on a public server, they are a fantastic troubleshooting tool to see what’s going wrong under the hood of your site. So the next time your users have an issue, or even your staff has an issue with the backend of the site not performing as expected, WordPress log files can be a fantastic line of defense.
What kind of situations have monitoring WordPress log files have you been able to fix or prevent?
Article featured image by fatmawati achmad zaenuri / shutterstock.com