POM Cache for developers

POM Cache exposes WordPress hooks and procedural helpers for integrations that need to classify requests, control cache writes, read or purge progressive JSON, or invalidate the current site's cache after a custom data change.

This chapter documents the supported extension points that integrations can rely on across compatible POM Cache releases.

Start with the request lifecycle

Read Architecture and execution phases before registering a callback. The earliest HTML and JSON hits can finish inside advanced-cache.php, before normal plugins load. A filter registered by a conventional plugin may affect WordPress-phase generation but cannot retroactively stop a response that was already served during that early phase.

For a new private or personalized feature, the safe rollout is:

1. make its public-versus-private contract explicit;
2. prevent unsafe cache writes before exposing the feature;
3. clear existing HTML and JSON artifacts that could contain the old representation;
4. verify anonymous and authenticated requests;
5. only then enable optional Apache or CDN delivery.

Extension guides

Request and HTML generation

• Control static cache eligibility
• Classify tracking parameters and Accept headers
• Filter rendered output
• Handle errors, 404s, and completion markers
• Understand cache-directory and filename filters

Invalidation

• Clear caches from application code
• Control site-wide deletion
• Integrate post invalidation
• Design bulk operations
• Coordinate translated-content changes

Progressive JSON

• Integrate JSON reads
• Integrate JSON writes
• Integrate JSON purging

Reference and safety

• Public hooks reference
• Path, output, and authorization safety

Compatibility rules

• Check function_exists() before calling a POM Cache helper from code that can run without the plugin.
• Use named integration contexts such as my_plugin_import, rather than pretending that a programmatic clear is a manual action.
• Treat filter context arrays as extensible. Read known keys defensively and ignore unknown keys.
• Use supported helpers instead of deleting files directly.
• Keep output and cache decisions deterministic for every visitor represented by the same cache key.
• On multisite, switch to the intended blog before calling a current-site helper, and always restore the original blog.
• Protect your own REST, AJAX, or administration action with capabilities, authentication, and a nonce before invoking a state-changing helper.

Public API boundaries

POM Cache's current HTML artifact is always index.html. The pom_cache_filenames filter belongs to a filename-list helper and does not rename the current reader or writer artifact.

pom_cache_json_purge_tags() currently accepts tags for compatibility but performs a full current-site JSON purge. It is not a targeted tag-index API.

These distinctions matter because code that assumes more selective behavior can leave stale content or delete more than expected. The individual guides state the actual scope and return value of every documented helper.