Adding and arranging fields
Twenty-three field types, from a text box to a delete-account button — and the validation rules that decide what a member may type.
- Beginner
- 8 min read
- Applies to 2.0
Adding a field
Pick a type from the palette and it is appended to the current section. Drag to reorder, and set a width per field so two short ones can share a row.
The field palette on the left and the field list with its drag handles.
The field types
Text and numbers — Text Input, Textarea, Number, Phone, URL, Email.
Choices — Select / Dropdown, Checkbox, Radio Buttons, Toggle / Switch.
Pickers — Date Picker, Time Picker, Color Picker.
Uploads — File Upload, Image Upload.
Hidden — Hidden Field, for a value the member never sees.
Layout pieces — Heading, Divider, HTML Block. These display something; they collect nothing.
Account components — Profile Picture, Change Password, Delete Account, Two-Factor Authentication. Each is a complete, self-contained feature rather than an input: drop Change Password on the Settings flow and the member gets a working password change, with no wiring on your side.
Delete Account does what it says, permanently, after a confirmation. Put it on the Settings flow if you need it, and think about whether you want it on the Dashboard where somebody might reach it by accident.
Two-Factor Authentication
The enrolment wizard for an authenticator app, on the member's own page: a QR code to scan, one code to confirm it, and the ten backup codes that follow. Until this component existed, that wizard lived only on the WordPress profile screen — the screen a membership site keeps its members out of — so the app could be demanded at sign-in of people who had no way to pair one. See Authenticator app sign-in.
Two switches:
- Backup codes — show them at enrolment, and let the member issue a fresh set later. Leave it on unless you have another way to let someone back in after a lost phone; they are the only one the plugin offers.
- Allow turning it off — off makes the pairing one-way from the member's side. They can still be unpaired by an administrator.
Dropping this on a flow does not enable two-factor anywhere. What is asked for at sign-in is decided under Security → Two-factor; this component is only where a member arranges to be able to answer it.
Validation rules
Each input field can carry rules. Nine are enforced:
| Rule | What it checks |
|---|---|
| Required | something was entered |
| Min length / Max length | number of characters |
| the value looks like an email address | |
| Pattern | the value matches a regular expression |
| Min value / Max value | numeric bounds |
| Min date / Max date | date bounds |
Every rule takes an optional message. Write one — the defaults are correct but impersonal, and "Please enter your member number, which is on your card" is worth more than "Invalid value".
Rules are enforced on the server, so a member cannot get round them by editing the page. Three of them — min length, max length and pattern — are also placed on the HTML input, so the browser catches the mistake before the form is even sent. The numeric and date bounds are checked server-side only.
There is a tenth rule in the interface, file size, which applies to uploads and is checked when the file arrives rather than as you type.
Coming from version 1.x? The rules could be set on every field and were enforced on none of them: a required field submitted empty went straight through. They are applied in 2.0. If you had set rules long ago and built around them being ignored, check your flows — a form that used to save will now stop and ask.
Default values from tokens
A field's default can be a token rather than a fixed string, written
{source:key:fallback}:
| Source | Reads from |
|---|---|
user | the signed-in member — {user:first_name}, and dotted notation for values inside an array |
option | a WordPress option |
site | site information, such as the name or URL |
request | the query string, for prefilling from a link |
The fallback after the second colon is used when the lookup finds nothing, so
{user:company:—} never leaves an awkward blank.
Conditional fields
A field can be shown only when another field has a particular value. The condition is evaluated in the browser as the member fills the form, so a section appears and disappears as they answer.
Use it to keep a long form short. Do not use it to hide a required field, which leaves a member unable to submit and unable to see why.
What comes next
Something missing or out of date? Tell support.