pom_theme_upsert_custom_css: create or update managed custom CSS

Writes a named CSS snippet. Creates a new one, or replaces an existing one, depending on whether you pass an identifier.

Arguments

Permissions

Allow POM Theme writes open, plus manage_options.

The identifier decides create or replace

Omit repeater_identifier and a new snippet is created with a generated ID. Pass one and that snippet is overwritten in place.

Both paths report updated: true, so the response does not tell you which happened. Count the snippets afterwards if it matters.

The failure mode is duplication: an assistant asked to "update the banner CSS" that omits the identifier creates a second banner snippet, and both are now compiled into the site. The styling gets messier rather than fixed.

List the snippets and give me the identifier for the banner one, then update that identifier.

css replaces the snippet's whole content

Not a merge, not an append. Whatever you send is the snippet.

That is the point of snippets — the blast radius is one snippet rather than the entire stylesheet — but within that snippet the replacement is total. Read it first with pom_theme_get_custom_css and keep the copy; there are no revisions.

stylesheet_name is required even when updating

You cannot change the CSS while leaving the name alone by omitting it. It must be sent, and whatever you send becomes the name.

So an update that forgets the current name silently renames the snippet. Read the name along with the identifier and pass it back unchanged unless you mean to rename.

Validation is narrow

CSS containing PHP opening tags or </style> is refused with pom_ai_mcp_css_denied. Nothing else is checked.

Malformed CSS — an unclosed brace, an invalid property — is accepted and saved. Since the snippet is compiled into the site's stylesheet alongside everything else, a broken snippet can damage rules that come after it in the compiled output.

The site is the test, not the response.

The dry run shows the row, not a diff

It returns the row that would be stored: the identifier, the name, and the CSS content. What it does not return is the snippet's current content.

So unlike the global CSS dry run, there is no before here. If you want a comparison, read the snippet first and compare yourself:

Read the snippet, then dry-run the replacement, and show me both.

The dry run does confirm one useful thing: which identifier would be written. If it shows a newly generated ID when you expected an existing one, you are about to create a duplicate.

Every write rebuilds the site's CSS

The theme's save routine fires and the CSS assets regenerate. The response includes the resulting asset metadata — check the timestamp moved.

Then purge the cache. The rebuild changes the file; caches keep serving the old one.

Splitting a large stylesheet

Moving rules out of the global stylesheet into snippets is a good change, and a delicate one:

1. Read the global CSS and keep it.
2. Create each snippet and verify the site after each.
3. Only then rewrite the global stylesheet without the moved rules.

Doing step 3 first leaves the site unstyled in between.

After writing

1. List the snippets and confirm the count did not grow unexpectedly.
2. Confirm the name is what you intended.
3. Check the generated stylesheet's timestamp moved.
4. Purge the cache, then load affected pages.

Common problems

Related

• pom_theme_get_custom_css — get the identifier first
• pom_theme_delete_custom_css
• pom_theme_update_global_css