Use the WordPress JSON fallback

The WordPress read fallback reuses a stored progressive archive response after WordPress and the POM Theme router have loaded. It is slower than Apache or early PHP delivery, but it avoids rebuilding the archive query and item templates.

When the fallback is useful

Keep WordPress read fallback enabled when:

• your host does not allow custom Apache or Nginx file mappings;
• the advanced-cache.php drop-in is temporarily unavailable;
• a request legitimately passes the early path but remains eligible at the theme router;
• you want a safe compatibility layer during rollout;
• you are diagnosing whether the stored file itself is valid.

It is enabled by default as a child setting, but the Progressive JSON cache master switch must also be enabled.

What happens at the router

When POM Theme receives a progressive archive route, it does not blindly return a file with the same name. It rebuilds the expected public context and verifies:

• the post type and archive mode are valid;
• the context hash in the URL matches current settings;
• the items-per-page value in the filename matches the current context;
• the context is eligible for shared caching;
• the request has no query parameters when a cache read is attempted.

POM Cache then checks the corresponding stored file:

• path is safe and contained in the current site's JSON tree;
• file exists and is readable;
• size is greater than zero and within Maximum JSON file size;
• contents decode as valid JSON.

Only then does the router reuse it.

Recognize the result

A fallback hit can include:

X-POM-Progressive-Archive-Cache: hit

Because WordPress has already loaded, it will not include:

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

That distinction helps locate the active layer:

An Apache hit may have neither diagnostic header because PHP did not run.

Test the fallback deliberately

1. Generate a JSON file with normal runtime settings.
2. Set PHP early static serving to Disabled.
3. Ensure the optional Apache JSON rules are absent or temporarily disabled.
4. Keep Progressive JSON cache and WordPress read fallback enabled.
5. Request the exact clean JSON URL.
6. Confirm X-POM-Progressive-Archive-Cache: hit.
7. Confirm the returned archive items match the current site and locale.
8. Re-enable PHP early serving after the test if it is your intended production path.

Do not leave the site in a slower diagnostic configuration accidentally.

Reads and writes are independent

Turning off WordPress read fallback stops this layer from reading a file. It does not:

• disable PHP early delivery;
• disable Apache delivery;
• delete existing JSON;
• disable JSON writes.

Likewise, turning off JSON writes does not prevent the fallback from reusing files already on disk. These independent controls make controlled migrations possible, but they can also make a test confusing. Record the state of all four runtime switches.

Limits of this layer

The fallback cannot avoid the WordPress bootstrap, so it is not the lowest-latency option. It also cannot rescue a route whose current context no longer matches the path; that request must be generated from the current configuration.

If every request reports generated-cacheable, check that JSON writes succeeds and that the next read resolves to the same site, locale, and relative path. If it reports generated-dynamic, investigate why the archive context is not eligible rather than focusing on filesystem permissions.

See How a JSON cache request is served for the complete layer order and Troubleshoot progressive JSON caching for a symptom-based checklist.