How to save WordPress custom fields in a custom table

Decide whether one row should represent each post, user, term or another record. For post fields, include an object ID column and one column for each field you want to store. Use the WordPress table prefix rather than assuming it is wp_, because the prefix can be changed per site.

Choose column types deliberately. Text fields can use TEXT or VARCHAR, numeric values should use a numeric type, and fields that you will search or sort should have suitable indexes. Do not put every value into one serialized column unless the data cannot be queried separately.

For a manual implementation, create the table from a small plugin, not from a theme. Run the creation routine on plugin activation with register_activation_hook(), load wp-admin/includes/upgrade.php, and pass a correctly formatted CREATE TABLE statement to dbDelta(). Use $wpdb->get_charset_collate() so the table follows the site's character set and collation.

Where this breaks: dbDelta() is particular about SQL formatting. Put each column on its own line, use KEY for indexes, use lowercase field types, specify lengths where required, and write PRIMARY KEY in the format WordPress expects. Keep a schema version and run the upgrade routine when the plugin version changes, because activation hooks do not run automatically on plugin updates.

Add a meta box or another admin form for the fields. Include a nonce, check the current user's capability, ignore autosaves and revisions, and validate each submitted value according to its type. Use the appropriate sanitiser for the data rather than treating every field as plain text.

For example, a short label can use sanitize_text_field(), while a number should be validated as a number and a URL should use URL validation. WordPress describes sanitize_text_field() as removing tags, invalid UTF-8 and unwanted whitespace, but it is not suitable for every kind of input.

Hook the save routine to save_post, or to the post-type-specific version when appropriate. The hook runs after a post is saved and also fires for imports and other save paths, so your callback must check the post type, permissions, nonce, autosave status and revision status before writing data.

Use $wpdb->insert() when the object has no row yet and $wpdb->update() when it does. Use the object ID as the primary key or unique lookup value, pass raw values with explicit formats such as %d and %s, and check the return value for database errors. Do not concatenate submitted values into SQL.

Replace calls to get_post_meta() with a small repository or helper function that reads the row by object ID. Use $wpdb->get_row() or $wpdb->get_results() with prepared queries, and escape values for their final output context when rendering them.

Also decide what happens when a post is deleted. Add a cleanup routine for deleted objects, or document why rows are retained. Test new posts, edits, revisions, autosaves, bulk edits, imports, empty values and deleted posts before using the table on production data.

Use MB Custom Table when your fields are managed by Meta Box and you do not need to write the storage layer yourself. Configure the field group to use custom-table storage, enter the table name, and either let the extension create the table or connect it to an existing table. The table needs an ID column, and its other column names must match the field IDs.

Save the post normally after configuring the field group. The values are then stored in one row for that object, with each field in its matching column. Use the plugin's helper with the custom-table arguments when reading values. This route is usually preferable when you have several fields, need a visual field builder, or want cleaner storage without maintaining insert, update and migration code yourself.

For existing post-meta data, do not assume changing the setting moves old values automatically. Back up the database and migrate the old values with a script or documented migration process, then verify that field IDs, column names and stored formats match.