What happens when content changes

Post-change invalidation connects the WordPress content lifecycle to POM Cache. HTML and progressive JSON each have their own opt-in setting because they are separate response stores.

Configure HTML and JSON independently

Open Settings → POM Cache → General.

For static pages:

1. Set Caching to Enabled;
2. Set Purge HTML on post changes to Entire site or Edited post single only.

For progressive archive batches:

1. Set Progressive JSON cache to Enabled;
2. Set Purge JSON on post changes to Enabled.

With Entire site, a qualifying public post change clears the current-site HTML tree. With Edited post single only, it removes only the exact single file for that post in every configured POM Translate language. Turning on one purge setting never implies the other.

Eligible changes

POM Cache reacts to normal WordPress events for a public, viewable post type, including:

• create or update;
• publish and relevant status transitions;
• trash, restore, or delete;
• change the terms assigned to the post.

This applies to custom post types such as products or events when WordPress treats them as publicly viewable.

POM Cache ignores revisions, autosaves, invalid post identifiers, and non-viewable post types. It also avoids processing the same post repeatedly within one request after a successful clear.

Invalidation scope

Choose the HTML scope according to where post data is rendered:

post save
├─ HTML entire-site purge → all current-site HTML cache removed
├─ HTML edited-single purge → only that post's localized single files removed
└─ JSON post purge enabled → all current-site progressive JSON removed

The targeted HTML option preserves unrelated cache files and never recursively removes child URL directories. It does not refresh the homepage, archive pages, taxonomy pages, navigation, sorted pagination, or other pages that render data from the edited post. Use Entire site when those representations must change with the post.

Term assignments belong to this setting

When an editor assigns a category or custom term to a post, the post's archive membership changes. That event is covered by the post-change switch.

The term-change switch covers editing the term object itself. Enable both when a site uses taxonomy-driven archives.

Test each store

1. Enable the intended settings;
2. Generate one HTML page and one progressive JSON batch;
3. Note both status counts;
4. Update a public post shown in those responses;
5. Save;
6. Refresh POM Cache → General;
7. Confirm the complete enabled store is empty, or that only the edited single files disappeared when using targeted HTML invalidation;
8. Request the page and batch again;
9. Verify the edit appears;
10. Repeat the requests and confirm cache hits.

Also test a term assignment if archive membership matters to your site.

Bulk content operations

A large import can save thousands of posts. With broad automatic invalidation enabled, each request or chunk can repeatedly remove newly generated files.

Plan bulk work as one freshness window:

1. Decide whether automatic purge should remain active during the import;
2. Prevent public warming midway if a mixed state would be harmful;
3. Complete all source changes;
4. Clear HTML and/or JSON once at the end;
5. Restore any temporarily changed purge setting;
6. Verify critical origin routes;
7. Invalidate the CDN after origin verification.

The plugin does not preload the cleared routes, so expect demand-driven regeneration.

Changes outside the post lifecycle

A global template setting, direct database write, external source, or custom field integration may change public output without a normal viewable post event. Use the manual tools unless that integration explicitly clears POM Cache.

See Understand site-wide invalidation to decide whether that manual clear should include one store or both.