Adds a dynamic list of entries to each record. Log work hours, attendance records, list your collection, places you’ve been…adds a whole new dimension to your Participants Database record.
This add-on provides a new kind of field that you can define in Participants Database that works as an ongoing log or list of things that are attached to the record. This log is really a separate database that is linked to the record, and provides you with a powerful way to add another dimension of content to your Participants Database records.
Use this plugin to maintain a list of:
attendance records
work timesheet
volunteer participation record
personal collections catalog
photo gallery
events participation record
personal log or diary
transaction records
family members
Main Features of the Plugin
Searchable, sortable, and paginated list display
Fully configurable set of data fields for list entries
Users can add/edit/delete entries
Responsive entry list display templates
Configurable “sum” display
CSV imports/exports
Supports Multiple logs or lists
Global log entry list display shows a filtered list from any log
The log entries can have any number of fields, and uses the same field management interface that is used for the main database, giving you complete control over what is stored in each entry. Log entries can also be added, removed, or edited by the user (if enabled).
On the display side of things, the single record display and editable record display shows a list of log entries that is sortable, searchable, and paginated so you can easily navigate though lots of entries.
Each log can also be configured to show a “sum” value that could be the number of entries or a sum of values within the entries, such as a timesheet that shows the number of hours worked. This configured sum value display is what is shown for the log field in displays where a list of records is shown using the [pdb_list] shortcode or in the admin participant list. The sum value can be configured to display just how you want it.
The log also supports CSV import and export so that it can be updated from a spreadsheet (for instance) or users can download the data for their own spreadsheets.
Finally, it is possible to have multiple logs per record, each with it’s own independent configuration.
It literally adds a whole new dimension to your database.
A “log” is essentially just a list, an ongoing set of entries that is used to keep a record of things. Ongoing means that the list is open-ended, so new entries can be added at any time. So, even though the word log is not commonly used for lists of things, it seemed appropriate for something that could be used for so many different purposes. I also call it a log because that differentiates it from the database of records that Participants Database uses.
Log entries are very much like Participants Database records, but they are different in that they are attached to a specific record. A log can’t exist separate from a record, it extends the data storage capabilities of the record. A log entry can’t be attached to more than one record (or to no record) and so a log can’t be used to set up a separate database of things. It is not a relational database, but it does add another dimension to the normally “flat” Participants Database.
In the Participants Database admin menu will be an item named “Participant Log.” On that page you will find the global settings for all logs under the “General Settings” tab. This is where you set things like the template (which controls the layout) and other general settings for all the logs. These settings can be individually overridden in the log field definition if needed.
Setting up the Log
The first thing to do to set up a log is to add a new “Participant Log” field to the Participants Database on the Manage Database Fields page. This new field is the “container” for the log, and in most ways is simply another field in the database. The General Settings tab of the plugin settings menu provides a way to add a new log. When this field is created, a new table is added to your WordPress database which will hold the data for the log.
It is important that the name of your log should be the name of what is stored in it. If, for example, the log is meant to record a person’s time spent volunteering, you might call it “Volunteer Hours.” If it is storing a record of class attendance, you could call it “Class Attendance” or “Attendance Record.” You can change the title that is displayed once it is set up, but the name of the log field can’t be changed, so it’s worth taking a minute to think about what you call it before committing the name. Once you set up the log field, you can configure what is recorded in each entry of the log you created.
Configuring the Log
On the Participant Log admin page, you will see a tab for the log you created. Under that tab you can configure the log: you can set the name for an entry or entries which will help the user interface make more sense. There are more settings that determine what the frontend user can do and also how the log will be displayed in various contexts. This will be explained in more detail later.
Configuring Log Entry Fields
Each log can have as many fields as needed to hold whatever information you need to store in each entry. The user interface for that is the same used for managing the fields in the main database. You can add fields, and then configure each field as needed. They work the same as fields in the main database. Each entry field you create for the log adds a column to the log’s database table.
Field Visibility
Entry fields have a “Visibility” setting that determines the context in which the entry field will be shown. “Public” means the field will be shown in all contexts. “Private” means the field will only be shown to the owner of the record and administrators. “Admin” means the field will be visible to administrators only.
Searchable Fields
When list searching is enabled, only fields that are both visible and marked as searchable will be used to get search results. This is helpful to making searches more efficient and avoids spurious results.
Searchable log entry fields are also available in regular Participants Database list displays so that records with log entries that match the search can be found.
Sortable Fields
Fields that have this setting enabled will be shown in the header of log entry list displays so the log can be sorted by the value of that field.
Field Validation
Entry fields can be made required in the entry field’s configuration. The entry fields use “client side validation” which means the user’s browser will perform the validation and provide the feedback. This is going to look slightly different on every platform, there is little you can do about that, but it has the upside of working on all platforms and devices. To make a field required, you set the validation setting to “required.” You can add to the field validation configuration by using validation attributes.
The Admin Record Log Display
The log display on the record edit page in the admin shows a list of all the entries. The list is paginated, and the number of entries shown on each page of entries is determined in the general settings for the log, in the “Entries Per Page” setting.
The display for the log on the frontend is similar, but what controls are shown depends on the configuration.
Entry List Filtering or Searching
There is a search input at the top, any text typed into the search input will be used to filter the list of entries. On the admin side, all the visible entry fields are included in the search. On the frontend, only fields marked as “searchable” will be included in the search.
Entry List Sorting
The entries can be sorted by clicking on the blue arrow icons seen in the top bar. The fields that can be used for sorting are configured in the log entry fields configurations: check the “Sortable” checkbox to configure the field to appear in the sorting bar.
Adding Entries
Once you have the entry fields set up, you can begin adding entries to the log. Entries can be added in the admin by going to the admin edit record page for the record you want to add log entries to. Find your log field on the edit record page and in the display for the log field, you will see a button with a plus sign for adding a new entry. Clicking that will bring up a form for entering the data for your log entry. Each entry may also be edited by clicking the pencil icon next to the entry. Clicking the pencil will open a form where the contents of the entry can be changed. Entries can be deleted individually by clicking the red on the entry line. When the “X” is clicked, you will be asked to confirm deleting the entry. There is no undo, deleted entries are gone forever unless you restore it from a backup.
Exporting/Importing Entries
In the admin record edit display (Edit Participant), the entry data for the record’s log can be exported as a CSV file. This works pretty much the same as exporting records from Participants Database: if you have used a filter, the export will only include the entries shown after the filter is applied. Records can also be imported with a CSV file. It’s also possible to import and export data for all records on the Participant Log admin page under the tab for the log.
The Frontend Log Entry Display
In single record and editable record displays on the frontend, the log is displayed as a list of entries. It is very similar to the display in the admin, only the ways that the user can interact with the list are controlled by settings. This is so you can choose whether the log can be added to by users, entries edited, deleted, etc. When the record is displayed using the [pdb_single] shortcode, a list of entries is shown using the template style chosen in the Participant Log settings under the general tab. The entry list in this display can be sorted and filtered. Only log entry fields that have “public” visibility will be shown in this display.
Display Templates
For the frontend displays of the log entry list, 3 basic templates can be chosen. Which one you choose is going to be determined by what you need to show, and what is going to work best for your users.
The Table template will put the log entries into a fixed-width grid so all the values will line up below a header row. This can be the clearest way to show the log entries, but you can only control the width of the table by controlling how many log entry fields you’re showing. Also, it isn’t great on small screens because the width is not determined by the device’s screen width, and so horizontal scrolling is usually required to see all the information.
The Responsive template takes the approach that every log entry field is a separate element with its own width determined by the title and data display. These elements can flow into whatever configuration will fit on the screen. With this template, all the data will be visible on any device, but it can be cluttered.
The Grid template is kindof a bend between the two. It is responsive in that the width of the log display is determined by the width of the device display, but instead of each entry field having its own width, the widths of the entry fields are controlled into columns. This can result in a more organized and easier to see display of the log entry data.
For any kind of responsive display, some adjustments of the CSS that controls the layout are often needed. These additional CSS rules can be placed in the Participants Database Custom CSS setting.
The Summary Display
Each log entry list display may optionally show a “summary” which is configurable to show an important value, such as the number of entries. By choosing a different sum type, the summary can also display other values. If the sum type is a numeric field, the summary will be a sum of the entry values for that field, such as for a work log that shows the number of hours worked. If the field is not a numeric field, the summary will show the number of records that contain a value for that field or if the field has a default value, the sum will show all the fields that have a value different from the default value.
When searches are performed on the list or when a date range is selected, the sum value is immediately updated to show the correct value. This also happens when entries are added, deleted or edited.
This sum value is also saved in the main database so that in Participants Database list displays, the list can be sorted by the summary value: for example you could rank volunteers according to the number of hours logged, or place the collector’s club member with the largest collection at the top.
Showing an Interactive Log Entry List
When the editable record is displayed using the [pdb_record] shortcode, the log entry display is sortable and filterable, but it is also possible to enable adding new entries, editing and deleting entries, and also import and/or export entries using a CSV file. The settings that control access to these features are in the Participant Log settings, under the General Settings tab. The user interactions in this display are very similar to what is possible in the admin. Log entry fields that have a visibility setting of “public” or “private” will be seen in this display.
Frontend Imports and Exports
The interactive log list display can also be configured to allow the user to import and/or export data to a record’s log. This is enabled under the global settings for the [pdb_record] log display.
Global Log Displays
It’s possible to display a list of log entries that are taken from all the log entries in all records. There is a special shortcode [pdb_log_list] that will show all the entries in the same way that the Participants Database list shortcode shows a list of Participants Database records. You can use shortcode filters, custom templates, search, sort, etc. to customize the display.
An example of the use of this shortcode would be a car club, where each member keeps a list of the cars in their collection. The global log display could be used to show all the cars in the club.
If you’ve got more than one Participant Log defined, you can tell the shortcode which one to use with the log_name attribute. Just give that attribute the name of your log, and it will show entries from that log. For example:
[pdb_log_list log_name=cars]
Log List shortcodes can be filtered just like the Participants Database List shortcode, you can filter by fields in the main database and by fields in the log. Check out the linked article for details.
Settings
General Settings
These settings will affect all logs, but it is possible to override them for a specific log in the participant log field definition attributes setting.
Enable Log Search: when checked, a search input will be shown above the display of log entries. This search input will search on visible fields only.
Enable Log Sorting: when checked, fields that are configured as “sortable” will show as sorting links in the header of the log entry list.
Enable Date Created Sorting: the “Date Created” field is an automatically set timestamp for every entry. This switch allows the user to sort the entries by this timestamp field.
Entries Per Page: sets the default number of entries to show in the list. If there are more entries in the log than this number, a pagination control will be shown.
Record Shortcode Settings
These are settings that pertain to showing the log list when using the [pdb_record] shortcode. The log list in this context is editable.
Record Shortcode Log Template: select the display template to use when showing the log entry list.
Enable Creating New Entries: when checked, allow the user to add entries.
Enable Editing Entries: allows the user to edit entries.
Enable Deleting Entries: allows the user to delete entries.
Allow Log Export: allows the user to export a CSV with the log entry data.
Allow Log Import: allows the user to import log entries in a CSV file.
“Slide In” Entry Controls: when checked, the log edit controls will be hidden until the user hovers over an entry. This is good for compact displays.
Highlight Color: lets you select the color to use when highlighting an entry while it is added or edited.
Single Shortcode Settings
These setting are used when showing the list of log entries when using the [pdb_single] shortcode.
Single Shortcode Log Template: selects the display template to use when showing the log entry list.
Individual Log Settings
For each log you have defined, there is a tab and under that tab are settings that are specific to that log.
Log Fields
In this section, the fields that are used for each entry of a log are defined. The interface is very similar to the one used on the Manage Database Fields page. There are a few differences, for example, there are no field groups (instead there is a “visibility” selector). And, like the Manage Database Fields interface, which options you can set depend on the type of field you have created. You can edit, delete and add log entry fields in this interface.
It is highly recommended that you define all the fields you need to use before adding entries to the log.
Log Options
For each log, a set of options is available:
Log Entry Name: name for a single entry.
Log Entry Name Plural: name for several entries.
No Entries Message: message to show when a log has no entries.
Search Field Placeholder: when the search input is shown, this placeholder string will serve as a prompt for the user.
Entry Image Height: the nominal image height for images uploaded to a log entry. The aspect ratio will be preserved in most cases.
Entry Dates
These settings are for configuring how entries are dated.
Primary Date Field: this allows you to select a log entry field to use as the date for the entry. It defaults to the timestamp that is set when the entry is created. You would use this in the case of something like a list of events where the date of the event is more important than the date the entry was created. This date field will be used to sort the entries chronologically.
Show Log Entry Timestamp: every entry has a timestamp, this preference lets you make that timestamp visible.
Timestamp Title: if you are showing the timestamp, this is how it will be labeled.
Date Range Filter
It is possible to filter entries by date range, these settings configure the date range interface.
Enable the Date Range Filter: check this to turn on the date range control for the log.
Date Range Filter Heading Text: title for the date range control. Leave blank for no title.
Date Range Filter Button Text: text for the button that performs the date range filtering.
Entry Sum Display
The “entry sum” is a feature of the log where a configurable sum is shown. The default is to show the number of entries, but if there is a numeric field in the log entries, the entry sum can show a sum of those values. For example, in a work log, it can show the number of hours worked.
Show Entry Sum in Record Displays: this is to enable a summary display just above the list of entries.
Sum Type: this is where you would configure what is summed.
Sum Display Template: this gives you a way to control how the sum is displayed. There are a number of “value tags” you can use to show dynamic values from the log in the summary display.
Additional information
Site License
Multiple, Single
5 reviews for Participant Log
Rated 5 out of 5
Pierre Biais (verified owner)–
Amazing plugin as usual. I use it to insert/update many different log entries programatically and it works great thanks Roland!
Rated 5 out of 5
Frank Graziani (verified owner)–
The participant log plugin is a great extension for the standard version of the database. It meets all my requirements. Without this plugin I would have had to program a lot by myself. The support from Roland is very friendly and above all fast. The upgrade is worth every penny. Thanks very much!
Rated 3 out of 5
Steve Hegenbart (verified owner)–
Dear Roland
I’ve just downloaded the add-on and tried it with our staging environment. When creating a log entry the new field does not seem to be created correctly. The new database table is missing. The field itself is there, both in the admin and frontend sections. When opening the frontend, there is an php error message on top telling me that the table cannot be found.
Any ideas here ?
Greetings
Steve
Roland Barker –
I don’t know exactly what the problem is, but when the “Participant Log” field is created, the table for that log is created at that time. There may be something in your configuration that prevented that.
What I would suggest you try is delete the Participant Log field you created, then re-create it with the same name. Immediately check to see if the table was created, if not, take a look at the php error log to see if there is an indication of what wen wrong.
Rated 3 out of 5
Ryan (verified owner)–
The Participant Log is great, with one caveat. It seems that there is no way to actually delete a log entry. It just hangs up as it’s loading. And re-importing an updated CSV file doesn’t remove the unwanted log entries either.
Roland Barker –
Hi Ryan,
I’m sorry you’re having trouble with the delete feature, it’s working in my tests here…but in your case something else is happening. A hung operation such as you describe can be due to an error in the back end, and the best way to know what that is is by checking the php error log. It can also be due to an error on the frontend, and you can check on this by opening your browser developer tools, then test the delete function with the “console” open. If an error comes in there, there is an issue with the javascript, possibly a conflict with some other functionality on the page.
If you don’t see an error on the frontend, you can turn plugin debugging on (Participants Database settings under the advanced tab), then try the delete and check the debugging log for anything that pertains to that operation.
As to deleting entries with a CSV import, I’ve considered this and have not yet come up with a way to do that that doesn’t result in unexpected data loss. Some people use the CSV import to add new entries, they would not expect existing entries to be deleted. So, at this point, a feature like that is an open question, and I’ve defaulted to not deleting just to be safe.
Let me know what you find
Rated 5 out of 5
Serge (verified owner)–
Excellent add-on comes in really useful Thank you!
If you find my plugins useful, and would like to encourage or support its further development, please drop a little something into the tip jar or give the plugin a rating.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
Pierre Biais (verified owner) –
Amazing plugin as usual. I use it to insert/update many different log entries programatically and it works great thanks Roland!
Frank Graziani (verified owner) –
The participant log plugin is a great extension for the standard version of the database. It meets all my requirements. Without this plugin I would have had to program a lot by myself. The support from Roland is very friendly and above all fast. The upgrade is worth every penny. Thanks very much!
Steve Hegenbart (verified owner) –
Dear Roland
I’ve just downloaded the add-on and tried it with our staging environment. When creating a log entry the new field does not seem to be created correctly. The new database table is missing. The field itself is there, both in the admin and frontend sections. When opening the frontend, there is an php error message on top telling me that the table cannot be found.
Any ideas here ?
Greetings
Steve
Roland Barker –
I don’t know exactly what the problem is, but when the “Participant Log” field is created, the table for that log is created at that time. There may be something in your configuration that prevented that.
What I would suggest you try is delete the Participant Log field you created, then re-create it with the same name. Immediately check to see if the table was created, if not, take a look at the php error log to see if there is an indication of what wen wrong.
Ryan (verified owner) –
The Participant Log is great, with one caveat. It seems that there is no way to actually delete a log entry. It just hangs up as it’s loading. And re-importing an updated CSV file doesn’t remove the unwanted log entries either.
Roland Barker –
Hi Ryan,
I’m sorry you’re having trouble with the delete feature, it’s working in my tests here…but in your case something else is happening. A hung operation such as you describe can be due to an error in the back end, and the best way to know what that is is by checking the php error log. It can also be due to an error on the frontend, and you can check on this by opening your browser developer tools, then test the delete function with the “console” open. If an error comes in there, there is an issue with the javascript, possibly a conflict with some other functionality on the page.
If you don’t see an error on the frontend, you can turn plugin debugging on (Participants Database settings under the advanced tab), then try the delete and check the debugging log for anything that pertains to that operation.
As to deleting entries with a CSV import, I’ve considered this and have not yet come up with a way to do that that doesn’t result in unexpected data loss. Some people use the CSV import to add new entries, they would not expect existing entries to be deleted. So, at this point, a feature like that is an open question, and I’ve defaulted to not deleting just to be safe.
Let me know what you find
Serge (verified owner) –
Excellent add-on comes in really useful Thank you!