Participants Database Settings Help

This page provides a compendium of help notes pertaining to the main settings in Participants Database. It is a work-in-progress, new notes are added as needed.

General Settings

File Upload Location

This establishes the path to all file, CSV and image uploads for the plugin. By default, the plugin places all uploaded files in the path (base path)/wp-content/uploads/participants-database/ with (base path) indicating the directory where the mail WordPress directories, such as wp-content, wp-admin, etc. are found. This gives you a lot of flexibility in placing the files in your setup. In most cases, the default location is a good one to use.

Signup Form Settings

Record Form Settings

List Display Settings

Admin Settings

Advanced Settings

CSV Imports in the Background

When this is enabled, data that is imported with a CSV file is processed and saved to the database in the background. What this means is that after the file is uploaded, the page is reloaded and you can close the page or go to other pages while the data is being processed.

This setting is enabled by default. This setting allows for much larger imports because the data waits in a queue, allowing the server to do other things at the same time…basically, it allows the server to multitask and so it doesn’t matter how much data is getting imported, it keeps working on the queue until it is finished. When you refresh the CSV Import page, a progress report will be displayed.

Please note: server caching can prevent background imports from working. If you have problems with background imports, you may need to adjust your server caching configuration to get things working. This specifically applies to “object” or “database” caching because the queue is kept in the options table.

If your imports are pretty small you may prefer to disable this so the import happens immediately. Also, in cases where it proves impossible to get background processing to work, this setting provides a workaround.

Another reason background imports are better is if you are using calculated fields or add-ons such as Participant Log or Directory Tools, there is a lot more processing to be done for each record as it is imported. This means it takes more time to import data, and if you’ve got background imports disabled and the import is too much to handle on a single page refresh, the operation will time out, causing problems such as an overloaded server and lost data.

This setting does not override php file size limits. Your server’s php configuration will set a limit to the size of file that may be uploaded. If you need to upload files that are larger than the php configuration allows, you can in most cases change the configuration to allow it. Ask your hosting provider about this if you don’t know how to do this yourself.

Use the Private ID for the Single Record Link

This setting enables the use of the Private ID in single record links. When this is enabled, all single record links presented by the plugin will use the ?pid={private_id} format to open the record on a page with the [pdb_single] shortcode on it.

When this setting is active, the normal numeric ID links with the format ?pdb={record_id} will no longer work.

This setting can prevent users from viewing records by guessing the ID.

Be careful with this setting: it is important to understand that the Private ID value used here is the same for opening a record for editing on a page with the [pdb_record] shortcode, so it will be necessary to think about how this might expose records to editing by unauthorized persons.

Strict Date Format

This setting forces users to use a specific date format when inputting dates. For most sites this is not needed, by default the date parser can deal with a wide range of date formats.

If you are in a locality where a commonly used date format is not parsed correctly, or if there is some special type of format you want your users to use, it may help to use this setting so that format can be correctly parsed.

This setting will affect all “Date” fields used by Participants Database, including fields that use the Datepicker extension.

Input Date Format

When using “Strict Date Format,” this defines the format that users must use when entering a date. This setting must be a valid php date format string. (Click the link for a full explanation of the format.) This is the same type of format string that is used by WordPress in its date formatting settings.

It is advised that you give the user specific instructions about the format they need to use. You can use the field help text for that.

This setting is only active when “Strict Date Format” is enabled.

Use Cache-Busting Query Variables

Participants Database, like many plugins that generate dynamic content, can sometimes run into problems with caching. The root of the issue is that caching and site accelerators work by serving cached content that is much more rapidly provided than content that is dynamically generated. This works great for things that don’t change a lot, but when dealing with things like form submissions, the content must be generated dynamically.

Caches don’t always know when it’s necessary to generate dynamic content, and this can cause problems. One of the ways that caches can know that the content must be generated dynamically is if there is a “query variable” in the URL.

This setting, when checked, adds a query variable to the return URL from a signup submission, signaling the cache to serve the dynamically-generated content and not cached content.

Use Alternate Session Method

As of Participants Database version 1.8.2, we offer this setting to give site operators an alternative to the use of php session cookies. If php sessions are not working on your site, or you just prefer not to use them, checking this box will invoke the alternate method that does not rely on a cookie.

Common symptoms of sessions not working are signup thanks messages not displayed and receipt emails not going out, issues with multi-page forms, and list search results and pagination using AJAX.

The way this alternate method works is simply that the session ID is passed to the next page in the URL. This will only happen as needed, so most of your site URLs will remain unchanged. The session ID is only valid for a short time, so re-using the URL with the ID will not expose sensitive data.

File and Image Uploads Use WP Content Path

See: #File-Upload-Location

The default base path (the path that the “File Upload Location” setting is aded to) is usually the WordPress root: the directory that contains wp-content, wp-admin, etc. in a standard install. In some cases, a non-standard directory setup is in use and it is more convenient (and sometimes necessary) to use the defined content directory (typically wp-content) as the base for file uploads instead.

To help clarify how this works, by default, the “File Upload Location” setting is wp-content/uploads/participants-database/ If the “File and Image Uploads Use WP Content Path” setting is checked that same setting would need to be uploads/participants-database/ because the new base is wp-content, so it is no longer needed in the path setting.

Note: When you change this setting, you may need to change both the “File Upload Location” and the “Default Image” settings (under the “General” tab) to get the correct path.

It’s best not to change this setting unless you have been unable to get the default setting to work.

Allow Record Timestamps to be Edited

Record timestamps are the “Date Recorded,” “Date Updated,” and “Last Accessed” fields. Normally, these values are set automatically, but you may have a specific need to change them. This setting allows you to change these values.

Remember that you will lose the original values when you change them manually.

Sync php Timezone

This setting sets the php timezone to match the timezone from the WordPress settings. This is helpful in cases where php is reverting to the server’s timezone instead of using the timezone set in the WordPress timezone setting. Uncheck this to let php determine the timezone.

This setting will only affect user-created “date” type fields, it does not affect the timezone used for record timestamps.

See: Date Shifting and Other Timezone-related Issues in Participants Database

Record Timestamps Use Local Time Zone

Select this to use the timezone set in the WordPress settings for your site when setting a timestamp on a Participants Database record. Record timestamps include “Date Recorded,” “Date Updated,” and “Last Accessed” fields of the record. User-defined date fields are not affected by this setting.

This setting is unchecked by default, and when unchecked, the record timestamps will be set using the normal UTC (or GMT) timezone.

Enable Debugging

Selecting this will enable plugin debugging messages to be written to the plugin debugging log. While this is enabled (not “off”), there will be a “Debugging Log” item in the admin menu where you can see the debugging statements.

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

Debug logging will also be enabled if the site-wide WP_DEBUG constant is set.

It is a good idea, for reasons of performance and security, to leave this in the “off” position unless you are actively trying to solve a problem.

Custom CSS