Product Support

Participant Log

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.

Product Setup

Global Log Configuration

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.

log field structure diagram
Example setup for an attendance log

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.

An example of a set of fields defined for a work log.

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.

Product 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.

Tabs for individual logs: “Work Log” and “Projects Completed”

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.

An example of a set of fields defined for a work log.
Configuring a log entry field

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.

F.A.Q.

Is it possible to override the global setting in individual logs?

Yes, this happens in the log field definition on the Manage Database Fields page in the main plugin. You add your override to the “attributes” for example to override the global setting and allow adding entries on the frontend:

allow_frontend_add::true

Here is a list of the global settings with the proper name to use in the attribute:

Setting attribute name
Enable Log Search enable_log_search
Enable Log Sorting enable_log_sorting
Entries Per Page entry_list_limit
Record Shortcode Log Template record_module_log_template
Enable Creating New Entries allow_frontend_add
Enable Editing Entries allow_frontend_edit
Enable Deleting Entries allow_frontend_delete
Allow Log Export allow_export
Allow Log Import allow_import
“Slide In” Entry Controls hide_entry_controls
Highlight Color highlight_color
Single Shortcode Log Template single_module_log_template
How can I show a customized sum of values for the log list?

Each log has a “summary display” that can be used to show a simple sum from the log data. If you want to show a sum that is specific to your application, such as a sum that is conditional, or a sum that involves multiple entry fields, you need some custom code for that.

In technical terms, the code you need is a filter handler that takes the normal value that would be displayed and changes it ro a custom calculated value. This is best added as a custom plugin or you can put it into your theme functions.php file.

The filter hook is pdblog-{$logname}_sum where {$logname} is the slug name of the log field. You’ll see that on the manage database fields page where the log field is defined.

The filter gets two arguments: the configured sum value (in other words, what the sum would show if you didn’t change it) and the second argument is an array of the record’s log values. You can calculate your sum from the values in that array, and then the filter handler should return your new sum, which will be displayed with the log as configured in the log’s settings for the summary display.

There is a simple example here: https://gist.github.com/xnau/fb961393fc675cf802a509a2a1c888d1

 

Is it possible to provide a link to the editable record in the Global Log List?

The Global Log List shortcode will show a filtered list of entries from all records for a particular log. Each line in the list is an individual entry from a record’s log. It is possible to place a link to the editable record in this list so that the log entry can be edited. This requires the use of a custom template.

Be sure to control access to this list display, you will be giving edit access to your records when you use it.

To use this custom template, you must first create a “placeholder” field in the main Participants Database plugin. You can also re-use an existing placeholder field if you want. Below is a link to the custom template. You must modify it to use the placeholder field you set up.

pdb-log_list-edit-link.php

Is it possible to delete log entries that are no longer connected to a PDB record?

As of version 1.5.9, when a Participants Database record is deleted, the entries belonging to that record are deleted also.

If records were deleted prior to that version, or if records were deleted not using the “with selected” delete method on the List Participants admin page, you can end up with entries that no longer have a parent record.

There is a utility function you can use to clear these out. To do that go to the Participant Log admin page. Add &pdblog-delete-orphan-entries=log_name to the URL and hit return. This will clear out all the entries that are not connected to a PDB record. For example, if your log is named “automobiles” you can clear out the orphan entries from that log with a URL like this:

When creating a field for a new log, I get this error message: “Failed to create table for this log. You need to use a different name for your log.”

The message you’re seeing means that the table needed to create the log could not be created for some reason. The part about trying a different name is just the most likely reason for the failure.

What I suggest you do is start over: on the Manage Database Fields page, delete the log field. It will be a field of type “Participant Log” Once the log field has been deleted, go to the Participant Database settings under the Advanced tab and turn plugin debugging on to “all errors”. Once that’s enabled, open the Debugging Log page and clear the log.

Now, recreate the log: go back to the Participant Log settings page and create a new log. Try using a very simple name for the log at first…you can always change the display name of the log later, but when you’re first creating it it’s a good idea to use something simple. Once you’ve created the new log field, go back to the Participant Log settings and under the tab for the new log, create your first field for the log. If you get the error message again, check the debugging log.

If you can’t create the log field because of the error, post a question to tech support on this page.

Be sure to turn plugin debugging off again once you get things set up and working.

