pom_theme_delete_custom_css: delete managed custom CSS

Removes one CSS snippet. Marked destructive, and there is no trash to recover it from.

Arguments

Permissions

Allow POM Theme writes open, plus manage_options.

There is no undo

Snippets have no revision history and no trash. Once removed, the row is gone from the setting.

The only copy of its CSS is whatever pom_theme_get_custom_css returned before you deleted it. Read it, keep it outside the conversation, then delete:

Show me the full CSS of that snippet. I want to keep it before you delete it.

A wrong identifier reports success

This is the quirk to know. The tool filters the snippet list by identifier and reports deleted as whether the count changed.

So deleting an identifier that does not exist returns deleted: false — not an error, not a 404. A response of deleted: false means nothing was removed, and the usual cause is a stale or mistyped identifier.

Read the response value rather than assuming the call succeeding means the snippet went.

The dry run counts rows

It returns before_count and after_count — how many snippets exist now, and how many would remain.

Equal counts mean the identifier matched nothing, which is exactly the case worth catching before a real call. A difference of one confirms the identifier resolves.

What it does not show is which snippet, or its content. Confirm that separately from the listing.

Confirm by content, not just by name

Snippet names are not unique, and identifiers are opaque strings. Both make it easy to delete the wrong one.

List the snippets, show me the CSS of the one you plan to delete, and wait for me to confirm.

For anything on a live site, that confirmation step is the whole safeguard.

Emptying a snippet is the reversible alternative

If the goal is to stop some CSS applying while keeping the record, use pom_theme_upsert_custom_css with the same identifier and empty content, or with the rules commented out.

The snippet stays, its name stays, and restoring it is one write. Prefer this when the styling might be wanted again — a seasonal campaign, an A/B test.

Delete only snippets that are genuinely obsolete.

The site's CSS rebuilds immediately

After the row is removed, the theme's save routine fires and the compiled stylesheet regenerates without that snippet. The response includes the resulting asset metadata.

The styling disappears from the site as soon as caches clear. There is no draft state.

Removing one snippet can affect others

Snippets share a compiled stylesheet, so CSS elsewhere may have been written assuming a rule from the deleted snippet was in effect — an override that is now overriding nothing, or a layout that depended on a reset.

After deleting, check pages beyond the one the snippet was named for.

After deleting

1. Check deleted is true.
2. List the snippets and confirm the right one went.
3. Confirm the generated stylesheet's timestamp moved.
4. Purge the cache, then load several page types.

Common problems

Related

• pom_theme_get_custom_css — read and keep it first
• pom_theme_upsert_custom_css — the reversible alternative
• Setting tools