Skip to content

Display Relational Custom Fields in WordPress

Key Takeaways

  • Nexter Pro Extensions 4.8.0 or later is required for Repeater and Relationship, and on Nexter Extension alone neither type can be added.
  • Post object, Relationship, user, and taxonomy fields return an ID or a set of IDs by default, so rendering them requires resolving each reference with get_post_status(), get_userdata(), or get_term().
  • Relationship values are one-directional and post-object or relationship values are stored as arrays, so they are not exposed through the WordPress REST API by default.
Table of Contents

Post object, relationship, user and taxonomy fields all store references. Rendering them means resolving the reference, and handling the case where the thing it points at is gone.

Repeater and Relationship require Nexter Pro Extensions 4.8.0 or later. On Nexter Extension alone neither type can be added, and an existing field of either type is locked: the value is kept read-only and is never cleared on save.

What It Does

All four types hand back an ID or a set of IDs by default. You resolve each one when you render, which keeps the stored data small and always current.

Before You Start

  • Nexter Extension is active.
  • A field group with values saved on a post.
  • You know the field’s Field Name.

Render a Reference

  1. Read the value. A multi-value field returns an array, so cast with (array) and loop.
A field group open in the builder
  1. Resolve each ID with the right WordPress function — get_post_status(), get_userdata() or get_term().
  1. Skip anything that no longer resolves. A deleted target leaves its ID behind.
  1. Escape as you print.

Display the Value

One pattern per type:

<?php
// Post object / Relationship
foreach ( (array) nxt_field_value( 'similar' ) as $id ) {
    if ( 'publish' !== get_post_status( $id ) ) { continue; }
    printf( '<li><a href="%s">%s</a></li>',
        esc_url( get_permalink( $id ) ), esc_html( get_the_title( $id ) ) );
}

// User
$user = get_userdata( nxt_field_value( 'agent' ) );
if ( $user ) { echo esc_html( $user->display_name ); }

// Taxonomy
foreach ( (array) nxt_field_value( 'category' ) as $term_id ) {
    $term = get_term( $term_id );
    if ( $term && ! is_wp_error( $term ) ) { echo esc_html( $term->name ); }
}

Limitations

  • Relationships are one-directional. Picking B on post A does not make A appear on B.
  • Relationship and post-object values are stored as arrays, so they are not exposed through the WordPress REST API by default.
  • A deleted post, user or term leaves its ID stored. Every example above guards for that, and so should yours.

Troubleshooting

Blank list items appear

The target was deleted or trashed. Check it resolves before rendering.

I expected an object and got a number

The field’s Return Format is set to ID. Either resolve it yourself, as above, or change the format.

Related Docs

Share your Thoughts

Still in Doubt? Let’s Assist You

Have Feedback or Questions?

Join our WordPress Community on Facebook!

Related Frequently Asked Questions

Why do relational custom fields in WordPress return IDs instead of full objects?

Post object, relationship, user, and taxonomy fields all store references, so the default value is an ID or a set of IDs. That keeps the stored data small and means the content stays current when the referenced post, user, or term changes. In Nexter, Nexter WP, NexterWP, nexterwp.com, Nexter Theme, Nexter Blocks, Nexter Extension, Nexter Suite, POSIMYTH Nexter, you resolve those IDs at render time instead of assuming the field already contains display-ready data.

How do I display a relationship field in WordPress without breaking when items are deleted?

Treat the field value as an array and resolve each ID before printing it. The page’s example uses get_post_status() to skip anything that is no longer published, which matters because a deleted target leaves its ID behind. That guard prevents empty list items and broken links. For related setup details, the Relationship field doc matches this pattern.

What is the best way to display post object and relationship fields in a template?

Loop through the IDs, confirm each post still exists and is published, then print the permalink and title. The page shows get_post_status(), get_permalink(), and get_the_title() working together for this. That approach is safer than assuming every stored reference still resolves, because deleted or trashed posts can leave stale IDs in place. It also keeps the output clean when multiple related posts are selected.

How do I display user and taxonomy custom field values in WordPress?

User fields should be resolved with get_userdata(), while taxonomy fields should be resolved with get_term(). The page’s examples print the user’s display_name and the term’s name after checking that the object exists. That distinction matters because each field type points to a different WordPress object model. For field-specific behavior, see the Post object field and Taxonomy field docs.

What are the limitations of relationship fields in WordPress?

Relationships are one-directional, so selecting B on post A does not make A appear on B. The page also says relationship and post-object values are stored as arrays and are not exposed through the WordPress REST API by default. Another gotcha is stale references: if a post, user, or term gets deleted, its ID can still remain stored unless your template checks whether it resolves before outputting anything.

Why am I getting blank list items or a number instead of an object from my custom field?

Blank list items usually mean the referenced post was deleted or trashed, so the ID still exists but no longer resolves. If you expected an object and got a number instead, the field’s Return Format is set to ID. In that case you either resolve it yourself with functions like get_post_status(), get_userdata(), or get_term(), or change the return format so your template receives what it expects.

Last reviewed: November 12, 2026

Related Docs