Skip to content

Browse the documentation

LiteSpeed Cache and REST caching

Settings that save, then come back empty five minutes later. The cause is a cached REST response, not a broken save, and the fix has shipped.

updated

If saving settings shows a success message and a refresh shows empty fields — and then the values reappear on their own five or ten minutes later — your cache plugin is caching REST API responses. The save worked every time. What you were reading afterwards was a cached copy of the old settings. PixelCapi now sends no-store headers on all of its admin REST responses, which prevents this.

The symptom, exactly

  1. Change a setting, save. A success toast appears.
  2. Reload the page. The fields are empty or show the previous values.
  3. Save again, same result.
  4. Some minutes later, without any further action, the correct values appear.

That timing is the tell. Nothing that is genuinely failing to save fixes itself on a timer. A cache expiring does.

What is actually happening

The plugin’s admin screens read settings over the WordPress REST API. A page cache configured to cache REST responses will serve the response it captured before your change. The write succeeded and went to the database; the read came from the cache.

This was root-caused on a live site running LiteSpeed Cache. It is not specific to LiteSpeed in principle — any cache layer that treats REST responses as cacheable can do it — but LiteSpeed is where it shows up most often, because caching the REST API is one of its options.

The fix

All admin REST responses now carry no-store cache headers, so a compliant cache will not retain them. If you are on a current version you should not see this at all.

If you do:

  1. Purge the cache completely.
  2. Check whether your cache plugin has a “cache REST API” option and turn it off.
  3. Confirm the settings screen now reflects saves immediately.

The wider rule

Purge your page cache after every plugin update. Not because of this bug specifically, but because a cache serving pre-update HTML is the second most common cause of “I installed it and nothing happens” — see Events don’t show.

Caching and event IDs

There is a related, more dangerous cache failure that PixelCapi is designed to avoid entirely. If a plugin writes a per-visitor event ID into the page HTML, a page cache will freeze that one ID and serve it to everyone, and the platform will treat thousands of conversions as one repeated event.

PixelCapi puts no per-visitor event ID into cacheable HTML. The ID is generated in the browser at load time and sent to the server with the event, so byte-identical cached HTML still produces a unique matched pair for every visitor. That has been verified against a live cached site.

Was this page helpful?