Post Relation and User Relation

Pro

A relation links two things so that both sides know about it. Add a Writer to a Book's "Writers", and the Writer's "Books" list includes that book, without anyone editing the Writer. Post Relation links posts; User Relation links users, such as the shop managers.

Pairing two fields

A two-way relation is two fields, one on each side, that share a Relation key:

• On the Book fieldset: a Post Relation "Writers", relation type Has many, relation key book_writers, post type Writer.
• On the Writer fieldset: a Post Relation "Books", relation type Belongs to many, the same key book_writers, post type Book.

Edits from either side update the same connection. Leave the relation key empty and it defaults to the field key.

Right under the key, a panel lists every field using it and flags problems: a matching partner gets a green check; two fields pointing the same direction, mismatched post types, or more than two fields on one key get a warning. The panel reads your saved fieldsets, so save to refresh it. It only warns; it never blocks saving.

A relation field without a partner still works as a one-sided link, like Select Post, but stored in the relations table.

Relation types

Type	This side is…	Holds
Has one	the parent	one linked item
Has many	the parent	an ordered list
Belongs to one	the child	one linked item
Belongs to many	the child	an ordered list

A pair is one has side and one belongs to side. "One" sides are enforced everywhere, in the picker, on save and over the REST API, so they never hold more than one item.

Reassignment

Because the connection is shared, a "one" side can be filled from the other end. If you link an entry whose "one" side is already taken, the older link is moved to the new entry automatically.

For example, with Book has one featured writer paired with Writer belongs to one featured book: if Writer A is featured on Book 1, and you open Writer A and set their featured book to Book 2, Writer A moves from Book 1 to Book 2, and Book 1 no longer has a featured writer.

Warning

Reassignment happens without a prompt, and the only way back is to link the item again. It only affects the "one" side of a relation.

Order

Relations keep the order editors drag items into, and that order is used everywhere they're read. When both sides are "many", the two sides share one order: reordering from one side changes the order seen from the other.

Limits

• Relation fields are always top-level. They can't go inside a Group, Repeater, Field Table or Content sections.
• Post types (or Roles) with nothing selected offers nothing to pick.
• An option page can be the "has" side of a relation, but never the "belongs to" side. A belongs-to relation on an option page is skipped on save with a warning.
• Every save re-checks links against the field's post types, statuses, author scope, roles and your access, and silently drops anything that doesn't fit, just like Select Post.

Technical details for LLMs

• Type keys: post_relation, user_relation (Pro). Settings: relation_type (has_one | belongs_to_one | has_many | belongs_to_many, default has_many), relation_key (^[a-z0-9_-]*$, max 96, default = field key), exclude_self (post: default true; user: false), min_count (advisory), max_count (enforced). Post: post_types, post_status, author_scope, authors. User: roles, capability.
• Storage: the {prefix}vx_relations table (relation_table strategy), not meta. Stored order = submitted order; many-to-many order is shared by both ends.
• Writes: vx-framework/set-post-values / vx-framework/set-user-values with id arrays, or vx-framework/create-relation / vx-framework/delete-relation for one edge. has_one / belongs_to_one cap at one id; claiming a paired single side steals the edge from its previous owner (warn before doing it).
• Renaming a relation key is tracked by Meta Watch as a relation-key move.
• VX Script / Bricks: relation paths traverse into linked objects and are loopable.