Updates, support, and safe maintenance

POM Cache updates arrive through the private POM update channel. Because the plugin participates in WordPress’s early bootstrap and Apache can serve files without PHP, maintenance must consider more than the plugin directory.

Before an update

1. Read the release notes for changes to cache format, the drop-in, settings, rewrite rules, invalidation, or progressive JSON.
2. Confirm the POM Cache site or network license is valid.
3. Confirm the subscription is active and the current domain remains authorized.
4. Back up:
   • wp-config.php;
   • the main .htaccess;
   • wp-content/advanced-cache.php;
   • any deployment-managed cache configuration.
5. Record the current HTML and JSON counts under General.
6. Test one dynamic request and one confirmed cache hit.
7. Schedule the update when a current-site and, if necessary, CDN purge is acceptable.

The common POM updater can advertise a new version even when the target plugin is inactive. On multisite, this includes discovery from the network update screen. POM Cache must be installed and have a valid site or network license for gated metadata and downloads.

Apply and verify the update

Use the normal WordPress plugin update flow, or the network plugin update flow on multisite.

After the files are updated:

1. Confirm WordPress reports the expected POM Cache version.
2. Open POM Cache → Advanced → WordPress configuration.
3. Confirm the installed advanced-cache.php still matches the expected source.
4. Compare the displayed Apache and progressive JSON rules when the release notes mention delivery changes.
5. Confirm existing settings retained their intended values.
6. Purge current-site HTML and JSON if rendered output, file format, or delivery behavior changed.
7. Invalidate the corresponding CDN objects where required.
8. Repeat the first-cache verification.
9. Test an authenticated request and one personalized route.

POM Cache never updates wp-config.php, .htaccess, or the deployed drop-in automatically. A successful plugin update does not prove those external files are current.

Routine maintenance

After editorial changes

If the relevant automatic purge switch is enabled, verify that the expected current-site cache was removed and regenerated. If it is disabled, use Delete Cache, Delete Progressive JSON Cache, or the admin-bar action according to the affected layer.

After theme, plugin, or template changes

Clear every cache layer that contains the old rendered output. A CSS-only asset change may be handled by asset versioning/CDN policy, while a template or server-rendered markup change normally requires HTML regeneration.

After changing domains or multisite mapping

Revalidate the license for the correct domain, review host/path rewrite assumptions, remove obsolete host-specific cache files through the supported scoped tools, and test the new public route from the origin outward.

Monitor storage

Review Cache Contents and Progressive JSON Cache Contents regularly. The plugin does not delete files simply because they are old. An unexpected increase can indicate more public routes, an uncontrolled URL pattern, an invalidation gap, or JSON responses that need a lower size limit.

Safe troubleshooting sequence

When visitors report stale or incorrect content:

1. Identify whether the response is HTML, progressive JSON, an image, or another asset.
2. Test the WordPress origin without relying on the CDN.
3. Compare a signed-out request with an authenticated request.
4. Check the exact host, path, query string, cookies, response headers, and cache timestamp.
5. Clear only the affected current-site layer.
6. Regenerate and verify the origin.
7. Invalidate the CDN object if the edge still holds the old response.

Avoid repeatedly deleting the whole network cache. A broad purge can hide the original scope and creates unnecessary regeneration work.

Information to include with a support request

Provide:

• POM Cache, WordPress, and PHP versions;
• single-site or multisite topology and the affected site domain;
• Apache, another web server, and CDN presence;
• the exact public URL with private tokens removed;
• whether the problem occurs signed out, signed in, or both;
• the relevant POM Cache settings by visible label;
• Advanced → WordPress configuration status;
• HTML and JSON cache counts;
• sanitized response headers;
• the cache-comment timestamp when present;
• the steps that reproduce the result;
• what changed immediately before the problem.

Never send:

• the license key;
• WordPress, hosting, CDN, or database credentials;
• raw authentication cookies;
• private customer data;
• an unredacted server log.

Recovery considerations

Deactivating POM Cache disables its runtime setting but does not delete the existing static files, rewrite rules, constants, or drop-in. Apache can continue serving a matching file while its rule remains active.

For a controlled diagnostic rollback:

1. bypass or invalidate the CDN;
2. remove or disable the POM Cache rewrite block;
3. delete the affected HTML and JSON cache through the supported tools;
4. disable the runtime switches;
5. restore the previous drop-in or constants only when the documented migration requires it.

Do not delete broad directories manually unless the exact current-site target and recovery plan have been verified.

Return to the POM Cache start-here chapter for the documentation path into HTML caching, Apache, JSON, invalidation, monitoring, and developer hooks.