pom_cache_clear_site_cache: clear the site cache

Deletes this site's cached output so the next visitor triggers a fresh render.

Arguments

Permissions

mcp:write, plus manage_options. No write gate — see the chapter index.

include_json defaults to on

Omit it and both caches are cleared. Pass it as false to clear only the HTML cache.

That default is the right one for the usual case — you want the site to reflect a change — and it is worth knowing because "clear the cache" will do more than a reader of the argument list might assume.

The JSON purge is attempted only if the site supports it. On a site without it, include_json has no effect.

It is destructive, and that is fine

Classed destructive because it deletes files. But everything it deletes is generated output, rebuilt automatically on the next request.

No content, settings, media or configuration is touched. There is nothing to back up and nothing to restore.

The real cost is performance: the next visitor to each page waits for a full render. On a large or busy site that is a brief load spike, which is the only reason to think about timing.

Read the response, not just the success

Three fields come back:

So deleted: true with html_deleted: false is possible: the JSON cache was cleared and the HTML cache was not. Since the HTML cache is the one hiding your change, that combination looks like success and is not.

Check html_deleted specifically.

A json_deleted of null means the JSON purge was skipped — either include_json was false or the site does not support it. That is not a failure.

The statistics are reset regardless

Both cache statistics options are deleted as part of the call, whether or not the purges succeeded.

So empty statistics afterwards are not evidence the cache was cleared. They only prove this tool ran. Use html_deleted for the actual outcome.

The dry run reports intent, not contents

It returns which caches it would clear — HTML always, JSON if supported and requested. It does not list files, count them, or report how much cached output exists.

Its only real use is confirming whether the JSON purge is in scope on this site. For the size of the cache, read pom_cache_get_status first.

Given the operation is harmless and reversible by definition, the dry run matters less here than anywhere else in the documentation.

POM Cache only, and this site only

Untouched by this call:

• CDN caches. Usually the layer that actually keeps a change invisible.
• Hosting page caches — server-level or reverse-proxy caching.
• Object and opcode caches.
• Browser caches.
• Other sites in a multisite network. One site per call, from that site's own connection.

A change that is still not visible after this tool reports success is almost always the CDN. Purge that next.

Where it belongs in a workflow

Last, after the change and after verifying the stored data:

Update the global CSS, read it back to confirm, then clear the site cache.

Clearing before the change is finished just caches the old version again.

And clearing the cache is not a way to fix a change that did not save. If the data is wrong, the cache is not the problem — check the write first.

After clearing

1. Confirm html_deleted is true.
2. Purge the CDN.
3. Load an affected page and confirm it renders the change.
4. Load a second page to confirm the site is generally healthy.

Common problems

Related

• pom_cache_get_status — check availability first
• Clearing the cache after a change
• Limited cache access