Support Discussions for Participant Log

  • Hey Roland,
    I have added the plugins into the back end, but when I go to add a new entry in the front end, the yellow box appears but I cannot type anything into any of the fields. I have added date and notes section in the settings > p.database > p.log

    Do you know why this could be? Many thanks
    Nick

    • What theme are you using? The plugin is not currently compatible with the new block-based themes. I’m working on an update. If you’re not using the Twenty Twenty-Two theme, you probably have a javascript conflict with another plugin. You can try deactivating other plugins to see if you can identify the source of the issue.

  • Global Log Display question.

    I am considering creating an attendance tracker with this plugin.
    I would like to be able to edit or add a log record for each person at the event.
    It would be a list of all members with a check box for each person in attendance.
    The date and even name would be a global selection at the top of the display and each added record would contain this information if the check box field is selected.
    I assume there would be a save button to update the fields as needed.

    Can you provide some guidance about how to implement this?
    I am fine with some coding in a custom template.
    Just want to be sure this is possible before I start attempting an implementation.

    Editors would be providing the updates so no need to deal with user input.

    • I don’t have a complete picture of what you want to do from your description, so I can’t say for certain if the plugin can do this.

      Yes, you can keep an attendance log for each person in the database, but the interface for recording their attendance requires you to open each record for editing, then add the attendance log entry for that record.

      As to the global log display, it is controlled by customizable php template, so given the coding skills a lot is possible there. It is not normally interactive (aside from search and sort functions), so you’d be building any interactivity you wanted into that display. While it is possible to construct the global log display shortcode to only show attendance for a specific event (filtering by a field in the log), it is not normally possible to make that interactive (that is, you would not normally be able to select with event the lost focuses on). Of course, it is possible given the skills to implement it.

      I guess the short answer is that as far as I can tell, to implement what you describe would require more than basic php skills.

  • Hello, thank you for your superb plugin!

    I would like to know if there are hooks in the log plugin, fired when there is a creation or an update. I would need to store the current wp user ID or name for each log row (as many different wp users could create/update log rows).

    If there are hooks, would it be possible to have a list?

    Thank you!

  • Hello,

    I just downloaded and set up my plugin. I’m not sure if the is possible. From wag at I have read and understood I’m not sure if what I want can be accomplished. But all I want is a front end list that acts as a weekly attendance sheet which gives all the participants names from the data base, the data date, and next to each name a check box to mark members present. The list would be used by a volunteer, so I wouldn’t want them to have access to the admin.

    That’s all I need. Is this possible?

    Thank you for your time.

    • Yes in general, but it’s not going to be that simple because for each person on the list, the volunteer will have to open their record, then add a log entry for their attendance that day. No way to slim that down to just ticking a checkbox.

      Yes, it can all be done from the frontend, but you’ll have to take steps to set up a special template for the list (making record editing available from a list on the frontend is a special case, normally, this is not allowed) then you will need to configure the record edit page to show only the log so the volunteer can make the attendance entry without access to other information in the record.

      So, you will need to put in some time learning how to configure the plugin for your specific needs, it’s not going to work like that out of the box.

  • Hi,

    I would like to set up a Participants Log with 3 levels. Is this possible? eg.
    Level 1
    Person’s name, phone, number address, etc
    Level 2
    A list/log of family members associated with the Level 1 person, each with their own details, eg Mum, Dad, Brother (with contact number, age, etc for each person)
    Level 3
    A list/log of pets for each of those family members in Level 2, with details of each pet, eg Woof, Bouncer, Blackie (with age and food preference for each)

    • Hi Helen,

      What you’re describing is called a relational database, and currently, Participants Database cannot do this. I have an extension to the plugin in the works that will make this kind of thing possible, but it will be several months before that is ready for release.

      The Participant Log add-on can do something like this, but the difference is each log entry “belongs” to the record that holds them, they are not independent records that are simply associated with the record (such as a parent-child relationship). It is good for things that belong to the person (such as possessions or pets), not great for things that are represented as independent records, such as relatives or children.

      It is possible to implement a scheme that simulates the kinds of relationships you’re asking about, but in a very limited way, and it does require you have some technical knowledge to set it up. Take a look at this article for an outline and example of how this is done:

      “Multiple Databases” with Participants Database

      • Hi Roland,

        Many thanks for your quick reply. I’ve had a read through the “Multiple Databases” and I don’t think that fits what I need. I wonder if my example was ambiguous. I do want each log entry to belong only to their parent, they will not relate to any other Participant records. Perhaps this is a clearer example:

        _Level 1_
        Patient Name (contact details, date joined, etc)

        _Level 2_
        Medical diagnosis 1 (name of diagnosis, date of diagnosis, etc)
        Medical diagnosis 2

        _Level 3_
        Treatments for each diagnosis (name of treatment, date treatment started, outcome, etc)

        So Patient 1 may have 1 or more diagnoses, and each of those diagnoses, there will various treatments. Each diagnosis and treatment will be specific to that single patient.

        Is this possible now, or what you are working on?

        • OK, from what I see there, this is possible (with some limitations) using the Participant Log add-on. You could have one log for diagnoses and another log for treatments. Something you would not be easily able to do, for example, would be to dynamically link a treatment to a diagnosis. In other words, you would not be able to have a log of treatments for a diagnosis, the treatment log would belong to the patient. I hope that is clear.

  • Updated to WordPress 5.8.2 and now my pdb_log_list lists are all wrong. I have several lists with different filters but they are now returning the wrong entries.

    For example
    ‘[pdb_log_list template=edit-link log_name="debt" fields="date_recorded, edit_link, debt_added_by, patient_name, last_name, debt_action_taken, debt_type_of_action, debt_insurance_company, debt_deadline" orderby="debt_deadline" order="asc" filter="debt_type_of_action=chase insurance&debt_action_completed="]‘

    should give only ‘Chase insurance’ that are incomplete but I am getting mostly ‘Chase client’ that are complete.

    Thanks

    • I don’t know of any specific issues related to the WordPress update, so I’ll need more information to get an idea what’s going wrong there.

      I suggest you turn plugin debugging on, clear the log, then display your list. In the log will be the database query used to generate the list, that will help understand the results.

      • Sorry, forgot about the log.

        ‘PDb_List::_setup_iteration list query: SELECT p.id, pdb.id AS pdbid, p.date_recorded, p.debt_added_by, pdb.patient_name, pdb.last_name, p.debt_action_taken, debt.debt_type_of_action, p.debt_insurance_company, p.debt_deadline FROM wpxf_participants_database_debt p JOIN wpxf_participants_database pdb ON pdb.id = p.record_id INNER JOIN wpxf_participants_database_debt AS debt ON p.id = debt.record_id WHERE debt.debt_type_of_action LIKE ‘%”chase insurance”%’ AND (debt.debt_action_completed IS NULL OR debt.debt_action_completed = “”) GROUP BY p.id ORDER BY p.debt_deadline ASC’

        • OK, thanks, I will need to issue an update to address this problem.

        • I just updated the Participant Log plugin with a patch that addresses this issue. Thanks for the bug report!

  • Dear Roland

    I’m writing here now, seems like I’ve used the wrong place with the general comments.
    My Problem is still that the log-table is not created.

    What I’ve done so far:
    * Added the log field as instructed via participants-log sub-menu
    * Came to database field configuration, added the field
    -> field was there but db-table missing, no direct error message; php error on user account configuration

    * Removed field, recreated with different name (a couple of times with some php debugging)

    What struggles me is that there are no log entries at all. No php error, no pdb-debug log entries when activating pdb debugging.

    I’ve added following lines of code in the

    pdb-participants_log/pdblog/Field_Manage_Updates.php

    file:

    public function add_field()
    {
    $log_name = filter_input( INPUT_POST, 'group', FILTER_SANITIZE_STRING );
    $fieldname = filter_input( INPUT_POST, 'title', FILTER_CALLBACK, array('options' => '\PDb_Manage_Fields_Updates::make_name' ) );

    +++ error_log(__METHOD__ . ' add pdb-log field method');
    +++ \Participants_Db::debug_log(__METHOD__);

    • — Continuing, as post was too long

      For my technical setup:
      We are running the wordpress page with plesk 18. I am currently working with a reference clone of the page. I’ve also tested deactivating all security features but this did not do anything.

      Currently I try to investigate where the method actually should be called. If you could give me some hints I would try to add more debug logs to find out more about the problem.

      Greetings
      Steve

      • There are specific error messages that are set up to to show if the log’s table can’t be created.

        If you look at pdblog\element\participant_log_db::add_new_log_field() you’ll see this. The function that creates the table is participant_log_db::create_table. That will be called when a new log field is created.

        The code you put your error log statements in is where log entry fields are created, not the log field itself, so this is why you’re not seeing anything from those.

        • Dear Roland

          I finally found the actual problem. Due to an error when opening the pdb-log admin setting page, I was unable to create a new field. As the database is created with the first field (not with the log itself) I never saw the database getting created. Due to a php error the page nearly loaded, but the add-field form did not show up thus I was unable to create the table.

          The whole problem is solved by adding following two lines to

          pdblog\Field_Manager.php

          :


            private function log_option_value( $name )
            {
          ...
          +++   $new_log_options = [];
          +++   if (!is_string($setting))
                $new_log_options = filter_input_array( INPUT_POST, $setting, FILTER_SANITIZE_STRING );

              return isset( $new_log_options[$name] ) ? $new_log_options[$name] : $log_option_value;
            }

          The error told me that

          $setting

          was a string but had to be either an array or int.

          Now it works.

          Greetings
          Steve

        • Thanks for the details, Steve, I will look into this.

        • Steve, can you tell me what php version you are running?

          I do have a fix for this coming in the next update, so you won’t need to worry about an update breaking it for you again.

        • The page is running with PHP 8.0
          Thanks for the update.

  • Hi Roland,

    I’m displaying a global loglist using the csv download template. I would like to show 2 fields from the main fields group from the record i.e first_name and last_name. I also need to be able to search by fields in the log (called classification) i.e classification_event_name, classifier_1

    I can do either but not both using the shortcode filters. As soon as I add the record fields using fields= these become the only fields available in search despite specifying classification_event_name and classifier_1 in the shortcode filter for search fields.

    Is this a result of the way the plugin loads fields or is it a template issue? I’ve tried a variety of templates and replicate the same behaviour so assume it’s how the plugin works when looking for search fields?

    • I’m not 100% clear on what you have attempted, but you can combine main database fields with log entry fields in the “fields” attribute of the log list shortcode. If you use the “fields” attribute, you need to name all the fields you want shown, that attribute value takes over control of which fields to show in the list. Be sure you are getting the names of your log entry fields right, one of them looks incorrect in your question.

      • Sorry if I wasn’t clear. I’ve tried some more scenarios with the shortcode and triple checked the field names (i’ve copied them from the back end to be certain). If I use this shortcode;

        [pdb_log_list template=CSVdownload search=true fields="first_name, last_name, classification_event_name, classification_classifier_1, classification_country, classification_eligability"]

        I get all the fields but only first_name and last_name is available in search. If I remove first_name and last_name and just use log fields then they all appear as search fields in the dropdown. As soon as I add search_fields=”classification_event_name, classification_classifier_1, classification_country” to the shortcode, the search field dropdown disappears completely.

        • Thanks for clarifying.

          It looks like currently, it is not possible to mix main plugin fields with log entry fields in the search dropdown. This is not how it should work, so I will need to issue an update to fix this.

        • Thanks Roland. I’ll await the fix

  • Yes, it is 1.5.2
    I just put the links in the multiselect checkbox options (the links will all be different eventually):
    Square Standing A, Square Standing B, Square Standing C

    • Sorry, didn’t realise it would render that.
      Multiselect checkboxes options are:

      <a href="/test-exercises">Square Standing A</a>, <a href="/test-exercises">Square Standing B</a>, <a href="/test-exercises">Square Standing C</a>
    • OK, I tested that and didn’t see any problems with it, so I’m not sure what’s going wrong in your case.

      Can you send me a link where I can test it myself?

  • In the main plugin I have multi select checkbox fields with hyperlinks, so when selected they provide the desired links for the user (admin selects them, user can access page with pdb_single).

    1). I set them up in exactly the same way in a log, and although when selecting them they have hyperlinks, on the pdb_single page the links are lost. (Also true on pdb_record page).

    2). When editing a log entry the selected checkboxes are not shown as selected, they are all unchecked, even though there are some selected.

    Thanks

    • Hi Laura, I’m checking to this…

    • Laura, can you confirm you’re using the latest version of Participant Log? Should be 1.5.2

      I tested the issue you’re seeing and it’s not coming up for me. Are you using your own custom code to place your links?

Leave a Reply to Alex Dowding Cancel 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.