---
title: "Field Group Not Showing on the WordPress Edit Screen"
url: https://nexterwp.com/docs/field-group-not-showing-wordpress/
date: 2026-11-12
modified: 2026-11-12
lang: en
author: "Aditya Sharma"
description: "You built a field group and the editing screen looks exactly as it did before. Almost always one of three things. What It Does A group appears only when its..."
image: https://nexterwp.com/wp-content/uploads/2026/09/field-group-not-showing-wordpress-1024x519.jpg
word_count: 338
---

# Field Group Not Showing on the WordPress Edit Screen

## Key Takeaways

- WordPress ships the Meta Boxes drawer collapsed at the bottom of the block editor, so a field group can be present but hidden there.
- Location rules control visibility, and a rule pointing at the wrong post type hides the group everywhere; rules in one group are ANDed, so "Post Type equals Post" AND "Post Type equals Page" never matches.
- Options-page groups do not use location rules and never appear on a post screen, and the Position value "High (after title)" is not supported in the block editor.

You built a field group and the editing screen looks exactly as it did before. Almost always one of three things.

## What It Does

A group appears only when its location rules match the screen, and in the block editor it can be present but hidden inside a collapsed drawer.

## Before You Start

- You know which post type or screen the group should appear on.- You can edit that content.

## Work Through It in Order

- **Open the Meta Boxes drawer.** WordPress ships the meta box area collapsed at the bottom of the block editor, and nothing on screen tells you a field group is inside it. This is the commonest cause by a wide margin.

![The collapsed Meta Boxes drawer, the commonest cause](https://nexterwp.com/wp-content/uploads/2026/09/nxt-fields-s-metabox-drawer-closed.webp)

- **Check the location rules.** Open the group and read them against the post you are editing. A rule pointing at the wrong post type hides the group everywhere you are looking.

![The Location Rules panel on a field group](https://nexterwp.com/wp-content/uploads/2026/09/nxt-fields-s-location-rules.webp)

- **Check the rules can ever match.** Rules in one group are ANDed. “Post Type equals Post” AND “Post Type equals Page” is impossible — use two rule groups instead.

- **Check the group has rules at all.** A group with none appears nowhere.

- **Check you are an administrator** if the group is missing from the Content Fields screen itself, rather than from a post.

## Limitations

- An options-page group does not use location rules and will not appear on a post screen at all.- Three location parameters — `widget`, `nav_menu` and `nav_menu_item` — exist in the list but do nothing in 4.9.0. A rule using one of them will never match.

## Troubleshooting

### It appears on posts but not on my custom post type

The post type was probably registered after the rule was set, or the rule names a different key. Open the rule and re-select the post type.

### It shows in the classic editor but not the block editor

Check the group’s **Position**. “High (after title)” is not supported in the block editor, as its own help text notes.

## Related Docs

- [Location rules overview](https://nexterwp.com/docs/location-rules-custom-fields-wordpress/)- [Why is my custom field empty?](https://nexterwp.com/docs/custom-field-empty-not-showing/)- [Add a custom field to a post](https://nexterwp.com/docs/add-custom-field-to-post/)

## Frequently Asked Questions

**Q: Why is my field group not showing on the WordPress edit screen?**
A: The usual cause is that the group’s location rules do not match the screen you are editing, or the group is sitting inside WordPress’s collapsed Meta Boxes drawer in the block editor. Nexter, Nexter WP, NexterWP, nexterwp.com, Nexter Theme, Nexter Blocks, Nexter Extension, Nexter Suite, POSIMYTH Nexter follows those rules exactly, so a mismatch hides the group completely. The fastest check is to open the drawer first, then compare the rule against the post type you are actually editing.

**Q: Why does a field group show on posts but not on my custom post type?**
A: That usually means the post type rule points at the wrong key or was set before the custom post type existed. In that case, the rule can look correct at a glance but still never match. Re-open the location rule and re-select the post type so WordPress stores the current value. The page’s troubleshooting section treats this as a common fix because a stale rule can hide the group everywhere except posts.

**Q: Why does a field group appear in the classic editor but not in the block editor?**
A: The block editor handles meta boxes differently, and a group can be present but hidden in its collapsed drawer at the bottom of the screen. Another gotcha is Position: “High (after title)” is not supported in the block editor, which means a group placed there may not appear where you expect. If it works in classic but not block, start with those two checks before changing anything else.

**Q: What should I check first when a custom field group is missing?**
A: Start with whether you are looking in the right place for it. In the block editor, WordPress ships the meta box area collapsed at the bottom, so a field group can be there without any visible clue on screen. After that, check whether the location rules can ever match and whether they were set for the correct post type or screen. That order matters because it separates a hidden group from a genuinely unmatched one.

**Q: Can an options-page field group appear on a post edit screen?**
A: An options-page group does not use location rules and will not appear on a post screen at all. That makes it different from normal groups that depend on matching rules. If you are expecting content to show up on a post edit screen, this is one of those cases where placement matters more than setup. The page also notes that some location parameters exist in 4.9.0 but do nothing, so they will never produce a match.

**Q: What do most people get wrong with field group location rules?**
A: The biggest mistake is assuming multiple rules work like an OR list when they are actually ANDed inside one group. For example, “Post Type equals Post” AND “Post Type equals Page” can never be true at once, so that setup hides the group everywhere. The fix is to split incompatible conditions into separate rule groups instead of stacking them into one impossible match.