Clear JSON after post changes

Enable post invalidation when progressive archives display information that editors can change on a post, page, product, or another public post type.

Enable the switch

1. Open Settings → POM Cache → General.
2. Find Progressive JSON runtime.
3. Confirm Progressive JSON cache is Enabled.
4. Set Purge JSON on post changes to Enabled.
5. Save.

The switch is independent of Purge HTML on post changes. Enable both when the archive page shell and its later JSON batches can contain the edited information.

Changes covered

For a public, viewable post type, POM Cache responds to the normal WordPress lifecycle, including:

• saving or updating a post;
• publishing or changing publication status;
• trashing, restoring, or deleting it;
• assigning or changing its taxonomy terms.

Revisions and autosaves are ignored, as are non-viewable post types. Repeated notifications for the same post within one request are consolidated to avoid clearing the same tree over and over during that request.

Scope of the purge

A qualifying change clears the complete progressive JSON cache for the current site.

It does not try to delete only the edited post's file because that post may appear in:

• a main post-type archive;
• several taxonomy sections;
• more than one page of ordered results;
• translated archive variants;
• multiple contexts with different templates or batch sizes.

Broad current-site invalidation favors correctness. Other sites in the multisite network have separate namespaces.

Taxonomy assignment is a post event here

Changing the categories, tags, or custom terms assigned to a post follows Purge JSON on post changes, because the object being reclassified is the post.

Changing the term itself—its name, slug, hierarchy, existence, or supported ordering metadata—follows Purge JSON on term changes. Many sites should enable both switches.

Verify the behavior

1. Generate at least one progressive JSON file;
2. Note the file count under Progressive JSON Cache Contents;
3. Edit a public post that appears in the archive;
4. Save the change;
5. Refresh the POM Cache settings screen;
6. Confirm the current-site JSON count is zero;
7. Request the archive batch again;
8. Confirm the edited content appears and a new cache file is generated.

If a CDN caches the JSON URL, origin invalidation alone may not update the public edge immediately. Verify the origin first, then follow Decide when the CDN must also be invalidated.

High-frequency editing and imports

Because the purge is site-wide, repeated saves during a bulk import can repeatedly empty the tree. For a controlled bulk operation:

1. Decide whether temporary staleness is acceptable;
2. Disable the automatic post purge only for the planned window if your operational policy permits it;
3. Complete the import;
4. Select Delete Progressive JSON Cache once;
5. Restore the automatic setting;
6. Verify important archives and CDN paths.

Do not leave automatic freshness disabled accidentally.

When to clear manually as well

Use a manual clear after a change that affects rendered archive cards but does not follow a normal public post save—for example, a global archive template setting, a custom integration that changes output externally, or a direct data operation that does not emit WordPress lifecycle events.

The manual process is documented in Clear the JSON cache manually.