Understand cache generation after WordPress renders

Phase two creates static HTML. Unlike the early drop-in, it runs with WordPress loaded, so it can classify the queried page, observe redirects and status headers, and inspect the complete rendered document.

The visitor does not wait for a separate crawler. An eligible miss can populate its own cache entry.

When output buffering begins

POM Cache starts its HTML output buffer when:

• General → Runtime → Caching is enabled;
• the request is not a backend operation;
• no meaningful query string remains;
• the static runtime has not already been disabled.

Dynamic WordPress rendering then continues normally. POM Cache records conditionals for familiar frontend page types such as pages, posts, archives, terms, authors, the front page, and the posts page. It also notes REST/feed/robots/404 state and tracked redirect statuses.

The first inspection gate

At the end of the request, the output-buffer callback refuses storage when it detects:

• a fatal PHP error;
• DONOTCACHEPAGE;
• a meaningful query string;
• POST, PUT, or DELETE, or submitted form data;
• a preview;
• a rejected WordPress backend or PHP route;
• REST, robots, redirect, feed, or sitemap output;
• a JSON/ActivityPub/linked-data representation;
• an unrecognized page type under the default policy;
• a WordPress, password, comment-author, or WooCommerce bypass cookie.

Developers can inspect or transform the buffer at this stage with the documented output-buffer filter, but public deployment should not use that hook to disguise an unsafe request as cacheable.

The final document gate

A response that passes the first gate still needs to be a complete cache document. POM Cache does not write when:

• the buffer is empty;
• the request is a 404 under the default policy;
• no recognized document-ending marker is present;
• the runtime was disabled before the write;
• a bypass cookie is present at the final check.

For standard pages, the important completion signal is a closing </html> tag. This prevents a truncated PHP response from replacing a previously good static page.

Building the stored copy

POM Cache keeps the visitor’s rendered buffer and the storage buffer separate. It adds diagnostic comments to the copy that will be written:

<!-- Page generated in 0.123 seconds. -->
<!-- Cached page generated by POM-Cache on 2026-07-27 12:34:56 -->
<!-- pom cache -->

The values above are examples. The page-generation duration and timestamp reflect the request that created the file.

Because the first visitor receives the original WordPress buffer, these storage comments are most reliably observed on a later hit.

Atomic publication

The file operation follows this sequence:

1. calculate the host-and-path directory;
2. create missing directories;
3. resolve the real directory and verify cache-root containment;
4. write the complete storage buffer to a uniquely named .tmp file;
5. close it and reject it if its size is zero;
6. rename it to index.html.

Other visitors should therefore see either the previous complete file or the new complete file, not a partially written response.

Automatic invalidation hooks

When the corresponding runtime switches are enabled, phase two also registers broad current-site purges for:

• relevant public post saves, deletions, trashing, publishing, status transitions, and term assignments;
• term creation, editing, deletion, and supported term metadata changes.

Revisions, autosaves, and non-viewable post types are not treated as public-page changes in the post purge path.

The hooks delete the site tree; they do not attempt to predict the one page affected, because content can appear in archives, navigation, related items, or shared templates.

Verify a generated file

1. Delete the current site HTML cache.
2. Request a simple published URL once while signed out.
3. Confirm Cache Contents reports a file.
4. Locate its index.html according to the public cache file layout.
5. Confirm it contains the complete page and the three diagnostic comments.
6. Request a deliberately incomplete, redirected, or 404 URL and confirm it does not replace/create a normal file.

For developer filters that participate in these gates, use Output-buffer filters.