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
- Setting Up the Log
- Configuring Log Entry Fields
- The Admin Record Log Display
- Adding Entries
- Exporting/Importing Entries
- The Frontend Log Entry Display
- Showing an Interactive Log
- Showing a Global List of Log Entries
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.
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.
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.
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.
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.
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.
Hey Roland it’s me again, I hope I won’t bother you much after this question.
I would like to add a button icon next to the update icon of an entry to allow users to duplicate it.
Could you point me to the right direction please?
It would open the popup to Add an entry with all the field values taken from the entry to be duplicated.
For now I’m displaying a checkbox that users can tick so that when they update the entry, I create the entry using \pdblog\log\entry_db::add_entry in the filter pdblog-{$log_name}_before_update_log_entry
and then return false to the filter
It works except that I get many lines like this in the debug :
[17-Mar-2021 16:53:39 UTC] PHP Warning: array_key_exists() expects parameter 2 to be array, bool given in /home3/eventtf0/public_html/realestate/wp-content/plugins/participants-database/participants-database.php on line 1741
And also it shows that the last_name, first_name and email are required when I click on Update entry instead of closing the popup.
Yes, returning false to the {$log_name}_before_update_log_entry filter will do that because it is expecting an array in return.
Is there a way to prevent the entry from being updated in that case?
There is no filter for the cancel button?
I am trying to avoid running a select to recreate the original entry array so that the update runs fine but I cannot even do that because I don’t see the entry id in the array
Actually, you should run a select on the database, that is the best way to do it.
Yes I’m going to run a select but I need to find the entry id first.
When I’m in the update filter, there is no way to retrieve that value with PHP?
I guess I’ll just have to learn JS and do something like you did : var record_id = wrap.data(‘record-id’);
Hi Roland,
FYI I tried to duplicate an entry with JS but it was too complicated to even display the spinner properly so I ended up adding 2 lines in participants_database.php
Before the SQL statement :
if ($post[‘properties_interactions_duplicate_interaction’] === ‘Yes’) $action = ‘insert’;
And after :
if ($post[‘properties_interactions_duplicate_interaction’] === ‘Yes’) $action = ‘update’;
To avoid a JS error when returning the result.
I know it’s not clean at all to do that but I couldn’t find a better solution.
Hi Roland,
When I use pdb_record on the frontend, I can add and edit without issues but when I try to delete an entry it just shows a circle turning around forever. No JS error in the console and nothing in the WP debug log.
I also cannot filter the dates, it doesn’t find the entries when it should.
Both delete and filter actions work fine on the backend tho
Any idea?
Everything is working fine with the Nineteen theme so it’s definitely an issue with the Divi theme.
There is likely a php error somewhere, but it may not show up in error logs that are monitored with WP plugins, you need a server-level php error log to catch that sort of thing. Hung operation can be due to JS error too, but that would show up in the console. Another thing to check is the Network panel, you will see the AJAX transaction if you clear the panel then attempt the delete. There will probably be an error code. If it is a 4XX code, it’s probably a security setting. A 500 indicates a php error.
If it works in the backend but not the front indicates either JS error or caching issue.
Is there a way to make the text area fields output the line breaks and paragraphs?
Thanks
Text area fields are for unformatted text, so no, not really. You can enter line breaks by holding down the shift key and hitting return. If you want formatted text, you would need to use a rich text field, but that is not currently supported in a log field entry, I’m sorry.
Hi Roland,
I am using your very useful script to populate a log field dropdown but I noticed pdb-form_element_build_dropdown is also called for that field when the record form is displayed (not only when I want to add a new entry). Is there a way to avoid that unnecessary sql query?
Probably, I don’t know…not sure where to find the code you’re referring to, but if it’s example code, I probably didn’t bother to optimize it.
I meant this code https://xnau.com/populate-a-form-dropdown-from-the-database/?swcfpc=1 but it’s not a complex query so it’s fine to leave it like this actually
I managed to do it filtering the page like this : && basename($_SERVER[‘PHP_SELF’]) != ‘index.php’)
Because the insert log uses admin-ajax.php
Yes, that filter is called on any page that displays the field (even just to display the value) because the value in the database is a reference to the defined value in the field’s options. The code could be optimized by caching the query result, that would be the usual way to do it.
Do you also provide a filter similar to pdb-before_submit_update that allows to change the log fields values before they are inserted or updated?
This is a good question, I did not have a filter like that in place, but in the latest release, I added one. Here is the documentation for the filter:
/**
* @filter pdblog-{$log_name}_before_{$action}_log_entry
*
* $action will be ‘insert’ or ‘update’
*
* @param array the post data
* @param string the entry id
* @return array the post data
*/
Amazing! Just installed the last version and it works like a charm, thank you so much for that filter!
The pagination doesn’t seem to work (at least on my setup) with pdb_log_list.
Same with the default WP template of different themes.
When I try to click on the second page or the right arrow it just gives me a blank page with no possibility to even go back so I have to reload the page every time.
As a workaround for now I have to set list_limit=1000 to be able to see all entries.
If the pagination doesn’t work, then that suggests that other things may not work either. Open your browser developers tools, then check the console when opening the page and clicking on the pagination controls. There may be a javascript error.
I only get the blank screen when i am logged as admin and it shows no JS error in console.
If not logged in I get a circle icon loading infinitely below the pagination and this error :
jquery.min.js?ver=3.5.1:2 POST https://mysite/wp-admin/admin-ajax.php 400
send @ jquery.min.js?ver=3.5.1:2
ajax @ jquery.min.js?ver=3.5.1:2
s.ajax.s.ajax @ jquery-migrate.min.js?ver=3.3.2:2
post_submission @ list-filter.js?ver=1.7.4:153
$.fn.PDb_processSubmission @ list-filter.js?ver=1.7.4:232
submit_search @ list-filter.js?ver=1.7.4:82
get_page @ list-filter.js?ver=1.7.4:99
dispatch @ jquery.min.js?ver=3.5.1:2
v.handle @ jquery.min.js?ver=3.5.1:2
list-filter.js?ver=1.7.4:195 Participants Database JS error status:error error:
/wp-admin/admin-ajax.php:1 Failed to load resource: the server responded with a status of 400 ()
list-filter.js?ver=1.7.4:195 Participants Database JS error status:error error:
It does work fine on FF/Android tho but not Chrome/android
Disabled all plugins with Site Health troubleshooting plugin except Pdb and PDBlog but same issue so no plugin is interfering with the JS
And I get these errors in the debug when trying to go to the next page :
Trying to get property ‘mode’ of non-object
in /home3/eventtf0/public_html/realestate/wp-content/plugins/pdb-participant_log/pdblog/Log_Field_Group.php on line 82
Trying to get property ‘name’ of non-object
in /home3/eventtf0/public_html/realestate/wp-content/plugins/pdb-participant_log/pdblog/Log_Field_Group.php on line 52
This suggests that the field configuration is out of sync…the “non-object” is a missing group definition. Groups are used as a container for the fields in a log, and are found in the wp_participants_database_groups table.
Your other two posts are also because of this issue.
Forgot to post the db error :
WordPress database error Unknown column ‘pdb.id’ in ‘field list’ for query SELECT p.id, pdb.id AS pdbid, pdb.properties_interactions_property_name, ………………pdb.properties_interactions_filter_view FROM wp_participants_database_properties_interactions p ORDER BY p.date_recorded DESC made by do_action(‘wp_ajax_pdb_log_list_filter’), WP_Hook->do_action, WP_Hook->apply_filters, pdblog\Log_List::list_filter, pdblog\Log_List::print_list, pdblog\Log_List->__construct, PDb_List->__construct, PDb_List->_setup_iteration, QM_DB->query
VS the 1st select on the 1st page that doesn’t get mixed up with the pdb table prefix :
PDb_List::_setup_iteration list query: SELECT p.id, ………..FROM wp_participants_database_properties_interactions p ORDER BY p.date_recorded DESC
To fix the bug temporarily I changed that line in Log_List.php :
if ( ! in_array( $field, $log_fields ) ) {
by
if ( ! in_array( $field, $log_fields ) && !empty($log_fields) ) {
No idea yet why the second page is generating this empty array causing to add the pdb table in the query
I’ll let the expert have a look =) Let me know if you need more info
Those 400 codes are a problem….that is usually due to a security issue of some kind. One thing that can cause the 400 is if the display is “stale” because there is a security code in the submission that is timestamped. A fresh refresh of the page just before testing might help…that’s a longshot though.
Almost nothing will work until the issue with the 400 is resolved. Your web host should be able to help with that, it is an error that will show up in the server logs. I’m not seeing these problems with Chrome/Android on my tests here.
OK it is working fine now. Looks like some records were deleted (not displayed) on the record logs but not actually deleted in the sql table. Thanks
I am trying to export log entries and import them to another record (duplicate records have been created for the same patients, so I need to combine them).
I can export the log entries ok, but even if I change the record id in the csv to match the record it is going to, the upload does not work. The progress spinny thing just keeps spinning and the debugging log shows:
[03/11/21 9:03am UTC]
Participants_Db::process_form storing record: UPDATE wpxf_participants_database_treadmill SET
= NOW(),
= ‘1615334400’,
= ‘5’,
= ’20<22′,
= ‘2.5/2.5/2.5/2’,
= ”,
= ”,
= ”,
= ‘Swansea’,
= ‘MT’,
= ‘720’ WHERE id = 1729
id 720 is the record it was exported from but I changed it in all the entries in the csv to the record it is being imported to (382).
How can I move these logs?
Thanks
Hi Laura, this is a great question, and one I’ve never checked in to.
You’re correct that you need to modify the CSV in order to import to a new record. You got that you need to change the record ID to match the record ID of the recieving record, but the other thing you need to do is delete the “id” column completely. If the entries import with an ID, the importer assumes you’re updating existing entries (which won’t exist, and therefore the error), but if the entries don’t have an ID at all, they are assumed to be new entries. And that is what you want.
That makes sense, I had actually tried deleting the ids but not the column itself. Unfortunately it’s still not working, spinning circle just keeps spinning. There are only a few entries so I would expect it to be quite quick.
Well, the hanging import is another issue unrelated to altering the CSV for moving the logs from one record to another. If you’re not seeing an error in the logs, what you need to do is open the Developers Tools Console and try the upload…see what comes in to the console that is hanging things up.
Are you performing the import on the frontend or admin side?
I’m doing this admin side. It does seem to upload the first two rows, if I leave it going and then cancel it (I’ve left it for varying amounts of time), although you don’t see them til you submit and come back into it.
I can’t post what the dev tools says, as it says it’s unsafe.
It actually works fine if there is only one row in the csv file. It’ll import 2 fom a file with more rows but does hang.
Thanks
There is probably a php error happening, try using the plugin debug (Participants Database settings under the advanced tab) and then check the debugging log after attempting the upload.
I don’t understand how to get a specific log to display.
I tried [pdb_log_list log_name=properties_interactions] and [pdb_log_list log_name="properties_interactions"] because properties_interactions is the participant log field name but I always get the first log to display instead
My bad! The shortcode was not properly interpreted by the WP page so the attributes would look like this :
[10-Mar-2021 02:53:58 UTC] atts: Array
(
[0] => log_name=properties_interactions
)
On a new page it was fixed!
It’s indeed easy to modify the log field values with the filter pdb-before_display_form_element but is there a way to also modify dynamically the log field titles?
Forget the above question it looks too complicated.
What is a lot more important is to be able to change dynamically a link field and not just the text displayed, is it possible?
You can change the link property (which holds the href value of the link) of the field in your filter.
OK thanks I managed to do it putting html into the value because I couldn’t find how to change the link property and return the object as it’s expecting a string for the return value.
if ( $field->name === 'properties_interactions_property_link' ) {
//$value = array("link" => "http://google.fr");
$value= '<a href="https://www.google.com">Voir</a>';
}
return $value;
}
I noticed this bug when trying to filter pdb_record with a field name from the log table :
[07-Mar-2021 00:52:23 UTC] PHP Notice: Undefined index: properties_interactions in /home3/eventtf0/public_html/realestate/wp-content/plugins/participants-database/classes/PDb_Shortcode.php on line 720
[07-Mar-2021 00:52:24 UTC] PHP Notice: Undefined property: stdClass::$properties_interactions_property_name in /home3/eventtf0/public_html/realestate/wp-content/plugins/participants-database/classes/PDb_Template.php on line 618
[07-Mar-2021 00:52:24 UTC] PHP Fatal error: Uncaught Error: Call to a member function set_value() on null in /home3/eventtf0/public_html/realestate/wp-content/plugins/participants-database/classes/PDb_Template.php:618
1. Is there a way to display only specific fields from the log table? I cannot use the visibility setting as I’m doing it programatically.
2. Where is the setting or template that allows to display log field values even when they are empty? Using a custom template from pdb-record-tabs.php
3. Is it possible to make a log field searchable on the frontend but not displayed (hidden field doesn’t work?
NB : Yes JS doesn’t look complicated, I’ll give it a try later (cf previous comment)
Thank you!
1. It’s not possible to determine which log entry fields are shown in the shortcode, this is controlled by the visibility setting of the log entry field only.
2. In most templates, empty log entry fields are hidden with a CSS rule that selects the “empty-item” classname. You can add your own CSS rule to override this.
3. Searchable but not displayed? Yes, just hide the field using CSS.
Oh amazing I’m not a coder so I didn’t know we could do that with CSS! Thanks for pointing me to the right direction :)
Hey Roland!
One last question if I may : it’s pretty easy indeed to hide elements in CSS but what if I need to change the values in the log table displayed but not the value of the log field in the database?
Doing a echo print_r($this,1) helped me to understand how to deal with “classical” pdb fields but I only see the Participant log field in the $this object. Is it possible to access what’s inside so that I can put conditions in the template for the display of the forms?
Yes, it’s possible. You can use the pdb-before_display_form_element filter to alter the value that is displayed. This filter gives you access to the display value of a particular field, you can see the filter in the source in the PDb_Field_Item class. You can set up your filter handler at the top of your template.
Oh, and thanks for the bug report, I didn’t know that was happening.
Hey again!
Sorry I have a more complicated question but it’s not urgent as option 1 would be fine for now .
I have a log with many interactions of users and I would like to be able to let the person who views or edits the record to be able to filter if needed the “list” of entries so that it shows only the last interaction for each user.
So far I see 4 options :
1. Run an update in the database every time there is a new user interaction and set a field to “distinct” (for example) only on that entry and set the older ones to null.
This way I can tell the person to type distinct in the search to filter the results
2. Have another distinct log/tab used that is also handled by sql queries with an insert if it’s a new user or update the entry if it already had an interaction
3. Have a button or a link in the displayed log table that loads the page with a filter on the table
4. Have a checkbox on the page that will run the search automatically with the word distinct (same as 1 but more user friendly) using PHP or maybe some JS to input the string in the search field
Actually it would be better to have the filtered entries shown by default with an option to show all the interactions.
Which solution would you recommend? Or maybe a better one? :)
Thanks!
The only helpful option that is built in to the plugin is to limit the number of entries that are shown using the “Entries Per Page” setting. The entries are going to be sorted by date with the latest ones at the top, so the entries you’re looking for should be on the first page of entries.
If you need to mark entries as having been checked or whatever it is the editor needs to do, you should add an administrative checkbox field. You can then use the value in that checkbox field to filter the results. That filter setting is not retained, however, so the user will need to enter it each time they open a new record.
If you understand the javascript it is possible to add a button that can apply a preset filter. You will need to use an action such as “pdb-before_edit_participant_body” to place you own javascript on the admin edit participant page.
Thanks for your prompt reply! Not sure I expressed myself clearly tho.
Below are some random log entries :
User Date
Marc 04/03/2021
Marc 06/03/2021
Pierre 02/03/2021
Roland 03/03/2021
The sort on the Date field in the settings will give me :
User Date
Marc 06/03/2021
Marc 04/03/2021
Roland 03/03/2021
Pierre 02/03/2021
But I want an option to show only distinct users like this :
User Date
Marc 06/03/2021
Toto 03/03/2021
Pierre 02/03/2021
I don’t know much about JS so I could hire you guys for a custom script but first I want to see if I can display this table in a new tab which would not be a real group, just created on the fly when the page loads with my custom record template.
I’ll post a comment now in the proper tech support page. Thanks.
The last Toto was meant to be Roland :)
Yes, I’m sorry, I don’t provide custom coding services. I was providing you with the information you’d need to implement this yourself.
If you’re doing this on the frontend (I assumed you waer talking about the backend) it’s easy to add custom javascript to the custom template…but I’m leaving it to you to actually come up with the code. Sorry, I can’t do this for you.