Storing custom fields in real, typed tables instead of wp_postmeta buys you sorting, indexing and correct types, as described elsewhere on this blog. It also introduces a category of risk that wp_postmeta never had: schema changes. Renaming or changing the type of a column is a normal database operation, but it is not automatically a safe one, and a plugin that manages tables on your behalf has to take that seriously.
This post covers what actually happens, mechanically, when you rename a field, change its type, or remove it in Mass Custom Fields — and what Table health does when your field group definitions and your actual tables drift apart.
The rules behind every save
Every field is a column, so editing a saved field group alters a real table. Four rules apply to every save:
- Table first, definition second. The table is altered first. Only when that worked is the field group definition stored, so a failed save cannot leave the two out of step.
- All or nothing. If one step fails, for example because a new unique index meets duplicate values, the steps already done are undone and the message ends with "Nothing was changed."
- Removing never deletes data. A removed field's column stays in the table.
- Risky conversions keep a backup. Before a conversion that could lose data, the old values are copied to a backup column.
Renaming a field does not lose data
When you change a field's key, the underlying operation is a column rename, not a drop-and-recreate. The data already in that column stays exactly where it is; only the column's name changes, and the field's indexes are renamed with it. The editor warns you before you save that the rename will run RENAME COLUMN. The naive way to rename a column — add a new one, copy values across, drop the old one — is slower on large tables and has more ways to go wrong.
ALTER TABLE wp_wpmcf_fg_product
RENAME COLUMN release_date TO launch_date;After a rename, update the templates, shortcodes and code that still use the old key.
Changing a field's type keeps the old value
Changing a field's type is riskier than renaming, because not every value in the old type converts cleanly to the new one. Truncating a TEXT column to a shorter VARCHAR can cut off real data; converting free text to a number turns values that are not numeric into NULL or 0.
For a risky change the editor shows the dialog "This type change can lose data" with three choices:
- Cancel, and nothing changes.
- Convert with a backup. The old values go to a column named
{key}__bakfirst. Check the converted values after saving, and delete the backup under Table health when you are satisfied. - Create a new field instead. A second field with the new type is added and the old column is left alone, which suits cases where you want to migrate values by your own rules.
A compatible change, such as Text to Text area, simply modifies the column and keeps the values.
Removing a field does not delete your data
Removing a field from the editor removes the field definition — the thing that makes it editable and visible — but the column and its values stay in the table as a leftover column. Deleting data is a separate, explicit action. Deactivating the plugin does not delete anything either, and uninstalling it only removes data if you switch on the deletion option in Settings.
If you add a new field with the same name as a leftover column, the editor asks whether the new field should use the saved values or start empty, and moves the old values to a backup column in the second case.
What drift means and why it happens
Drift is any mismatch between what a field group's definition says the table should look like, and what the table actually looks like. It can happen for ordinary reasons: a developer ran SQL, a migration tool dropped a column, or a backup was restored partly.
Table health exists to surface this rather than let it be discovered later as a confusing bug. For each saved group it shows a health badge and size statistics, and a Table differences panel with up to three lists:
List | Meaning | Actions |
|---|---|---|
Missing columns | Defined in the field group but absent from the table | Add to DB |
Leftover columns | In the table but not in the definition, including backup columns | Import as fields, Remove from DB |
Changed outside the plugin | The SQL type in the database differs from the definition | Sync to DB |
Tables that have no field group at all appear as unregistered tables at the top of the Field Groups list. You can register them as a group or drop them.
For details on each panel, see Table health.
Large tables change in the background
Some schema operations — adding an index to a table with a large number of existing rows, for instance — are not instantaneous. When a table has about 100,000 rows or more, the change is queued and runs in the background through Action Scheduler, the same job runner WooCommerce uses. The editor shows an Updating badge, the site keeps using the previous definition until the change completes, and values saved in the meantime are kept. A queued change can be cancelled; one that is already running cannot.
Takeaway
A plugin that manages real tables on your behalf has to treat schema changes with the same care a careful engineer would apply by hand: renames that don't move data, type changes that keep a way back, removals that don't touch the column until you say so, and a panel that tells you when reality and definition disagree. The full rules are described in changing a field group safely.
