Caching behavior for logged-in users

POM Cache’s default HTML policy is anonymous-first. A WordPress authentication cookie prevents early static delivery and prevents the authenticated response from being written over the public index.html.

The cached file can remain on disk for signed-out visitors; bypassing it does not require deleting it.

Why authentication changes the decision

A logged-in response can differ even when its URL is identical:

• WordPress may add the admin bar;
• themes may show edit or account links;
• menus can depend on role or membership;
• private, draft, or restricted data may become visible;
• nonces and user-specific values can appear in markup.

POM Cache does not create a file per user or role. Without a variant dimension in the cache key, sharing any of those versions would be unsafe.

Where the bypass happens

The early drop-in recognizes WordPress authentication cookie names before the normal user object is available. When it finds one, it marks the request non-cacheable and returns control to WordPress.

After rendering, the output-buffer gate checks again. That second check prevents a logged-in page from being published if authentication state appeared or changed during the request.

Direct Apache and CDN rules must implement the same cookie boundary because they run before PHP can protect the request.

Test public and authenticated views separately

1. Choose a page that visibly changes for an editor, such as one with the admin bar or an edit link.
2. Delete the current site HTML cache.
3. Open the page in a clean private window and allow it to generate.
4. Reload privately and prove a public hit.
5. Open the same canonical URL in a different browser profile where you are logged in.
6. Confirm the authenticated controls appear correctly.
7. Confirm the response is not an early POM Cache hit.
8. Return to the private window and verify that the anonymous file is still correct.

Do not move cookies between the two profiles. A test window that was once logged in may retain a bypass cookie after logout.

Password and comment state is treated similarly

Post-password and comment-author cookies also bypass the static page. They do not necessarily mean the visitor has a WordPress account, but they can change page output or reveal protected content.

Use a fresh cookie jar when validating the anonymous cache after testing those features.

Late delivery is opt-in, not automatic

Once WordPress has loaded, POM Cache knows the user, capabilities, and queried object. It performs a late file lookup, but the default policy does not serve the file from that phase.

A developer can permit a tightly scoped late case with pom_cache_can_serve_cached_file. Any such policy must prove that:

• the selected route is identical for the allowed authenticated audience;
• no nonce, admin bar, edit link, private content, or account data enters the file;
• direct Apache and CDN layers do not bypass the application decision;
• the rule is covered by a repeatable leak test.

This is an extension point for exceptional public-equivalent views, not a general “cache logged-in users” switch.

If a logged-in visitor sees public cached content

Treat it as a delivery-chain incident:

1. capture the URL, response headers, and cookie names without exposing their values;
2. identify whether the response came from the CDN, Apache, or PHP;
3. disable the unsafe upstream cache route;
4. purge the origin HTML and relevant edge entries;
5. verify the effective cookie exclusions;
6. retest with separate anonymous and authenticated sessions.

Use Logged-in content leak check for the full diagnostic workflow.