Configure POM Theme

Theme settings change how the whole site looks. That makes this the group where reading the schema first stops being good practice and starts being necessary.

Requirements

• The POM theme active, or the tools are not registered at all.
• Allow POM Theme writes open — its own gate, separate from content and options.
• pom_theme:read and pom_theme:write on the token.
• edit_theme_options on the acting user.
• Staging, for anything beyond a single known setting.

Always read the schema first

The schema is not optional context. An assistant writing a setting key it invented, or a value of the wrong shape, produces a site-wide visual change that is hard to attribute later.

Read the theme settings schema and the current values, then show me the setting that controls the header layout.

Change one setting at a time

pom_theme_update_setting writes a single setting. pom_theme_update_settings_batch writes several.

Prefer the single-setting tool while you are learning what each does. A batch that produces an unexpected result gives you several suspects; one setting gives you one.

Use a dry run to change that setting to X and show me the before and after.

Both tools support dry_run, and the before-and-after is worth reading — it shows you the current value in the shape the theme actually stores, which is often not the shape you assumed.

Complex settings are refused

Some settings are structured rather than scalar, and the tool refuses to write them through this path. That is deliberate: a partially-written complex setting is worse than an unwritten one.

If a change is refused as a complex setting, make it in the theme's own admin interface.

CSS

CSS deserves particular care because a syntax error can affect layout site-wide, and because a rewrite replaces rather than merges. Read the current CSS, change the specific rule, and keep the original in the conversation so you can restore it.

After a CSS change, run pom_theme_generate_assets if the compiled output has not refreshed, then check pom_theme_get_css_build_info.

JavaScript writes are refused through this path.

Content models are structural

pom_theme_configure_content_model creates and changes post types, taxonomies and custom fields.

This is the largest change available in the theme group. It affects what content exists, how it is organised, and which templates apply. Treat it like a database migration:

• staging first, always;
• a backup you have confirmed restores;
• the create_pom_content_model published prompt rather than an improvised instruction — see Prompt recipes;
• a check of the rendered site afterwards, not just the stored configuration.

Reserved post type slugs and invalid field keys are refused, which catches the obvious mistakes but not a well-formed model that is wrong for your site.

After any theme change

1. Look at the front end — home page, an archive, a single post, on desktop and mobile.
2. Check pages using different templates, not just one.
3. Rebuild assets if CSS changed.
4. Purge the cache. Theme changes affect every page, so a stale cache makes a correct change look broken or a broken change look fine.

See Clear the POM Cache.

Common problems

Related

• Theme setting tools
• Work with POM Theme templates
• Recover from a failed write