Add and arrange fields
6 min read
The Fields section of the field group editor is the field builder. Each field is one row; each row becomes one column in the group's table (a few types add extra helper columns, see the column counter below).
Add a field
- Open the group (or click Add field group) and go to Fields.
- Click Add field. A new row appears.
- Type a Field label. The Field key (SQL column name) is filled from the label as a lowercase slug (
Sale pricebecomessale_price) until you edit the key yourself. - Pick the type in the third column. The picker lists every type; types that need a higher plan are shown disabled. For what each type stores and shows, see Field types.
- Open Advanced options (the button at the end of the row) for the choices, settings and the other tabs described in Field settings: general, validation and SQL column.
- Click Create field group or Save changes.
A row with problems is outlined in red and shows the message under the input: Each field must have a label., Field "..." is missing a key., This key is used more than once. Keys must be unique., Add at least one choice.
New rows have a highlighted border; rows you changed but did not save have another. Click the Revert changes button on a changed row to put it back to its saved state. Discard new field removes a row that was never saved.
Field keys
The key is the column name. It is what you pass to wpmcf_get_field() and what you use in wpmcf_query conditions.
Rule | Detail |
|---|---|
Characters | Start with a letter; lowercase letters, numbers and single underscores. The input removes other characters as you type. |
Length | Up to 63 characters (less for types that add helper columns). |
Unique | Keys must be unique inside the group, and inside a Group or Repeater field among its own sub-fields. |
No double underscore |
|
Reserved words | SQL reserved words ( |
Rename a field
You can change the key of a saved field. The row shows the warning Key rename will run SQL RENAME COLUMN. On save the column is renamed in place and its values are kept; indexes on the field follow the new name. A rename that also changes other column settings runs as one CHANGE COLUMN. Code and templates that used the old key must be updated; the plugin does not rewrite them.
You cannot give a name to another field in the same save if a renamed field gives that name up (swapping names). The message is The name "x" is being given up by a renamed field in the same save. Save the rename first, then use the name again. Save the first rename, then reuse the name.
Change the type of a field
Pick another type in the row. If the conversion is safe (for example Text to Text area) nothing special happens. If it could lose data (for example Text to Number) the dialog This type change can lose data opens. It explains the risk and offers three buttons:
Button | What it does |
|---|---|
Cancel | Keeps the current type. |
Convert with a backup | Copies the old values into a backup column named |
Create a new field instead | Adds a new field and leaves the old one untouched. Recommended when the old values must stay exactly as they are. |
Details are in Changing a field group safely.
Changing the type also removes what the new type cannot use: an index on a type that cannot be indexed, a column type override that the new type does not allow, a SQL function it does not support, and settings it does not know (choices survive moves between Select, Radio buttons and Checkboxes).
Reorder fields
- Drag a row by its handle and drop it where you want it (a Drop here marker shows the target).
- Or focus the handle (
Move {field} (arrow up or down)) and press the up or down arrow key. A live message announces the new position.
The order of the rows is the order on the edit screen. Reordering does not change the table (column order in the table stays as it was).
Group and Repeater fields hold their own sub-fields: use the + Add field to "..." button inside them, and drag sub-fields between the root list and the container. Tab and Accordion fields are layout markers: the fields after them (until the next marker) belong to that tab or accordion section, and the bar above the row says what the section holds. Layout fields store nothing, so they have no column, Required, index, default or SQL options.
Remove a field
Click the trash button (Remove field) on the row and save.
See Table health.
If you later add a new field with the same key as the leftover column, the editor asks whether the new field should use the old values or start empty. See Changing a field group safely.
Column counter and limits
The Fields section header shows N / 100 columns. Every field that stores a value uses a column; a few types add helper columns (for example Map stores latitude and longitude next to the value), and those count too.
Columns | What happens |
|---|---|
40 or more | A warning: |
100 | The limit. Add field is replaced by |
A Group field stores all its sub-fields in a single JSON column, so it counts as one. The trade-off: values inside a Group are not individually indexed, but you can still query them with a path such as group_key.field.sub_field (see Query posts by field value).
Fields with an unavailable type
If a field's type is not available (for example a Gallery field after a Pro license ended, or a type from a plugin that is deactivated) the row is read-only and shows Gallery fields are not included in your plan or Unknown field type "x". Its settings and stored values are kept; you can still save the group. Editing it again becomes possible when the type is available again.
Troubleshooting
Problem | Fix |
|---|---|
I cannot find the key field of a saved group | The group key is fixed. Only field keys can be renamed. |
| The type is not registered (a typo through the API, or an add-on is off). |
| The type needs Pro. |
| Types with helper columns need a shorter key. |
Still stuck? Contact support