This is the second article in a 3 part series on the use of activity logs in WordPress.
Read the first article here.
In the first article of this series we have seen how, by keeping a record of the changes that happen on your site in a WordPress audit trail (activity log), you can improve user accountability and also tick another checkbox for compliance requirements.
In this second article we will see what logs WordPress site administrators and developers have to help them troubleshoot and solve technical issues.
Logs for WordPress Site Administrators & Developers
WordPress is a PHP web application. To host a WordPress site you need a web server service that can execute PHP code. You also need a MySQL database server where to store the WordPress database. Both the web server service and the database server run on an operating system.
All of the above mentioned components that work together to host a WordPress site have their own logs. So apart from the WordPress activity log where you can find a record of the changes logged in users have made on your website, you also have the following logs at your availability:
- WordPress debug logs
- Web server access and error logs (including PHP errors)
- SFTP logs
Logs are useful only if you know what you are looking for. In this article we will use examples to explain how you can use any of the above logs to troubleshoot issues.
WordPress Audit Trails
To keep a log of what logged in users are doing on your WordPress website you need a WordPress audit trail (activity log) plugin. I use and recommend WP Security Audit Log because it is developed by yours truly.
In the WordPress activity logs you will find a record of all the changes that logged in users made on your website. Therefore, using these logs for troubleshooting is relatively straight forward.
A page has changed or was deleted? A new plugin was installed on your website or updated and you did not authorize it? Or even worse, a WordPress user account was hacked and you need to find out what damage was done? You can find all this information and more in the WordPress activity logs.
WordPress Debug Logs
In the WordPress debug log you can find debugging information. Debugging is the process of identifying and fixing issues in software. It is a process typically used by developers when developing an application or troubleshooting a bug.
When developing a plugin, a theme, or a WordPress customization, developers enable the WordPress debug logs so that, if something is not working right, they can refer to the errors in the debug log to find out what is wrong.
As a WordPress site admin, you most probably won’t need to refer to these logs. However, if a plugin is acting up, plugin developers might ask you to enable the WordPress debug log file to find the cause of the issue.
Web Server Access & Error Log Files
In the web server access log file you will find a record of every HTTP request your web server received. Below is a screenshot of an abstract from a default Apache access log file.
For every entry in the access log file the web server keeps a log of:
- IP address from where the request originated
- Remote logname
- Authenticated user (in case of HTTP authentication)
- Date and time of the request
- HTTP response status of the request (200, 404 etc)
- Bytes sent for the request
- User agent
The web server can be configured to store more information in the access log file, such as the actual request and other payloads.
In the web server error log file you will find information about the errors the web server service encountered when starting up and running. You can also find the errors the web applications generated while running, or PHP errors.
Using the Web Server Log Files for Troubleshooting
If you get the WordPress white screen of death, you will most probably find the information you need in the WordPress debug log (if it is enabled) and in the web server error log file.
The web server access log file contains information about connections and requests. You can use these logs if some users are having connectivity issues, or perhaps even HTTP authentication issues. Access log files are also handy if you use some sort of custom web services or software that connects directly to the web server and you are having connectivity issues.
When users connect to a web server via SFTP, depending on the privileges, they can have direct access to the site’s files. In the SFTP logs you can see who connected to your website and created, updated or deleted files.
FTP server logs are very easy to read and you’ll only need them if you have a suspicion that someone changed, added or deleted a file on the website.
Even More Logs For Troubleshooting Technical Issues
The above mentioned logs are the most common logs used for troubleshooting technical issues in WordPress. However, on a web server there are many other logs you can use to do more low level troubleshooting.
For example, the database server MySQL also has its own logs. You can configure the database server to keep a log of every database request it gets, which is certainly handy for developers. The operating system on which the web server service is running also has its own logs, as well as the SMTP server (mail server).
Store The Logs For As Long As You Can
This posts highlights how important logs are in troubleshooting technical WordPress issues. Always keep as many logs as you can. If you encounter a technical issue and have no logs, finding the source of the problem is like looking for a needle in a haystack.
Disclosure: Some of the links used above are affiliate links, meaning that, at no extra cost to you, we may earn a commission if you click through and make a purchase.