Data

Relations (Blocks)

Relations connect your content types to each other — Projects to Clients, Courses to Instructors — so related items travel together and can be displayed from either side. Connections are stored in a dedicated, indexed table rather than scattered post meta, which keeps look-ups fast in both directions. Where: WP Admin → Tiger Blocks → Data […]

2 min read Updated July 14, 2026

Relations connect your content types to each other — Projects to Clients, Courses to Instructors — so related items travel together and can be displayed from either side. Connections are stored in a dedicated, indexed table rather than scattered post meta, which keeps look-ups fast in both directions.

Where: WP Admin → Tiger BlocksDataRelations. Enable the engine under Modules & WidgetsDynamic Content.

Define a relationship

  1. Give the relation a name and slug.
  2. Pick the two sides — a “from” (parent) object type and a “to” (child) object type. Sides can be post types, users, taxonomy terms or Custom Content Types.
  3. Choose the cardinality: one-to-one, one-to-many or many-to-many.

Editors then attach related items right in the editor through a relation meta box, and the connection is bi-directional — set it once from either end.

Display related items

Pull a record’s related items into your layout with a saved Query using the Related items source — a client page listing its projects, a project showing its client — without manual linking. Because the store is a real relational table with manual ordering columns on both sides, you can order children under a parent (and parents under a child) and support true many-to-many without serialized-array bottlenecks.

Kept tidy automatically

When a connected object is deleted — a post, user or term — its rows in the relations table are purged, scoped to that object’s type so IDs cannot collide across object types.

Troubleshooting

Related items are not appearing on the front end

Display happens through a Query, not the meta box alone. Create a query with the Related items source that points at your relation, then place a dynamic block (Dynamic Loop or AJAX Grid) that uses it on a singular template where there is a current item to traverse from.

Should I use a Relation or a shared category?

Model real associations (this project belongs to this client) as a Relation rather than a shared taxonomy term. Relations keep queries precise and content easy to maintain, whereas categories mix unrelated items that merely share a label.

Still stuck?

We’re here to help

Can’t find what you’re looking for, or hit something that looks like a bug? Reach the support team or ask the community.