Where fields appear

Who sees VX fields

On posts, terms and user profiles, VX fields appear only for users who can manage options, which by default means administrators. Other roles still edit everything WordPress provides (title, content, featured image, categories), but not VX fields.

Option pages are different: each page has its own Capability, so you can let Editors update an option page without making them administrators. See Creating an option page.

In the block editor

A VX button in the editor's top bar, next to Options, opens the VX panel on the right side of the screen. Every fieldset that applies to the post is in it.

• The panel's starting width comes from the post type's Default Sidebar width (Default, Medium or Wide). In the panel's menu you can change the width and choose whether it opens by default, for that post type.
• Values are written to the post as you type, so blocks bound to them with dynamic tags update in the preview straight away.
• WordPress's own Save and Publish buttons save the fields. The panel doesn't need to be open.
• WordPress's pre-publish checks use the same side of the screen, so the VX panel closes while they're open.

If a fieldset has a Taxonomy field set to edit terms inside VX, WordPress's own panel for that taxonomy is hidden, so there's one place to choose terms.

In the classic editor

When a post type uses the classic editor, the same form appears in a Fieldsets box below the content. Dynamic tags, data loops and visibility rules are block editor features, so they aren't available there.

On terms

Fields appear on both the Add New form and the term's edit screen.

When you add a term, WordPress creates it first and VX saves the fields right after. If the fields can't be saved, the term still exists. A notice explains what happened and links to the term's edit screen so you can finish there.

On user profiles

Fields appear on Profile, Edit User and Add New User.

On Add New User, only the fieldsets that apply to the selected Role are shown. Switching roles updates the form; anything you already typed is kept if you switch back. Only the fieldsets that match the role you submit are saved.

On option pages

The option page shows its fieldsets as a form with its own Save button. Nothing is saved until you click it.

Fields that aren't there

If a field you expect isn't showing, check the fieldset is active and its Locations match, that the field isn't hidden by conditional logic, and that you're signed in with a role that can see VX fields.

Technical details for LLMs

• Capability gate: the post (block + classic), term and user editor integrations return early unless current_user_can( 'manage_options' ).
• Post types: any registered post type with at least one active matching fieldset gets the panel. VX doesn't need to manage the post type.
• Block editor: values sync to post meta through the editor store as they change; WordPress's save persists them. Empty values aren't written as meta rows on save.
• WordPress REST API: the field meta is registered for context=edit only, which WordPress serves to users who can edit the post. A visitor's /wp/v2/<type>/<id> response carries no field values. Filter vxframework/fieldsets/meta_rest_contexts to change the contexts.
• Taxonomy field with backend_edit_mode: "custom_field" hides the native taxonomy panel; native_metabox keeps WordPress's box and VX skips the field on post saves.
• Add New User: fieldsets are filtered by the chosen role through the user_role Location condition.
• Read or write the same values without a screen: vx-framework/get-post-values / vx-framework/set-post-values, vx-framework/get-term-values / vx-framework/set-term-values, vx-framework/get-user-values / vx-framework/set-user-values.