How POM Cache works on WordPress multisite

In a WordPress multisite network, POM Cache combines shared bootstrap infrastructure with site-specific runtime values and cache trees. Network activation does not turn every site into one cache namespace.

Shared network components

The WordPress installation has one:

• wp-content/advanced-cache.php drop-in;
• WP_CACHE constant;
• POM_CACHE_HOME constant;
• POM Cache plugin directory;
• base Cache Location unless a site overrides it.

The drop-in runs before the normal active-plugin bootstrap, so it must be able to locate the network’s plugin files without depending on a particular subsite’s plugin screen.

Site-specific effective settings

POM Cache reads POM Framework settings for the current site first. If that site has no saved runtime or storage file, it can use the corresponding main-site value as a fallback.

The practical model is:

current site has an explicit value?
        ├── yes → use it
        └── no  → use the main-site effective value

Use Fix Configuration on a subsite when you intentionally want its effective values written as explicit site files. This action does not edit wp-config.php, install the drop-in, or copy .htaccess rules.

Cache namespaces by network topology

POM Cache combines hostname and public path:

• Subdomain network: site-a.example.com/ and site-b.example.com/ use different host branches.
• Mapped domains: brand-a.com/ and brand-b.com/ use their actual public hosts.
• Subdirectory network: example.com/site-a/ and example.com/site-b/ use different path branches.

The site’s configured home URL is also used by current-site statistics and purge operations. Keep domain mapping and canonical redirects synchronized with WordPress.

Admin locations

The normal network entry is:

Network Admin → Settings → POM Cache

For a site-specific override, open that site’s administration and use:

Settings → POM Cache

Only administrators can access the settings. License management is network-scoped, while cache contents and maintenance actions target the current site.

Purging one site versus changing shared content

General → Cache tools → Delete Cache removes the current site’s HTML tree. The Progressive JSON tool is separate. The admin-bar Delete Cache shortcut clears both stores for the current site.

If one editorial change affects several sites, clearing only the edited site may be insufficient. Examples include:

• a network-wide menu or footer source;
• a shared template setting;
• translated or syndicated content reused across sites;
• a common data service that changes output everywhere.

List the affected sites and purge each intentionally. POM Cache does not assume that every post update changes every site in the network.

Deploying Apache rules on multisite

The generated rewrite block is server configuration, not a per-site WordPress toggle. Review it against:

• the network’s document root;
• subdomain or subdirectory structure;
• mapped-domain behavior;
• proxy/CDN host forwarding;
• the actual Cache Location;
• the standard WordPress rewrite block order.

Test at least one homepage and one inner page on each topology in use. A rule that works for the main domain may still point to the wrong branch for a mapped or path-based site.

A multisite validation sequence

1. Confirm the drop-in and both constants show OK.
2. Choose two sites with distinguishable page content.
3. Enable HTML caching for each intended site.
4. Generate the same relative path on both while signed out.
5. Prove that the responses and storage branches remain distinct.
6. Log in to each site and confirm authenticated bypass.
7. Delete one site’s HTML cache and verify the other still has its files.
8. Repeat through the CDN, if present, after origin behavior is correct.

See How cache files stay isolated by host and site for concrete paths and Multisite cache clearing for maintenance.