Web-server integration

POM Cache can reuse a generated file in two ways: PHP can serve it through the WordPress drop-in, or the web server can map the public URL directly to the file. Direct delivery removes PHP and WordPress from the hit, but it also moves the safety decision outside the plugin.

This chapter is for site owners and server administrators who already have a working PHP cache path. Establish that baseline before adding native rules.

What POM Cache supplies

Under POM Cache → Advanced, the plugin displays two read-only blocks:

• Apache rules → Recommended .htaccess rules: direct delivery for static HTML.
• Progressive JSON Apache rules → Recommended progressive JSON .htaccess rules: direct delivery for compatible progressive archive data.

POM Cache never writes the main .htaccess. Saving plugin settings does not install, update, reorder, or remove either block.

The HTML rule and the Progressive JSON rule are independent. The HTML block maps a trailing-slash page URL to pom-cache/{host}/{path}/index.html. The JSON block recognizes its supported JSON routes, maps them below pom-cache-json, and supplies JSON response headers when mod_headers is available.

Why server rules require deliberate review

A native hit happens before WordPress can inspect:

• the authenticated user;
• route conditionals;
• DONOTCACHEPAGE;
• plugin-specific personalization;
• the current POM Cache setting;
• PHP delivery filters.

The effective Apache, proxy, and CDN policy must therefore preserve the same public-only boundary as PHP. A rule that finds a file but ignores method, query, cookie, host, or path differences is not an acceptable cache rule.

Recommended rollout

1. Understand why files are served before PHP.
2. Prove the PHP cache fallback on representative pages.
3. Back up and review the server rules.
4. Install the supplied Apache rules safely.
5. Verify direct Apache delivery.
6. Recheck login, passwords, commerce state, query strings, methods, hosts, and multisite paths.

If the site does not use Apache, follow Plan an equivalent configuration on non-Apache servers. POM Cache does not generate Nginx, Caddy, IIS, or platform-specific configuration.

Modules and permissions

The HTML block depends on Apache mod_rewrite. .htaccess processing must permit at least FileInfo overrides; otherwise rewrite directives can be ignored by the server.

The Progressive JSON block additionally uses mod_headers for Content-Type, Cache-Control, and Vary. Its rewrite still requires mod_rewrite.

Module checks wrapped in <IfModule> avoid an Apache syntax failure when a module is missing, but they can also leave the feature inactive. Verify behavior rather than assuming the block ran.

A separate WebP integration

Same-folder WebP delivery is not part of either POM Cache block. It is an optional web-server pattern with three owners:

1. an image process creates the alternative file;
2. Apache negotiates it for a compatible browser;
3. the CDN keeps the original and WebP responses in distinct variants.

POM Cache does not convert images or rewrite image URLs inside cached HTML. Start with WebP delivery responsibilities, then use the same-folder Apache example.

After installing that optional rule, use Verify WebP negotiation and fallback to prove that compatible browsers receive the alternative file while other clients still receive the original image.

Production acceptance criteria

Before declaring native delivery ready, confirm:

• a clean anonymous read can receive the existing file;
• a miss falls through to PHP and WordPress;
• login, password, comment-author, and WooCommerce state bypasses;
• meaningful queries do not receive the canonical page;
• only safe read methods can reach static HTML;
• domain-mapped and subdirectory sites resolve to their own trees;
• disabling or purging POM Cache cannot leave an unexpected upstream copy;
• the CDN does not hide the origin test.

For the difference between Apache and PHP evidence, see Apache delivery and PHP delivery compared.