When Gutenberg custom fields missing becomes the problem, the usual reaction is to assume WordPress has deleted data. Usually, it has not. The Custom Fields panel is often simply hidden, unavailable for that content type, or replaced by a plugin field interface. The fix is normally straightforward, but it matters how your site uses the fields before switching settings or removing plugins.
For a disability support website, custom fields may control practical information such as service locations, staff profiles, intake details, page banners, structured contact information, or internal content labels. A missing panel can stop an administrator from updating a page properly. It should not lead anyone to enter participant or sensitive health information into a public WordPress field.
First, turn the Custom Fields panel back on
In the WordPress block editor, open the post or page where you expect the field to appear. Select the three-dot menu in the top-right corner, then choose Preferences. Open Panels and enable Custom fields.
WordPress may ask you to reload the editor. Accept the reload. Once the page opens again, scroll below the main editor content. The standard Custom Fields box generally appears underneath the block area, along with other legacy panels.
This setting is saved for the individual WordPress user, not necessarily for every administrator on the site. If one team member can see the panel and another cannot, compare their editor preferences first. That small detail saves a lot of unnecessary troubleshooting.
The panel is deliberately hidden by default on many installations because it is an older interface and can confuse people who do not need it. Hiding it does not remove existing custom field values.
Check whether you are editing the right content type
A common Gutenberg custom fields missing issue is that the feature works on posts but not pages, or works on one custom content area but not another. WordPress only displays the standard panel when that post type supports custom fields.
For a developer-built custom post type, the registration needs to include custom field support. In code, that usually means `custom-fields` is included in the post type’s supported features. If it is absent, Gutenberg has nothing to show, even when the editor preference is enabled.
This is a configuration decision, not a Gutenberg fault. Some content types intentionally exclude arbitrary custom fields to protect a controlled editing workflow. For example, a service listing may use selected fields for suburb, service category and call-to-action text. Allowing staff to add unplanned fields can create inconsistent page output.
If the site is custom-built, ask the developer which field system is intended for that content type before changing registration settings. Adding support can be useful, but it can also expose fields that the template does not use.
Pages and posts do not always behave the same way
Do not test only one screen and assume the finding applies everywhere. Check a normal post, a standard page, and the specific content type you are trying to update. Note whether the site uses a custom template, a page builder, or a fields plugin.
If the problem is limited to one page, it may have a different template or editing permission. If every item of the same content type is affected, the post type setup is the more likely cause.
Know the difference between native fields and plugin fields
The WordPress Custom Fields panel is not the same as a plugin-managed field group. Tools such as Advanced Custom Fields, Meta Box, Pods, or a theme framework may display their own fields beneath the editor or in the right sidebar.
If those plugin fields are missing, enabling the native Custom Fields panel will not restore them. Check the plugin’s field group rules instead. A field group can be set to appear only on particular page templates, categories, post types, user roles, or individual pages.
For example, a field group designed for a service page may only load when the page uses the “Services” template. Change the template and the fields disappear. The data may remain stored in the database, but the editing controls will no longer be visible.
This distinction matters because the wrong fix can create duplicate or conflicting data. Avoid adding a new native custom field with the same name as a plugin field unless you know exactly how the theme reads it.
Review block editor compatibility for custom data
Modern Gutenberg blocks can read and save post meta, but custom metadata needs to be registered correctly. For a custom field to work through the block editor or the WordPress REST API, it commonly needs `show_in_rest` enabled. Its data type, whether it stores one value or multiple values, and its permission callback must also match the intended use.
When those settings are incomplete, a field may appear in a legacy box but fail to save through a custom block. Or a block may show an empty value despite data existing on the post. These are developer configuration issues, not something an editor should work around by repeatedly saving the page.
A safe developer check is to inspect one known post, confirm the meta key and existing value, then test an update on a staging copy. Do not run database clean-up tools on a live site merely because a panel is missing.
Rule out plugin and theme interference
Some plugins intentionally remove the native Custom Fields box. This is often done to simplify the editor, reduce accidental changes, or support a more structured content model. A theme can also remove the panel with WordPress hooks.
Work through the checks in this order:
- Confirm the panel is enabled in Preferences for the affected user.
- Check that the post type supports custom fields.
- Confirm whether a fields plugin controls the information instead.
- Review recent updates to the theme, custom plugin, editor plugin, or security plugin.
- Test changes on a staging site by temporarily switching off non-essential plugins one at a time.
Use a staging site whenever possible. Turning off a plugin on a live service website can remove booking forms, contact controls, consent notices, or layout components for visitors. For organisations supporting people with disability and their families, clear and reliable website information is operationally important.
If deactivating a plugin restores the panel on staging, do not leave the plugin disabled as the final answer. Check its settings, update it, or identify the code that hides the meta box. A plugin conflict is a useful diagnosis, not a permanent configuration plan.
Check roles, permissions and managed hosting rules
Editors and administrators can see different WordPress controls. A capability management plugin may restrict access to custom fields, especially where a site has multiple content contributors. Test with a trusted administrator account before assuming a user role is broken.
Managed WordPress setups can also apply editor restrictions through a must-use plugin or hosting configuration. These plugins do not appear in the normal Plugins screen, so the settings can be easy to miss. A developer can inspect the site environment and determine whether a managed rule is removing the panel.
Security is a fair reason to restrict arbitrary metadata. Custom fields can expose implementation details or create unexpected output if templates render values without proper validation. The answer is not always “show every field to every user”. It depends on who edits the site and how the field is used.
Avoid these quick fixes
Do not install a random “restore custom fields” plugin before checking Gutenberg preferences and post type support. Another plugin adds another moving part, and it may mask the original cause.
Do not change field names to guess what the template expects. Field names are often hard-coded in a theme or custom block. A single spelling difference can leave a service page looking blank even though the editor shows a value.
Also avoid storing confidential participant notes, disability reports, medical details, plan information, or rostering notes in WordPress custom fields. Website administration fields are not a participant record system. Keep public website content separate from protected service documentation.
A practical handover note for your web team
If you need technical help, send a short, specific report: the page URL or page title, the affected content type, the WordPress user role, when it last worked, any recent updates, and whether plugin-managed fields or the standard panel are missing. Include screenshots that do not reveal private participant information.
That gives a developer enough context to check the right layer first: user preferences, post type registration, field group rules, theme code, permissions, or plugin conflicts. Clear details beat broad requests such as “the editor is broken”.
A missing panel is usually a settings or configuration problem, not lost content. Check the simple editor option first, protect the existing data, and only then make targeted changes. That approach keeps the site easier to manage for the people relying on it.
