A missing field in the WordPress editor can stop an otherwise simple page update cold. If you searched for “how to show meta boxes Gutenberg”, the fix is usually not complicated – but the correct fix depends on whether the box is hidden, attached to the wrong post type, or supplied by an older plugin.
For administrators updating service pages, staff notices or local community information, the aim is simple: show the fields you need without replacing the whole editor or creating a fragile workaround. Gutenberg, also called the Block Editor, can display traditional meta boxes. It just handles them differently from the old Classic Editor screen.
First, identify what is actually missing
A meta box is a panel added below or alongside the post editor by WordPress, a theme or a plugin. Common examples include SEO settings, featured content controls, page templates, event details and custom fields.
Before changing settings, open the same content type where the box should appear. A box registered for Pages will not automatically show on Posts. A box registered for a custom post type, such as `service`, will not appear on a standard Page either.
Also check whether the feature is a real meta box. Some modern plugins place their settings in the right-hand Gutenberg sidebar instead. Others use a block with its own controls. Looking in the wrong place can make a working feature appear to be missing.
How to show meta boxes in Gutenberg: five checks
1. Check the post type registration
For developers, the most common cause is registering the meta box against the wrong editing screen. The `add_meta_box()` call must use the correct post type slug, not the visible name used in the admin menu.
“`php add_action( ‘add_meta_boxes’, function() { add_meta_box( ‘service-details’, ‘Service Details’, ‘render_service_details’, ‘service’, ‘normal’, ‘high’ ); } ); “`
In this example, the box appears only when editing the `service` post type. To show it on Pages, change `service` to `page`. To support more than one post type, register the box for each screen deliberately. Avoid adding it everywhere just because it is convenient. A crowded editor leads to mistakes.
For non-technical administrators, this check means confirming the plugin feature was designed for the content you are editing. Read the plugin settings first. Many plugins let you choose supported post types under their own configuration screen.
2. Look in Gutenberg’s panel preferences
The Block Editor lets each user hide panels. Open a post, select the three dots at the top right, then choose Preferences. Under Panels, look for the relevant plugin or meta box name and turn it back on.
After saving a post, scroll below the main editing area too. Compatible legacy meta boxes commonly appear in an Additional section beneath the blocks, rather than in the right sidebar. This is normal behaviour, not a sign that Gutenberg has failed.
Do not rely on old instructions that tell you to use Screen Options. That control belongs to the Classic Editor interface and is not the normal place to manage Gutenberg panels.
3. Update the plugin, theme and WordPress core
Gutenberg supports meta boxes, but not every old implementation behaves well inside it. Update WordPress core, the active theme and the plugin that creates the missing box. Then clear any site, server or browser cache before testing again.
A compatibility issue is more likely when the box uses outdated JavaScript, inserts editor buttons directly into the old TinyMCE interface, or assumes the page reloads after every field change. In those cases, forcing it into Gutenberg may leave controls half-working.
If a plugin developer states that their meta box is not Block Editor compatible, use the plugin’s supported alternative if one exists. This may be a sidebar panel, a dedicated block, or a separate settings page. Keeping an incompatible editor component alive can cost more time than replacing it.
4. Register stored metadata for the REST API
A traditional PHP meta box can render in Gutenberg without REST API registration. However, if you want a block, sidebar component or custom JavaScript to read and save that metadata properly, register the field with `show_in_rest` enabled.
“`php add_action( ‘init’, function() { register_post_meta( ‘service’, ‘_service_area’, array( ‘type’ => ‘string’, ‘single’ => true, ‘show_in_rest’ => true, ‘auth_callback’ => function() { return current_user_can( ‘edit_posts’ ); }, ) ); } ); “`
This does not create a visible field by itself. It makes the data available to the Block Editor and authorised WordPress requests. You still need either a meta box callback, a sidebar interface or a custom block to collect the value.
Use an explicit authorisation callback and sanitise every saved value. This matters for any organisation, but especially for a disability support provider site. Do not store participant records, support notes, health information or other sensitive personal information in public website post metadata. Even correctly configured WordPress permissions are not a substitute for an approved client records system.
5. Mark compatible legacy boxes carefully
WordPress offers compatibility flags for legacy meta boxes. A developer can pass `__block_editor_compatible_meta_box` in the callback arguments where a box is known to work in the Block Editor.
“`php add_meta_box( ‘service-details’, ‘Service Details’, ‘render_service_details’, ‘service’, ‘normal’, ‘high’, array( ‘__block_editor_compatible_meta_box’ => true ) ); “`
Only use this flag after testing the save process, validation and display on a staging site. It is not a magic repair switch. Declaring a broken box compatible simply hides the real problem until someone loses an edit.
The opposite compatibility option can send users towards the Classic Editor for that screen. Treat that as a temporary operational decision, not the default answer. Gutenberg is the supported editing experience for modern WordPress builds, and maintaining two editor workflows increases staff training and support effort.
Build the box with safe saving practices
If you are creating the meta box yourself, the display callback should output a nonce, retrieve the current value and escape it for the field. The save callback should verify the nonce, check the user capability, avoid autosaves and revisions, then sanitise the incoming value.
“`php function render_service_details( $post ) { wp_nonce_field( ‘save_service_details’, ‘service_details_nonce’ ); $area = get_post_meta( $post->ID, ‘_service_area’, true ); echo ‘‘; echo ”; } “`
Keep fields focused on website publishing needs: a service area, a short page label, a display option or a related resource. If a field needs complex validation, repeated records or workflow approvals, a custom Gutenberg sidebar or purpose-built administration screen may be more reliable than piling more controls into a legacy meta box.
Test with the people who update the site
Technical success is not enough if coordinators or office staff cannot find the field during a routine update. Create a draft test page, open it with an administrator account and an editor account, and confirm the box appears for both roles where appropriate. Save values, refresh the page, preview the content and check the front-end output.
Also test on a mobile-sized browser window. Meta boxes below the editor are easy to overlook on a smaller screen, particularly when a page has many blocks. A short internal note showing the exact panel location can prevent repeated support requests.
Start with one missing box, one post type and one test value. That small check will tell you whether this is a preferences issue, a plugin compatibility problem or a development task worth fixing properly.
