Apache delivery and PHP delivery compared
Apache and PHP can serve the same index.html, but they reach it at different moments. Apache is the faster path; PHP understands more of POM Cache’s runtime contract and provides clearer response diagnostics.
Direct Apache delivery
The recommended .htaccess rule runs before WordPress’s normal front-controller rewrite. It maps a public trailing-slash URL to the corresponding file below wp-content/cache/pom-cache/.
When it matches:
- Apache reads the file itself;
- PHP does not start;
- WordPress does not load;
- plugins cannot add late headers or run request hooks;
- the response does not contain POM Cache’s PHP hit header.
This path minimizes origin work, but the web-server conditions must stay aligned with the application’s safety policy. Treat the displayed rule as deployment configuration: review it, copy it manually, and test it after server or permalink changes.
Early PHP delivery
If the request reaches WordPress, the advanced-cache.php drop-in runs before the normal plugin bootstrap. It loads POM Cache from POM_CACHE_HOME, evaluates the request, validates the resolved path, and serves an existing file when permitted.
A successful response contains:
X-POM-Cache: Served static cache from PHP; phase=earlyIt also sends status 200, the site’s HTML character set, and the file length. A HEAD request receives those headers without a body.
This path still avoids the normal theme and plugin render, although starting PHP makes it more expensive than Apache.
Practical differences
| Behavior | Apache | Early PHP |
|---|---|---|
| Starts PHP | No | Yes |
| Loads normal WordPress request | No | No; the drop-in exits early |
Uses the same index.html |
Yes | Yes |
Adds X-POM-Cache |
No | Yes |
| Applies PHP tracking-parameter normalization | No | Yes |
| Can call WordPress/POM filters | No | Limited early runtime filters |
| Depends on copied rewrite rules | Yes | No |
Depends on WP_CACHE, POM_CACHE_HOME, and the drop-in |
Not for the hit itself | Yes |
Why the same URL may use different paths
A clean canonical URL such as /about/ may be served by Apache. The same page requested with a recognized campaign parameter may reach PHP because the supplied Apache rule requires an empty query string. POM Cache can remove tracking-only parameters from its internal request key and reuse the canonical file.
A content-changing query such as ?s=cache does not qualify for either shared page file. WordPress must handle it normally.
Cookies can also change the route. WordPress login, post-password, comment-author, and WooCommerce session/cart cookies are bypass signals, not cache variants.
Which path should you deploy?
Use both when the hosting stack supports Apache rewrite rules:
- Apache handles the clean, high-volume public hits.
- The drop-in provides a safe fallback when the web-server rule does not match.
- WordPress generates missing files and handles excluded traffic.
On Nginx or another server, keep PHP delivery working while an equivalent native rule is reviewed and installed by the server administrator. Never paste Apache syntax into an incompatible server.
Verify without confusing the layers
For PHP, inspect the response headers. For Apache, record the cache-generation timestamp in page source, reload the same URL, and confirm it remains unchanged. If a CDN is present, bypass or invalidate the edge during the origin test.
A direct hit is only successful when the response is also correct for an anonymous visitor. After enabling native delivery, repeat tests for login, password, cart, query-string, preview, HEAD, and representative multisite URLs.
Continue with Install and verify the advanced-cache drop-in or Copy the recommended .htaccess rules.