Managing fieldsets

The Fieldsets screen lists every fieldset on the site. This page covers the list and the fieldset-level settings. Adding and configuring fields is covered in Fields.

Finding a fieldset

Three filters work together:

• All, Active or Inactive.
• A search by label.
• A location: a specific post type, taxonomy, Users, or Unassigned.

The location filter shows fieldsets whose Locations target that place. It ignores targeting conditions, so it answers "is this fieldset assigned here?" rather than "would it show on this particular entry?". Unassigned lists fieldsets that appear nowhere: no Locations, or only Locations with nothing selected.

Long lists load 30 at a time. Search and filters always cover every fieldset; Load more reveals further matches, and Select all includes matches that aren't on screen yet.

The fieldset key

When you create a fieldset you give it a label and a key. The label can change any time. The key can't: it's the fieldset's permanent identifier, used when you export it, define it in code, or refer to it from an AI assistant.

• Up to 64 characters: lowercase letters, numbers, hyphens and underscores.
• core is reserved.

General settings

The General tab holds the settings that apply to the fieldset as a whole:

• Label, Icon and Accent color: how the fieldset is labeled and colored in the editor panel and the dashboard.
• Display field description as: show each field's description as a Tooltip next to its label, or Inline below it.
• REST API default field access: the access level for fields in this fieldset that are set to inherit it. It defaults to Private. See Access tiers.

Active and inactive

An inactive fieldset:

• doesn't appear anywhere, even though its Locations are kept
• keeps all its configuration and every value editors have saved
• is left out of field key conflict checks

Deactivating is the safe way to take a fieldset out of use without losing anything. Activate it again and everything comes back.

Duplicating

A duplicate gets a new fieldset key and starts with no Locations, so it appears nowhere until you assign one. Field keys are copied unchanged.

That's safe because field keys only need to be unique among fieldsets that share a Location. Once you give the copy a Location that overlaps the original, the editor flags every repeated key so you can rename it or choose a different target.

If you want the same fields in two fieldsets, don't duplicate them. Use a Clone field, which stays in sync with its source.

Deleting

Deleting a fieldset removes its configuration: fields, Locations and settings. It doesn't delete the values editors saved. Those values stay in the database, and Meta Watch lists them as leftovers you can keep or delete for good.

If you might want the fieldset back, download it from its Revisions tab first.

Technical details for LLMs

• Fieldset config keys: label, icon, accent_color, description_display (tooltip | inline), order (0–999, default 10; the fallback sort order for Location groups without their own), active (bool, default true), fields, location.groups.
• Key rules: ^[a-z0-9_-]+$, max 64, not core, unique among fieldsets.
• Abilities: vx-framework/list-fieldsets, vx-framework/get-fieldset (returns the config_hash field writes guard on), vx-framework/create-fieldset, vx-framework/update-fieldset, vx-framework/duplicate-fieldset, vx-framework/delete-fieldset. Field-level changes go through vx-framework/add-fields, vx-framework/update-field, vx-framework/delete-fields, vx-framework/reorder-fields and vx-framework/move-fields. vx-framework/update-fieldset with config.fields replaces the whole array, so a field left out is deleted.
• Delete: config only. Stored meta stays and shows as Meta Watch leftovers (vx-framework/list-field-migrations).