Handle errors, 404s, and completion markers

POM Cache excludes fatal, incomplete, and most error-like responses by default. Extensions should preserve that conservative behavior unless an error page has a deliberate freshness and invalidation strategy.

wp_die() responses

When POM Cache's wp_die handling is selected, pom_cache_disable_cache_on_wp_die defaults to true. POM Cache then defines DONOTCACHEPAGE.

add_filter( 'pom_cache_disable_cache_on_wp_die', '__return_true' );

There is usually no reason to add this callback because it restates the default. The hook exists for exceptional integrations, but returning false can allow a failure or authorization response to proceed toward normal cache evaluation. Do not disable the safeguard globally to cache a custom public page; build that page through a normal WordPress route instead.

404 caching

One shared public 404 document is enabled by default when HTML caching is enabled. Disable its generation and delivery for a dynamic 404 template with:

add_filter( 'pom_cache_404', '__return_false' );

The default is equivalent to:

add_filter( 'pom_cache_404', '__return_true' );

This filter controls the shared document, not per-URL 404 files. Missing URLs are never written to the ordinary page-cache tree, including when the filter returns true. WordPress resolves each request and completes redirect handling before reuse; newly available pages are not hidden by the shared document. Existing callbacks returning false continue to force dynamic rendering.

Only enable 404 caching when:

• the 404 body is completely public and deterministic;
• no visitor-specific data or expiring form tokens are required;
• manual refresh after changing the shared design is acceptable;
• the CDN preserves the response's 404 status and no-cache policy;
• you have tested a URL that changes from missing to available.

The filter does not receive the requested path, so it is not a path-specific policy by itself.

The source document comes from a signed anonymous loopback to a fixed missing path, never from an arbitrary visitor response. Failed or personalized responses are not promoted. The separate store survives ordinary purges; use Settings → POM Cache → General → Cache tools → Delete 404 Cache to refresh it. See Shared 404 behavior for language, request, and generation requirements.

Completion markers

Before writing, POM Cache matches the response against pom_cache_eof_tags. The default regular expression recognizes completed HTML, RSS, feed, URL-set, or XML output:

/(<\/html>|<\/rss>|<\/feed>|<\/urlset|<\?xml)/i

An integration that produces a different complete public format can extend the expression:

add_filter(
    'pom_cache_eof_tags',
    static function ( $pattern ) {
        return '/(<\\/html>|<\\/rss>|<\\/feed>|<\\/urlset|<\\?xml|<\\/catalog>)/i';
    }
);

Return a complete valid regular expression, including delimiters and modifiers. Do not concatenate unescaped user input into it.

Adding a weak marker such as a common <div> or a single closing brace can allow truncated responses to be cached. The marker should prove that the intended document finished rendering.

Other exclusions still apply

Passing the completion check or enabling 404s does not bypass:

• request-method checks;
• query and preview exclusions;
• REST, feed, robots, redirect, or response-type classification;
• bypass cookies;
• DONOTCACHEPAGE;
• master runtime settings;
• fatal-error detection;
• non-empty buffer requirements.

Test errors with the exact status code, headers, and body. A browser that displays an attractive error document can still be returning a redirect, CDN-generated page, or wrong HTTP status.