Locations

A fieldset's Locations tab decides where its fields appear. Without a Location, a fieldset exists but shows up nowhere.

Location types

Add a Location and pick what it targets:

• Post Type: the edit screen of every entry of the selected post types.
• Taxonomy: the add and edit screens of terms in the selected taxonomies.
• User: user profiles, Edit User and Add User. A User location always applies to every user; narrow it with a User role condition (below).
• Option Page: the selected option pages.

An empty selection means nowhere, not everywhere. A Post Type Location with no post types selected never matches anything, and neither does an empty Taxonomy Location.

A fieldset can have several Locations. It appears wherever any of them matches, so "Books, and also user profiles" is two Locations.

Targeting conditions

Each Location can carry Show if or Hide if conditions, so the fieldset appears only on some entries instead of every entry of a type. Choose whether all of a Location's conditions must match, or any one of them.

Location type	Conditions
Post Type	Post status, Taxonomy term, Specific post, Parent post, Hierarchy (front page, posts page, top-level, has a parent, has children), Template
Taxonomy	Specific term, Parent term
User	User role, Specific user
All types	Viewer role, Viewer capability: who is doing the editing, not what is being edited

For example: show "Book notes" only on books in the Mystery term, or show "Staff profile" only on users with the Editor role.

Conditions that work on every site

A theme's fieldsets travel to every site that uses the theme, but post and term IDs don't: page 12 on one site is a different page, or no page, on the next. A Mystery term you create locally and again on the live site gets a different ID on each. These conditions match without an ID:

• Template matches the page template the entry uses, such as an About template. The template belongs to the theme, so it means the same thing on every site. Default template matches entries that don't use one.
• Specific post and Parent post can match By slug instead of By post. A slug like about matches the post with that slug. A path like company/about matches that one child page.
• Taxonomy term, Specific term and Parent term can match By slug instead of By term. A slug like mystery matches the term with that slug in the condition's taxonomy, on any site where the term exists.

A condition that matches by slug ignores any IDs it also has. Conditions set to By post or By term keep matching by ID.

Conditions are checked when the edit screen loads. If a condition depends on something the editor changes on that screen, such as the post status or a term, the fieldset appears or disappears the next time the screen loads.

Viewer role and Viewer capability decide who sees a fieldset on the edit screen. They don't hide its values from your theme: $post->field() and dynamic data return the same values to a signed-out visitor as to an administrator.

REST responses still apply viewer conditions, for the user making the request.

Note

Use conditions to decide which entries get a fieldset. To show or hide one field based on another field's value, use conditional logic.

Order

When several fieldsets appear on the same screen, each Location's Order decides their sequence. Lower numbers come first.

Targets VX doesn't manage

You can target any post type or taxonomy WordPress knows about, including ones other plugins registered, such as WooCommerce products. You don't need to manage it first. Managing a post type is about its settings; a fieldset only adds data to it.

When both kinds exist, the target picker groups them under Managed with VX and Other post types (or Other taxonomies). WordPress's internal system types, such as templates and navigation menus, aren't offered.

Fields on the Media post type (attachment) appear on the full Edit Media screen, not in the media library pop-up inside the editor.

When a target disappears

If a target is deleted later, for example a post type this fieldset points at, the Location keeps the missing key and shows it as an unknown reference, so you can retarget or remove it.

Locations and field keys

Two fieldsets that share a target store their values in the same place, so their top-level field keys must not collide. Fieldsets on different post types can both have a price field; two fieldsets on Books can't. All User Locations count as one shared target, because user values are stored per user, not per role.

While you edit Locations, the editor lists any overlapping keys, with links to the field and to the other fieldset. Save stays disabled until the overlap is resolved. See Field key conflicts.

If a fieldset does not appear

Check, in order: the fieldset is Active; the Location targets the right post type or taxonomy and isn't empty; any conditions match this entry; and you are signed in as a user who can see VX fields (see Editing content).

Technical details for LLMs

• Shape: location.groups[], each { object, targets[], order?, advanced_enabled?, advanced_action: "show"|"hide", advanced_group_match: "all"|"any", conditions[]: { source, operator, value } }. Groups are OR'd. order is clamped to 0–999 and falls back to the fieldset's order (default 10). On a screen matched by several groups, the lowest order wins.
• Objects: post_type, taxonomy, user (targets ignored). Empty targets on anything but user matches nothing.
• Condition sources → operators: post_status, specific_post, post_parent, page_type (front_page, posts_page, top_level, has_parent, has_children), page_template → is_any_of / is_none_of; taxonomy_term → contains_any / contains_all / is_none_of; specific_term, term_parent → is_any_of / is_none_of; user_role, specific_user → is_any_of / is_none_of; viewer_role → is_any_of / is_none_of; viewer_capability → contains_any / contains_all / is_none_of.
• specific_post / post_parent value: { post_type, ids: [] }, or { post_type, slugs: [] } for config that has to work on more than one site. With slugs, ids are ignored (and dropped on save). A slug with / is a page path compared against the full path; a plain slug is compared against the post's own slug; post_type must match.
• taxonomy_term value: { taxonomy, terms: [] } (term ids), or { taxonomy, slugs: [] }, compared against the slugs of the post's terms in taxonomy. With slugs, terms are ignored (and dropped on save).
• specific_term / term_parent value: { taxonomy, ids: [] }, or { taxonomy, slugs: [] }. With slugs, ids are ignored (and dropped on save); the term's (or parent's) taxonomy must equal taxonomy.
• page_template value: template names as the theme gives them, a file (templates/about.php) or a block template slug; default for no template. Assign one with vx-framework/create-post / vx-framework/update-post template.
• A condition that can't be evaluated for the current entity fails the group.
• Viewer conditions (scope: viewer) are checked against the current user in the editor, on save and in the content abilities. Value reads ($post->field(), $term->field(), $user->field()) skip them: each one answers as some user would (true in a show group, false in a hide group), so the result doesn't depend on who is viewing.
• Extension filters: vxframework/fieldsets/location_objects, location_sources, location_operators, location_condition_match, location_group_match.
• Before adding a location, check for key overlaps with vx-framework/get-object-fields on the target.