Custom Fields Not Displaying — Causes and Solutions for Block Themes

When custom field values do not appear, there are two likely bottlenecks: either the input field does not appear on the edit screen, or the value is saved but does not appear on the published page. Starting with this troubleshooting step, this article compares three methods for displaying values in block themes across three criteria: "will it disappear upon updates?", "is it resilient after handoff?", and "can it be brought into client projects regarding licensing?". The goal is to enable you to decide which one you should choose for your own project. The specifications in the main text are current as of September 2026 (The latest version of WordPress is 7.1.2）。

First isolate the issue — Two causes for custom fields not displaying

"Not displayed" conflates two different states. Since the troubleshooting steps differ as well, please clarify which one it is first.

I cannot find the custom field section on the edit screen.

In the Block Editor, custom field input fields are hidden by default. According to the official WordPress documentation, Assign custom fields explains that it is hidden by default if it has never been used. The procedure to display it consists of the following 4 steps.

1. Press the "Options" button (three-dot icon) on the toolbar in the upper right corner of the screen.
2. Select "Preferences"
3. Turn on "Custom Fields" in the "Details" section of the "General" tab
4. Click the "Enable and reload" button

Since this operation will reload the page, please be advised to save your changes to the document before switching. After switching, the input field will appear at the bottom of the editor.

What you need to keep in mind isThis is merely an editor display settingis. Even if you turn it on, the appearance of the public page will not change. If you cannot find the "Screen Options" of the Classic Editor, you can assume that it has been moved to this "Settings" panel side in the Block Editor.

Even though the value is entered, it does not appear on the public page

This is not a configuration issue, but the intended behavior. The same official documentation explains in a separate section that a template tag is required to display each post's custom fields on the public page. In other words, custom fields do not appear on the public page simply by saving them. We need to provide the location for output.

And the location of that placement changes between block themes and classic themes. Block themes build all parts of the site with blocks and edit templates in the site editor. In the official documentation, Block themes states clearly that classic themes do not work in the Site Editor.How the location of customization changes between block themes and classic themesI have organized this in detail in another article. This is why the fix of "adding one line of PHP to the template file" cannot be used as-is. From here on, I will cover the side that does not appear on this public page.

3 ways to display custom fields in block themes

There are roughly three options. Without ranking them here, I will simply list the prerequisites for what needs to be written.

Method A — Block Bindings API (completed with core features only)

It is a WordPress core mechanism that connects block attributes to post meta values.Block Bindings API ReferenceAccording to this, WordPress 6.5 or later is required. Since you specify "Display this post meta value" for paragraph or heading blocks, there is no need to create custom blocks. You only need to do two things: register the post meta and specify it in the markup, and no plugins are required.

Method B — Output using a custom block or shortcode

get_post_meta() This is a method of retrieving values using functions like `get_post_meta()` and outputting them yourself. There are several ways to output them, such as creating a custom dynamic block, registering a shortcode, or creating a block variation. This offers the highest degree of freedom, allowing you to write processing logic such as formatting values or conditionally changing the output. However, it increases the amount of code you have to write and what you need to maintain.

Method C — Use the display function of custom field plugins

Some plugins that manage custom fields come with a feature to display the values on the screen (List of plugin directoriesWhile you often don't need to write code, the output format is specific to that product. Since the assumptions change significantly depending on which one you choose, it is only explained here as a means to an end.

Which one to choose — Comparing across 3 decision criteria

The answer varies depending on the conditions of the case. Instead of committing to just one, I will arrange them along three axes.

Here are the guidelines for choosing:

• If you just want to output the value as literal text, A. If it's for use in inserting into paragraphs, headings, images, and buttons, it keeps dependencies from increasing. The dividing line is whether it fits within the compatibility table described below.
• If you want to process values, combine multiple values, or output them repeatedly, go with B. Requirements that fall outside the scope of A should be moved to B early on, which will result in a shorter process overall.
• If we want to thoroughly build the input-side management screen, and if the license terms fit the project, then C. It is safe to also consider the possibility of removing that plugin in the future.

For long-term operation handover projects, the configuration often settles on a combination of A for display and B only for areas that require processing.

Minimal Steps to Display Custom Fields with the Block Bindings API

There are only two steps. In addition, I could not confirm in the official documentation whether bindings can be configured using only editor screen operations without touching the block's HTML. Therefore, this article explains the method of directly editing the block's HTML.

Step 1: Register the post meta

register_meta() to register post meta. In a plugin or theme, functions.php Please put it here.

register_meta(
	'post',
	'my_custom_field',
	array(
		'show_in_rest' => true,
		'single'       => true,
		'type'         => 'string',
	)
);

show_in_rest is required, and references are also cited as a condition for referencing from the Block Bindings API. If you want to register it only for a specific post type, register_post_meta() I will use.

Step 2: Connect to block attributes

Select the block in the editor, switch to "Edit as HTML" from the options, and into the block comment metadata.bindings I will add. Of the paragraph block content This is an example of connecting to an attribute.

<!-- wp:paragraph {
	"metadata":{
		"bindings":{
			"content":{
				"source":"core/post-meta",
				"args":{"key":"my_custom_field"}
			}
		}
	}
} -->
<p>Text displayed as a fallback</p>
<!-- /wp:paragraph -->

source に core/post-meta、args.key Specify the key from step 1. The text written inside the block will be displayed when the value cannot be retrieved. When placing it in a template, open the target template in the site editor (single for posts) and perform the same operation.

Cases where the Block Bindings API cannot be used and their alternatives

A cannot be used everywhere. Knowing the constraints in advance will help you make a quicker decision to switch to B.

The connectable blocks and their attributes are determined.

As of September 2026, the connection is possible within the following scope (the source is the aforementioned Block Bindings API reference).

The list, table, and cover background images are not included. If you want to output values in places not covered by this table, please consider method B.

The list is WordPress 6.9 and later、block_bindings_supported_attributes The filter can be expanded using filters, but the reference notes that this filter also affects blocks and attributes that can be used with pattern overrides, so if both functions share the same settings, be careful. In sites that use pattern overrides, the settings you expand for one function can also work for the other.

two conditions on the post meta side

core/post-meta There are two conditions for using the show_in_rest => true That it is registered in the system, and that the leading character of the key is not an underscore. The reference is _example_key Such keys are said to be protected and cannot be used._ In existing sites where values are stored with the initial key, A cannot be used as is. You will have to create a new key or switch to method B.

Two points that broaden your options when you know them

• The value can be processed with filters that are 6.7 or higher. Starting with WordPress 6.7,get_value_callback Returns the value of block_bindings_source_value You can process it with the filter. For minor adjustments like changing the date format, you can skip to B without having to switch to it.
• The number of sources other than post meta has increased to 6.9. core/post-data（date / modified / link) and core/term-data However, it has been added as a core standard source in WordPress 6.9 and later. If you just want to display the publication date and permalink, you might not need to create a custom field.

Before adding custom fields, review what can be handled on the theme side.

Finally, as a final note: "Whether or not the value should be in the custom field" is worth pausing before you start creating it.

Things like the size of the headline, the margins, and the colorValues related to appearanceIt is not a custom field. theme.json Having the presets in place makes it easier to operate the rest of the program. The preset values are shared across the entire site, and they are also available as choices in the editor, so you don't have to enter them for each post (Global settings and styles (theme.json)）。You can also create repeating structures for each page using patterns and templates. It’s ideal for custom fields that change in reality with each post.contentThat's the one.

This arrangement is more effective when the theme is designed with preset drives. For example shitate, it is possible to complete everything with just the core block,theme.json In a block theme that follows the design principle of linking character size and margins with preset settings, the appearance is consistent even without writing your own CSS. Depending on how far the theme extends, the range of values that should be in the custom field will change. Before adding any values, please first review the settings and presets used.

The "not displayed" setting in the custom field is divided into the settings for the editing screen and the settings for output to the public page. The latter is a design decision of choosing A, B, or C. Whether it won't disappear with updates, whether it won't break after delivery, and whether the license fits the project—these three things will significantly reduce the time of confusion.

shitate It is a block theme from the 100% GPL,WordPress official directoryYou can try it for free. For more information,Official websiteSee