Use the PHP cache fallback

The PHP fallback serves an existing POM Cache file through wp-content/advanced-cache.php. It is the default origin path when no native web-server rule matches and the recommended baseline before configuring Apache, Nginx, or a CDN.

It is not a second cache. It reads the same index.html that Apache would serve.

Required WordPress configuration

Open POM Cache → Advanced → WordPress configuration and confirm:

• Drop-in is OK;
• POM_CACHE_HOME is OK;
• WP_CACHE is OK.

Then open General → Runtime and confirm Caching is Enabled for the intended site.

The drop-in uses POM_CACHE_HOME because it runs before WordPress has loaded the normal plugin list. POM Cache reports these values but does not edit them.

Prove a PHP hit

Use a staging environment or an approved origin route where direct Apache delivery is not taking precedence.

1. Delete the current site HTML cache.
2. Request a normal published page while signed out.
3. Confirm an index.html is generated.
4. Request the identical canonical URL again.
5. Inspect the response headers.

The expected diagnostic is:

X-POM-Cache: Served static cache from PHP; phase=early

POM Cache also sends status 200, Content-Type: text/html with the WordPress character set, and Content-Length when the file size is available. A HEAD request gets the headers without the body.

What PHP checks

Before returning the file, the early runtime evaluates:

• GET or HEAD;
• backend and rejected WordPress routes;
• remaining query state;
• Customizer state;
• WordPress authentication, post-password, and comment-author cookies;
• WooCommerce session and cart cookies;
• JSON and linked-data Accept values;
• DONOTCACHEPAGE;
• the resolved file’s existence and containment below Cache Location.

This is more application-aware than a basic try_files rule, although it still runs before WordPress knows the queried object or current user capabilities.

Tracking-only queries

POM Cache can remove recognized attribution parameters in PHP. If no meaningful parameter remains, a campaign URL may share the canonical page:

/about/?utm_source=newsletter
→ /about/index.html

A content-changing query remains dynamic. This distinction is one reason to preserve the PHP path even when Apache handles clean URLs.

When the fallback is the final deployment

Using PHP-only delivery can be appropriate when:

• the hosting platform does not expose native rewrite configuration;
• POM Cache paths live outside a simple document-root mapping;
• domain mapping is controlled by an upstream platform;
• traffic volume does not justify a server rule;
• the native policy cannot reproduce the cookie and method boundary safely.

The page still avoids normal WordPress rendering on a hit. The tradeoff is that each request starts PHP and executes the early runtime.

If a file exists but PHP does not serve it

Check:

1. the three WordPress configuration statuses;
2. the current site’s Caching setting;
3. the exact request host and URL path;
4. cookies in the test browser;
5. meaningful query parameters;
6. request method and Accept header;
7. read permission for the file;
8. whether the resolved file remains below Cache Location;
9. whether a CDN already answered.

A miss or bypass should continue to WordPress. It should not produce a blank response.

Once this path is reliable, use Install the supplied Apache rules safely if direct delivery is appropriate.