Understanding the WP_CACHE Constant

WP_CACHE is a switch for loading one file, and nothing else. When it is true, WordPress includes wp-content/advanced-cache.php very early in the bootstrap — before plugins, before the theme, before most of core. That file, placed there by a caching plugin, is what does the actual work. The constant on its own caches nothing, speeds up nothing, and on a site with no such file does nothing at all.

The line

define( 'WP_CACHE', true );

Caching plugins write this into wp-config.php during activation and usually remove it on deactivation. Managing it by hand is not normally useful, and the two situations where people do are both mistakes: setting it hoping for a speed improvement, and leaving it set after the plugin is gone.

The failure that takes a site down

Removing a caching plugin by deleting its directory — rather than deactivating it first — leaves two things behind:

• WP_CACHE still true in wp-config.php.
• wp-content/advanced-cache.php still present.

That drop-in is loaded before anything else and typically refers to classes from the plugin that no longer exists. The result is a fatal error at the earliest point in the bootstrap, which means the dashboard is gone too. It presents as a white screen with no way in.

The repair is two file operations, both doable over SFTP without a working site:

1. Delete wp-content/advanced-cache.php.
2. Set WP_CACHE to false in wp-config.php, or remove the line.

Check for wp-content/object-cache.php while you are there. It is a second drop-in that some caching plugins install, it is not governed by this constant, and it causes the same class of failure when orphaned.

The two kinds of cache people mean

The word covers two different mechanisms, and WP_CACHE only relates to the first:

A page cache serves a saved copy and never runs the query. An object cache still runs WordPress but avoids repeating database work. They are complementary, they fail differently, and only one of them is what this constant loads.

Why it loads so early

The point of a page cache is to avoid work. A cache that loaded after plugins and the theme would already have paid for most of the request before deciding it had a saved copy. Loading advanced-cache.php before that makes it possible to serve HTML and exit.

The consequence is that anything wrong in that file breaks the site completely rather than partially, and no plugin can intervene because none have loaded. That is why an orphaned drop-in is disproportionately destructive relative to its size.

Caching and logged-in users

A correctly configured page cache excludes logged-in sessions, the cart, the checkout and any personalised page. When it does not, one visitor's page is served to another — which on a store means someone else's basket, and on a membership site means content the viewer did not pay for.

If a site is showing the wrong content to the wrong person, this is the first thing to examine, before anything in the application. The routine for flushing and retesting is clearing the WordPress cache.

Checking what is actually installed

Three things tell you the real state, and they can disagree:

1. Whether WP_CACHE is defined and what it is set to.
2. Whether wp-content/advanced-cache.php exists, and which plugin it names in its header.
3. Which caching plugin is active, if any.

A site where the drop-in names a plugin that is not installed is in the broken state described above, even if it currently loads. A site with the constant set and no drop-in is doing nothing, harmlessly. A host-level cache in front of the site is a fourth layer that none of these three reveal, and it is a common reason changes appear not to take effect.

Verify

Load a page twice and compare response headers for a cache indicator, then make a visible change to the page and reload. If the change does not appear, something is serving a saved copy — which is the constant doing its job, or a host cache doing it.

Then log in and load the same page. A personalised page served from cache is a misconfiguration to fix before anything else, and it matters more than the speed the cache was installed for, in the same way an incorrect price matters more than a fast product page.