Posted on by

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.

The debugging log settings
  • “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

clear the log before doing any testing

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.

Typical query for displaying the
First NameLast NameClub RoleCityStateMain ActivityPhoto
Neil Myers Member Santa Rosa California
Debolt Edwin Member Tempe Arizona
danny lopez
Dale Byrne Volunteer Carlsbad California General Sports, Photography, Crafts, Arts & Hobbies, Knitting, Yoga, Rock Hounding, Organic Farming
Gabi Clayton
test test
Group FIBARO
mike s
Brett Bickham
JAIME PERALTA
shortcode

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.

Log record of an outgoing email. Note that this one failed because the email address was invalid.

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.

2 thoughts on “Using the Participants Database Debugging Log

  1. There’s nothing too worrying there unless you are experiencing some problem with the plugin.

    “Cannot modify header information – headers already sent” this is due to another plugin or theme sending output early, this can happen if there is a problem with a script that ouputs when it is not supposed to, or an error statement getting printed to the screen, etc. If you see something strange on the screen, note the exact circumstances that bring it up and try inspecting the HTML to see if you can see exactly what it is.

    “Date parsing failed” this means a string was entered for a date field that could not be interpreted as a date. Without knowing the input it was trying to parse, I can’t be more specific. Date fields in Participants Database are converted to timestamps, so the input must be parsable as a date.

    If you have the “Use Alternate Session Method” setting checked, you may want to try unchecking that. The system attempts to find the best way to keep track of sessions, so this may not stay unchecked if regular php sessions are not working.

    The overall suggestion is to turn plugin debugging off unless you’re actually trying to diagnose a problem. If you are running into an operational problem with the plugin, we should start with that.

  2. Hi, the site’s error log is being filled with dozens of these error records.
    There are two types, the date parsing seems to be the most common followed by the ‘headers already sent’ error.
    The operation is opening, modifying and saving a record
    All software is bang up to date. php 7.4
    Please let me know if you need further information.
    Thanks

    Cannot modify header information – headers already sent
    in /home/sites/1a/6/66ac65027f/public_html/wp/wp-content/plugins/participants-database/classes/PDb_Session.php on line 377
    [09/04/22 12:50am UTC]
    PDb_submission\main_query\base_query::execute_query storing record: UPDATE wp_participants_database SET

    date_updated

    = “2022-09-04 00:50:06”, WHERE id = 2402
    [09/04/22 12:50am UTC]
    PDb_Participant_Cache::refresh_cache: Refreshing Participants Database cache for cache group 24
    [09/04/22 1:50am BST]
    IntlDateFormatter::parse(): Date parsing failed
    in /home/sites/1a/6/66ac65027f/public_html/wp/wp-content/plugins/participants-database/classes/PDb_Date_Parse.php on line 236
    [09/04/22 12:50am UTC]
    Cannot modify header information – headers already sent
    in /home/sites/1a/6/66ac65027f/public_html/wp/wp-content/plugins/participants-database/classes/PDb_Session.php on line 377

Leave a Reply

Your email address will not be published. Required fields are marked *

Would you like to be notified of followup comments via e-mail? You can also subscribe without commenting.

2 thoughts on “Using the Participants Database Debugging Log

  1. There’s nothing too worrying there unless you are experiencing some problem with the plugin.

    “Cannot modify header information – headers already sent” this is due to another plugin or theme sending output early, this can happen if there is a problem with a script that ouputs when it is not supposed to, or an error statement getting printed to the screen, etc. If you see something strange on the screen, note the exact circumstances that bring it up and try inspecting the HTML to see if you can see exactly what it is.

    “Date parsing failed” this means a string was entered for a date field that could not be interpreted as a date. Without knowing the input it was trying to parse, I can’t be more specific. Date fields in Participants Database are converted to timestamps, so the input must be parsable as a date.

    If you have the “Use Alternate Session Method” setting checked, you may want to try unchecking that. The system attempts to find the best way to keep track of sessions, so this may not stay unchecked if regular php sessions are not working.

    The overall suggestion is to turn plugin debugging off unless you’re actually trying to diagnose a problem. If you are running into an operational problem with the plugin, we should start with that.

  2. Hi, the site’s error log is being filled with dozens of these error records.
    There are two types, the date parsing seems to be the most common followed by the ‘headers already sent’ error.
    The operation is opening, modifying and saving a record
    All software is bang up to date. php 7.4
    Please let me know if you need further information.
    Thanks

    Cannot modify header information – headers already sent
    in /home/sites/1a/6/66ac65027f/public_html/wp/wp-content/plugins/participants-database/classes/PDb_Session.php on line 377
    [09/04/22 12:50am UTC]
    PDb_submission\main_query\base_query::execute_query storing record: UPDATE wp_participants_database SET

    date_updated

    = “2022-09-04 00:50:06”, WHERE id = 2402
    [09/04/22 12:50am UTC]
    PDb_Participant_Cache::refresh_cache: Refreshing Participants Database cache for cache group 24
    [09/04/22 1:50am BST]
    IntlDateFormatter::parse(): Date parsing failed
    in /home/sites/1a/6/66ac65027f/public_html/wp/wp-content/plugins/participants-database/classes/PDb_Date_Parse.php on line 236
    [09/04/22 12:50am UTC]
    Cannot modify header information – headers already sent
    in /home/sites/1a/6/66ac65027f/public_html/wp/wp-content/plugins/participants-database/classes/PDb_Session.php on line 377

Leave a Reply

Your email address will not be published. Required fields are marked *

Would you like to be notified of followup comments via e-mail? You can also subscribe without commenting.