Where field groups appear and how values are saved

Last updated Oct 3, 20264 min read

When a group is Active and one of its location rules matches the current screen, its fields are shown there. Values are saved with the screen's own Update / Save button; there is no separate save.

Screens

Screen	Where the group appears	Saved when	Stored in `mtype`
Posts, pages, custom post types, media (Edit screen)	A meta box titled with the group Title, placed by the group's Position (High, Normal or Side) and Order. In the block editor the meta boxes are below the content or in the sidebar.	The post is saved (`save_post`). Autosaves and revisions are skipped.	`posts`
Users: Your profile, Edit user, Add new user	A section with the group title as an `<h2>` heading after the core fields.	Profile or user update; for Add new user, when the user is created.	`users`
Terms: Edit category, Edit tag, Edit {custom taxonomy}	A section with the group title as a heading at the bottom of the edit form. Not on the Add New form on the left of the terms list.	The term is updated (`edited_term`).	`terms`
Comments: Edit Comment screen	A meta box with the group title.	The comment is updated.	`comments`
Widgets	Inside each widget's form (every widget type that WordPress renders with a form), under its own settings.	The widget is saved.	`widgets`
Options pages	On the options page named in an Options page rule.	The options page is saved. See Options pages.	`options`
WooCommerce orders (Pro)	On the order edit screen. See WooCommerce.	The order is saved.	`wc_orders` (the row key is the order ID)
Navigation menu items	Not shown. The Menu and Menu item rules exist but no menu editor integration is built yet.

Every group has its own nonce on the screen, so one failing group never blocks the others.

Fields appear in the order of the field builder. On the Modern style, fields sit on a grid using each field's Width, Tab and Accordion layout fields split the box into sections, and the group Description sits above the fields.

Saving

Topic	Behavior
Nothing posted for a field	A field missing from the submitted form is left alone (its stored value is kept).
Unchecked checkboxes	They post an empty fallback so clearing works. A unique indexed field saves an empty value as `NULL`, so several empty values are allowed.
Sanitizing	Each value is sanitized by its field type, then your validation rules are applied (Max length cuts text, Min/Max value clamp numbers). Types that store files or links keep their own checks.
Defaults	The Default value is shown for an object that has no row yet, and saved with the first save.
Hidden by conditional logic	Hidden fields still post and keep their value.
Too many inputs	If the form sends more values than PHP's `max_input_vars` allows (default 1000), nothing is saved and an error notice reads `Custom fields were not saved: the form sent more values than the server accepts (max_input_vars = N). Remove repeater rows or ask your host to raise it.`
A failing group	One group that fails to save (for example its table was changed outside the plugin) is logged under Settings › Health and does not stop other groups.
Duplicates, revisions, export	Field rows follow posts through duplicate-post plugins, revisions and WordPress's WXR export and import.
Privacy tools	Tools › Export / Erase Personal Data includes `Custom field values` for user accounts and for comments with the person's email; password fields are never exported.

Required fields

See Required fields. In short: forms use browser validation, the block editor locks saving until required fields are filled, and the server never rejects a save but shows Saved, but these required fields are empty: ... afterwards.

Who can save

A post's values are saved only when the person can edit that post. Users, terms, comments and widgets follow the capabilities of their own screens. Direct calls such as wpmcf_update_field() do not check capabilities or location rules: they write to any object of any group, so check permissions yourself before calling them with user input.

When the object is deleted

When a post is permanently deleted, a user is deleted, a term is deleted or a comment is deleted, its rows are removed from every group table (in one query per table at the end of the request). Moving a post to the Trash does not delete the values.

Troubleshooting

Problem	Fix
A group is missing on a post type	Check Active, the location rules, and that the post type has an edit screen. After adding rules to a group that had none, save the group once so its table gets the `mid`/`mtype` columns.
A group is missing on the term "Add New" form	By design: groups appear on the term edit screen.
My values vanished after a failed save	Look at Settings › Health for the logged error; check `max_input_vars` on large repeaters.
The classic editor warns after saving	A required field is empty: fill it and update again.

Was this page helpful?

Still stuck? Contact support