pom_theme_update_settings_batch: update settings in a batch

Applies several setting changes in one call. A loop around pom_theme_update_setting, with the same allowlist and the same refusals.

Arguments

Permissions

Allow POM Theme writes open, plus manage_options. Checked per entry.

The batch dry_run always wins

Each entry's dry_run is overwritten by the batch-level value before the entry runs. An entry cannot opt out of a batch dry run, and it cannot opt into one.

Both this tool and wc_batch_update_variations keep every entry read-only during a batch preview. WooCommerce additionally allows an individual row to request a preview during a write batch.

Here, the batch flag is the only one that matters — which is the safer arrangement, and worth relying on.

Incomplete entries depend on the transport

The standard transport skips a malformed entry or one missing setting, field or value, without adding a result. WordPress MCP Adapter validates these required fields before execution and refuses an invalid batch.

So the results list can be shorter than what you sent, with nothing indicating why. Compare the counts every time:

Apply the batch, then confirm the results list has as many entries as I sent.

Note that a value of zero or an empty string still counts as present; only a genuinely absent key is skipped.

Failures are per entry, and there is no rollback

Each entry returns its own outcome. An entry denied by the allowlist fails alone; the rest still apply.

Given the allowlist contains two fields, a batch assembled from what the schema advertises will mostly fail. That is the expected shape of the response, not a malfunction:

Apply the batch and show me which entries succeeded and which returned pom_ai_mcp_theme_field_denied.

Walk the whole list. A batch reported as "done" because the call returned successfully may have written nothing.

Every entry fires the theme's save routine

The post-save action runs once per successful entry, not once for the batch. Ten writes mean ten save cycles, and for template settings, ten manifest rebuilds.

That makes a large batch slower and more disruptive than it appears. Keep batches small — which the two-field allowlist mostly enforces anyway.

When a batch is worth it

Realistically: setting archive and single layouts for several custom post types in one pass. That is the case the allowlist permits and where grouping helps.

Set the archive sidebar layout for the product, project and event post types in one batch, as a dry run first.

For anything involving CSS or templates, use the dedicated tools — those values are complex and this tool refuses them with pom_ai_mcp_complex_setting_denied.

Read the current values first

There is no combined before-and-after view of the whole batch beyond the individual dry runs. Read each setting with pom_theme_get_settings_values and keep the result; it is your restore path.

After writing

1. Account for every entry in results.
2. Read each affected setting back.
3. Load a page of each affected type and confirm the layout.
4. Purge the cache.

Common problems

Related

• pom_theme_update_setting — the single form, and the allowlist
• pom_theme_get_settings_values
• Update theme settings