Description

This is a full list of available parameters for Piklist fields. Not all parameters work with all fields.

Piklist allows you to turn ANY field, or group of fields, into a repeater field, by simple adding the add_more parameter.

Displaying Data
To display the results of the Add-More in your theme, pull the data like you normally would. Add more’s save data as an array, so you can loop though the data to display.

Adds HTML attributes to your field.

Set the use capabilities that will see this field.

Create a list of choices. Used with the following fields: checkbox, radio, select.

Piklist uses a 12 column grid system to help you layout your fields. The grid system is really helpful when laying out group fields.

Set conditions for your fields.

The description of your field.

The name of your field. This is the name that will be saved to your database.

Adds tooltip help to your field. This will only display if a label is set for your field.

The label for your field.

Display a list field (Checkbox, Radio or Select) as a vertical list or not. True is vertical.

Show field to only logged in users.

Lock the field value when your post is in a certain post status. A range of post statuses can be used by separating them with two hyphens (–).

Only used for Post data.
on_post_status is now part of the conditions array: post_status_hide, post_status_value

Allow this field to relate to a post type, user, comment or taxonomy.

Make a field required. If this field is not filled in the form will not save.

NOTE:
Piklist uses server-side authentication instead of browser-side authentication to do required verification. The pro is that it’s more secure, the con is that the user has to press “save” before the validation kicks in.

If you want the convience of browser-side verification you could add the HTML5 “required” attribute as well. See example below.

Untrusted data entered into your form should be sanitized and validated before saving. By default Piklist uses the WordPress $wpdb->prepare method to handle your data, insuring it is SQL-escaped before saving to prevent against SQL injection attacks.

Piklist also adds another level of sanitization you can use at the field level, and makes it easy to use. A library of sanitization functions are included with Piklist, or you can create your own.

NOTE: Piklist comes with a library of built-in sanitization functions.

Since data sanitization depends on the type of data and the context in which it is used, the sanitize parameter allows you to choose how to clean your data, and accepts the following parameters:

The scope parameter tells Piklist where to save field data. In many cases this is the WordPress database table (i.e. post, post_meta)

When creating fields for the WordPress admin, in most cases, you do not have to define scope. Piklist will automatically set it for you.

You MUST define scope when creating front-end forms.

Piklist allows you to mix-and-match field types within a form. So, one form can have fields that save information as post_meta, while other fields save to a taxonomy. Scope is what determines where the field data is saved. If you don’t set the scope parameter then it will default to where the field is used. For example, if you are creating a metabox, then scope will automatically be set to post_meta. When working with front-end forms, you must set the scope for each field, so Piklist knows where to save your data.

If you want create a field that saves the post_title, then you would set scope to post, since the post_title field is in the wp_posts database table.

If set to false, will stop an add_more field from being sortable.

Define a field template.

The type of field.

Validate this field with a set of validation rules.

The default value for this field.