Using the Participants Database Debugging Log

Participants Database has a built-in debugging log that can be helpful in understanding issues you may be having with the plugin.

The log is designed to keep a record of key operations that the plugin performs and log any errors that happen along the way.

Enabling the Log

In the Participants Database settings, under the Advanced Settings tab is a setting named “Enable Debugging” where you can set the level of logging to use. This controls the amount of information that will be added to the log.

“Plugin Debug” logs important operations from the plugin only. “All Errors” will also include general messages from WordPress and php such as warnings, notices and errors. “Verbose” adds a lot of detail, probably you should use this unless you have the knowledge to understand that all the information means.

During normal use, this should be left in the “off” setting so that unneeded debugging operations are not performed.

• “off” no debugging
• “plugin debug” debugging messages from the Participants Database plugin will be written to the log
• “all errors” general errors plus plugin debugging messages will be written to the log
• “verbose” in addition to capturing all errors, the plugin will add status messages to the log

Reading the Log

If debugging is enabled, a link to the “Debugging Log” will be visible in the plugin admin menu. Clicking that link will show you the log.

It is very helpful, and a good practice in general, to clear the log before doing any testing. This will help clarify which messages are related to the test. If you don’t do this, you will probably see dozens of irrelevant messages in the log.

To read the log, go to the Debugging Log page and click “refresh” to update the display with the latest messages.

To interpret what you’re seeing in the log, some degree of technical knowledge will be helpful, especially if you need to find something specifically related to the issue you’re looking at.

Things to look for in the Debugging Log

If you are looking at an issue that involves getting data from the database such as search or filter results or exporting records, you will be looking for a database query.

Database queries usually start with the word SELECT, but you’ll also see UPDATE or INSERT. Even for someone who doesn’t know the exact syntax of these queries can usually be easy to understand. These queries can tell you a lot about why you’re seeing the issue.

For example, if the query looks correct, and there are no errors, then it’s often an indication the issue is with displaying the data, not the data itself. Sometimes if the issue is search, filtering or exporting data and the query is correct, this can be an indication that the actual database contents are different than what you are expecting. Examine the database data directly using phpMyAdmin (or similar app) to better understand the results you’re getting.

If you do see messages marked specifically as errors (as opposed to not-very-serious warnings and notices) these are things that you may need to post to a support request.

Using the Debugging Log for Email Issues

When plugin debugging is on, every email that the plugin sends will be dumped into the log so you can see what went out. Having some technical knowledge about the data structures email uses can be helpful, but you can see who the email was addressed to, whether there was some problem with the content, even if there were errors in the send.

Often this ends up being confirmation that the email was sent, but never received…a common occurrence.

For operational monitoring of outgoing emails, it is a good idea to install an email logging plugin, which keeps an ongoing record of every outgoing email. Many of these plugins will allow you to resend an exact copy of the email, that can be very handy when debugging email issues with a customer.

An email log can be very helpful in providing support to your site users since you will often need to confirm communication details.

What to do when nothing shows in the log

Sometimes, you’ll have an issue, but nothing comes into the log telling you what happened.

There are several reasons for this:

1. The problem is not something that generates an error or log entry
2. The error is happening before the plugin is loaded
3. The php configuration is not correctly configured to log the errors

It is not uncommon for a problem that you are experiencing is not one that prints anything in the log. This can be problems that are not really errors or bugs, or something that is not set up to be logged.

This will often be issues that are due to misconfiguration of the plugin or misunderstanding of how the plugin works. In cases like this, it is a good idea to look carefully at the documentation to make sure you understand how things work. If you’re sure you’ve got it right, yet still seeing a problem, post a support request.

#2: The Debugging Log is a function of the plugin, so any errors that happen before the plugin is loaded won’t be logged. The reason for this is that every time a web page is opened in WordPress, the entire application goes through a sequence of actions before anything is printed to the screen. There are plenty of things that happen before the site’s plugins are loaded and activated, and if any of those things are generating errors, it won’t show up in the plugin’s debugging log. The solution to this is to set up an error log on the server that can pick up any errors that happen no matter when or where they occur.

The 3rd issue relates to how php is configured. There are local configurations in php that only affect code in certain directories (called “local configurations”). These configurations are often where the error log is configured, so if an error happens that is outside of the directories that the configuration is active in, the error won’t show up in that log. This is rather technical and probably will require help from your hosting provider to address.