Bulk Edit Custom Fields in WordPress from Any Plugin or Theme

To bulk edit custom fields in WordPress that another plugin or your theme created, you need two facts about each field: its meta key and the format of the value it stores. Toolset fields, listing and directory details, a theme's per-post options: as long as they live in the post's meta, WOLF can show them as columns, filter by them and change them for hundreds of posts at once. This guide shows how to find the key, how to read the stored format, which column settings match it, and how to recognise the fields that cannot be edited this way.

What a custom field is, and what WOLF can edit

A custom field is a row in the wp_postmeta table: a post ID, a meta key and a value. The plugin that owns the field decides the key and the format. Its edit screen shows a friendly control, such as a group of checkboxes, an image uploader or a date picker, but what it saves is a value in that row: a list of option keys, an attachment ID, a date string.

WOLF works on that stored value, not on the plugin's control. That has two consequences:

• Any value in post meta can become a WOLF column, whatever plugin wrote it.
• Data the plugin keeps anywhere else, in its own database tables, in options or in term meta, cannot be a column, a filter or a bulk operation.

For Advanced Custom Fields there is a separate guide with the format of every field type: bulk editing ACF fields.

Find the meta key of a custom field

Use these three methods in this order:

1. List the keys of a post. Fill the field on one post with a value you will recognise and save it. In WOLF, select the post type, open Meta Fields, enter the post ID under Get meta keys from any post by its ID and click Get. Keys with readable names usually explain themselves. To check a candidate, keep it, save the meta fields, enable its column in Settings and look at the value of your test post. Keys that start with an underscore are hidden from the WordPress custom fields box, but many plugins store their real data under them, so do not skip them.
2. Inspect the field on the edit screen. Right-click the input on the post edit screen and choose Inspect. Its name attribute often contains the key or a part of it. Toolset, for example, adds the prefix wpcf- to the field slug, so a field listing-amenities is stored under wpcf-listing-amenities.
3. Ask the author. If neither works, the plugin's documentation or support can tell you the key and the format.

Match the column to the stored value

Once the column shows the raw value, its shape tells you how to set up the field in Meta Fields. The Meta Fields documentation describes each view.

Two notes on the table. The calendar view saves a Unix timestamp, so use it only for fields that already store one; for every other date format it would change the format and the owning plugin could no longer read the date. And for text values of a checkbox, add a rule to Settings → Override meta checkbox: a rule is the meta key, a colon and the value, so featured:yes makes the checkbox write yes when it is on, and featured:yes^no also writes no when it is off. Several rules are separated by commas.

Serialized and JSON values open in a key/value popup; see bulk editing serialized meta data.

Examples from real plugins and themes

Toolset checkboxes and yes/no fields

A Toolset checkboxes field such as wpcf-listing-amenities stores a serialized list of the selected options, identified by Toolset's internal option keys, not by their titles. Set it to array: the popup shows only the options that are selected, under those keys. Typing such keys by hand is error-prone, so copy a selection instead: set it on one post in the Toolset editor, select that post and the posts that should get the same selection in WOLF, switch on binded editing, open the array popup of the example post and click Apply. The value is written to every selected post, as described in setting the same value for several posts. A single yes/no field such as wpcf-featured-listing stores 1 when checked; the checkbox view handles it.

Page templates and theme post options

WordPress keeps the template chosen for a page or post in _wp_page_template. Add it as a string, copy the exact value from a post that already uses the template, and bulk edit the others to it; default returns them to the default template. Themes with their own per-post options often keep them together in one serialized field, the Newspaper theme's post template among them. Add that key as array, change the setting on one post, and copy it to the others with binded editing as above.

Images in listing and directory plugins

Image fields usually store attachment IDs, not URLs, so a URL typed into the column does nothing. Enter the ID of the image from the Media Library. If the field holds the main image of the post, check whether it is simply the featured image: that is WOLF's built-in Thumbnail column. Some plugins store their image lists in a format of their own; if the value is neither an ID, a comma list nor a serialized list, leave it to the plugin's own editor.

When a custom field cannot be edited in bulk

• The data is not in post meta. Some directory and listing plugins, GeoDirectory among them, keep listing details in their own database tables. If a field never appears in Get meta keys from any post by its ID, even on a post where it is filled, there is no meta row to edit. Only the plugin's own tools, or its support, can help with such fields.
• Several rows share one key. A few plugins save a multi-value field as several meta rows with the same key, one per value. WOLF treats a meta field as one value: the column shows the first row, and saving replaces every row of that key with the one value. Do not bulk edit such fields.
• The value is not a real list. Values such as red|blue or red, blue are plain text. Edit them as a string; the array view cannot append to them.

One effect surprises people: editing only meta fields does not change the post's Date modified. WOLF saves meta with update_post_meta() and fires the save_post and edit_post actions so other plugins can react, but it does not save the post row. If the modified date matters, for example for sitemaps or "last updated" labels, include the Date modified column in the same bulk operation: WordPress stamps the current time on every post it saves, whatever date you pick.

Test on one post, then bulk edit the custom fields

1. Change the field on one post in the WOLF table.
2. Open that post in the owning plugin's edit screen and on the front end, and check that the new value is shown correctly.
3. Filter the posts you want to change in the Filters tab and run the operation in the Bulk Edit tab.
4. If the result is wrong, revert the whole operation in the History tab.

If a field is stored in post meta and still does not behave as described here, open a topic on the WOLF support forum with the meta key, an example of its stored value and the plugin that creates it.