pom_theme_update_global_css: update global CSS

Replaces POM Theme's global custom stylesheet and rebuilds the site's compiled CSS.

Arguments

Permissions

Allow POM Theme writes open, plus manage_options.

It replaces, it does not append

css becomes the entire global stylesheet. Anything currently there and absent from what you send is gone.

This is the mistake that costs people an afternoon: asking for "a rule to hide the sidebar on mobile" and receiving a stylesheet containing only that rule, with two years of accumulated styling deleted.

The safe shape of the request names the whole file:

Read the global CSS, then write it back with this rule added at the end. Show me the complete stylesheet before writing.

Read it first, and keep the copy

Theme settings have no revision history. The output of pom_theme_get_global_css, taken before the write, is the only way back.

Save it outside the conversation. A dry run's before is the same content, but a conversation is not a backup.

The dry run is real

It returns before — the current stylesheet in full — and after, exactly what would be stored. Both are the actual CSS.

It also runs the validation first, so a dry run tells you whether the content would be rejected without writing anything.

Diff the two. For a replace-everything write, that diff is the whole review.

What is rejected

CSS containing PHP opening tags or a closing </style> tag returns pom_ai_mcp_css_denied.

That check is deliberately narrow: it blocks the two ways a stylesheet could escape being a stylesheet. It is not a CSS validator. Syntactically broken CSS is accepted and saved.

A missing brace can therefore break the styling of every page on the site, and nothing in the response will say so. Check the rendered site, not just the tool's answer.

The write rebuilds website.min.css

After saving, the theme's save routine fires and the CSS assets are regenerated. The response includes the resulting asset metadata, so you can confirm the rebuild happened and see the new file size and timestamp.

If the metadata shows an unchanged timestamp, the rebuild did not run and the site is still serving the old compiled stylesheet.

Then purge the cache

The rebuild produces a new file; caches serve the old one. A page cache, a CDN, and browsers all need clearing before anyone sees the change.

Update the global CSS, then clear the site cache.

See Clearing the cache after a change.

Consider snippets instead

If the site's custom CSS is one long global stylesheet, every change rewrites all of it, and every change risks all of it.

pom_theme_upsert_custom_css stores named snippets that are edited and deleted individually. For anything that is a distinct piece of styling — a campaign banner, a seasonal override — a snippet is the safer home.

Reserve the global stylesheet for genuinely site-wide rules.

After writing

1. Read the global CSS back and confirm it is complete, not just the new rule.
2. Check the generated stylesheet's timestamp moved.
3. Purge the cache and CDN.
4. Load several page types, including one you did not intend to affect.

Step 4 matters because global CSS is global: a selector meant for the blog can reach the checkout.

Common problems

Related

• pom_theme_get_global_css — read and keep it first
• pom_theme_upsert_custom_css — the safer alternative
• pom_theme_get_generated_css — confirm the rebuild