Caching Plugins and the Acorn View Cache: Making WP Rocket or W3 Total Cache Play Nicely

You fixed the bug. You know you fixed it, because you read our post on Acorn’s view cache, recognized the exact symptom, ran wp acorn view:clear, watched it complete without an error, and even opened the compiled view cache directory to confirm it was empty. By every signal available to you, the fix is live. Then you open the page in a browser, the one your client or your QA person is looking at, and the old, broken markup is still sitting right there. Not a caching error message, not a PHP warning, just the exact same wrong output you started with, as if the clear command did nothing at all.

The natural next move is to clear the Acorn cache again, harder this time, the way you’d hit a stuck elevator button twice. That doesn’t help either, because the Acorn cache was never the problem the second time. Something else, a different cache, belonging to a different plugin, with a different clear button somewhere else in wp-admin, is quietly answering the request before your fix ever gets a chance to run. This post is about that second cache: what a general-purpose WordPress caching plugin like WP Rocket, W3 Total Cache, or WP Super Cache actually stores, how it’s genuinely different from the problem our Acorn post already solved, and the specific, confirmed steps to clear each one when it’s the thing standing between your fix and the page your visitor is actually looking at.

In this guide

• Two caches, not one: compile-time versus render-time
• Why these two layers normally don’t conflict at all
• The real problem: sequencing, not incompatibility
• The logged-in trap: why you tested fine and your visitor didn’t
• How to tell which layer is actually stale
• The troubleshooting flow, in order
• Quick reference: all three plugins side by side
• Clearing WP Rocket’s page cache
• Clearing W3 Total Cache’s page cache
• Clearing WP Super Cache
• Preventing this during active development
• Questions developers ask
• Where this leaves you

Two caches, not one: compile-time versus render-time

Our companion post on Acorn’s view cache covers one specific mechanism in detail: Acorn, the Roots package that brings Laravel’s Blade templating engine into Brndle, compiles every .blade.php file into plain executable PHP exactly once, then caches that compiled PHP at wp-content/cache/acorn/framework/views/ so it doesn’t have to re-parse Blade syntax on every request. That cache lives entirely inside the PHP execution of a single request. It answers one narrow question: when WordPress’s request lifecycle reaches the point of rendering a Blade view, does Acorn hand the renderer freshly-compiled PHP or a stale compiled copy from before your last edit? Nothing about that mechanism knows or cares whether the HTML that PHP eventually produces gets saved anywhere afterward.

A general-purpose WordPress caching plugin solves a completely different problem, one layer removed. WP Rocket, W3 Total Cache, and WP Super Cache exist because running a full WordPress request, loading plugins, firing hooks, querying the database, rendering templates, costs real time and real server resources, and most pages don’t need all of that work redone for every single visitor who asks for the same URL within the same few minutes or hours.

Their page cache feature, specifically, does this: the first time a given URL is requested, it lets the full request run exactly as it normally would, including every bit of Acorn’s own compiling and caching, then it takes the finished HTML response WordPress produced at the very end of that request and saves a copy of it. The next visitor who requests that same URL gets handed that saved HTML directly, often before WordPress, your theme, Acorn, or a single plugin hook has run at all.

On a well-configured site using WP Rocket or WP Super Cache, that saved copy is a literal static .html file on disk, served through an early-loading advanced-cache.php drop-in or a web server rewrite rule, specifically so that a cached hit never has to boot PHP at all. W3 Total Cache supports the same disk-based approach and also supports storing that same finished HTML in an object cache like Redis or Memcached instead, depending on how its Page Cache module is configured, but the artifact being stored is the same thing either way: a complete, already-rendered HTML page, not PHP, not Blade, not anything Acorn would recognize.

That’s the entire distinction this post rests on, and it’s worth stating as plainly as possible because almost every confusing symptom downstream traces back to blurring it: Acorn’s view cache operates before and during PHP execution, deciding what template logic actually runs. A page cache plugin operates after PHP execution has already finished, deciding whether PHP needs to run again at all for the next visitor. They are not two competing implementations of the same idea. They’re sequential stages of one request’s life, and a page cache plugin’s entire reason for existing is to make the later stages, including Acorn’s compiling, skippable for repeat visitors.

Why these two layers normally don’t conflict at all

It’s worth being honest about what this post is not claiming, because the framing “two caching systems on the same site” invites an assumption of built-in tension that doesn’t actually hold up. On a stable site that isn’t actively being edited, Acorn’s view cache and a page cache plugin cooperate without either one needing to know the other exists.

A visitor requests a page. If a page cache plugin has a saved copy, it serves that copy and nothing downstream, including Acorn, ever runs for that request. If there’s no saved copy yet, or the page cache plugin has excluded that URL, the full WordPress request executes: Acorn checks its own compiled-view cache, recompiles if the Blade source changed, renders the page, and hands back finished HTML. The page cache plugin, watching that same request from the outside, takes the finished HTML and saves it for the next visitor. Two caches, two completely different responsibilities, zero overlap in what each one stores, and no scenario on a quiet, unedited site where one produces output the other has to reconcile against.

This is also why the premise “these might be double-caching the same thing and fighting over it” doesn’t survive contact with how either system actually works. Acorn never writes HTML. A page cache plugin never writes compiled Blade PHP. There’s no shared file, no shared cache key, no shared storage location where a race condition or an overwrite could even occur. If you go looking for a genuine technical incompatibility between Acorn’s view cache and WP Rocket, W3 Total Cache, or WP Super Cache, specifically, you won’t find one, because there isn’t one to find. What you will find, and what actually generates support tickets, is simpler and far more common: a timing problem between when each layer gets refreshed.

The real problem: sequencing, not incompatibility

Walk through the actual sequence of events that produces the “I fixed it and it’s still broken” symptom, because every step in it is individually correct, and the bug only exists in the gap between them.

• Before your fix: a visitor requests a page with the bug in it. PHP runs, Acorn compiles the buggy Blade view (because that’s what the source said at the time), WordPress produces HTML containing the bug, and your page cache plugin, doing exactly its job, saves that buggy HTML to disk as the cached copy for that URL.
• You make the fix: you edit the .blade.php file. Acorn’s own automatic freshness check would normally recompile it on the very next request that needs it, and if it doesn’t, you correctly run wp acorn view:clear (or the blunter rm -rf wp-content/cache/acorn/framework/views/*) to force it. At this exact moment, the fix is real, correct, and sitting on disk as fresh, uncompiled source, ready to be compiled correctly the next time PHP actually runs for that view.
• You reload the page to check: this is the step where the two systems’ independence stops being reassuring and starts being the actual cause of the bug. Your page cache plugin doesn’t know you edited anything. It doesn’t watch resources/views/, it has no concept of a Blade file, and nothing about clearing Acorn’s cache tells it that its own saved HTML is now outdated. If the URL you’re testing still has a saved copy from before your fix, and nothing has purged it, the webserver or the cache plugin’s early-loading drop-in intercepts your request and hands back that old saved HTML directly. PHP never runs. Acorn never gets invoked.

Your fix did work. Acorn’s cache was cleared correctly and isn’t lying to you. The page cache plugin isn’t malfunctioning either, it’s doing exactly what you configured it to do. The bug isn’t in either layer, it’s in the fact that clearing one cache has no mechanism, by default, for telling the other that its own saved copy is now stale.

That’s a narrower, more specific, and much easier to fix problem than “these two caching systems are incompatible,” and naming it this precisely is the whole point of this post.

The logged-in trap: why you tested fine and your visitor didn’t

There’s a detail that makes this specific sequencing bug unusually good at hiding from the person who introduced the fix, and it’s worth calling out on its own because it explains a pattern you’ve probably already lived through without naming it: WP Rocket, W3 Total Cache, and WP Super Cache all default to not serving (or saving) the page cache for logged-in WordPress users. This is standard, long-documented behavior across all three, not an edge case, because caching an admin toolbar, personalized dashboard widgets, or any user-specific markup into a shared cache meant for anonymous visitors would be its own category of bug.

That default is exactly why this problem so often ships unnoticed: you, the developer, are logged into wp-admin while you test your fix. Your browser request bypasses the page cache entirely by default, goes straight through PHP, hits Acorn’s freshly-cleared view cache, renders correctly, and you see your fix working. You conclude the bug is resolved and move on.

Meanwhile, every visitor who isn’t logged in, which is to say nearly everyone, keeps getting served the old saved HTML from before your fix, because nothing about your logged-in test request ever touched, refreshed, or invalidated that cached copy. The report that comes back, “it’s still showing the old version for me,” isn’t the client being wrong or confused. They’re looking at the one request path your own testing never exercised.

The practical consequence: never consider a fix confirmed on a site running a page cache plugin until you’ve checked it logged out, in a private/incognito window, or from a second browser profile where you’ve never authenticated to wp-admin. That single habit catches this entire category of false “it’s fixed” conclusion before it reaches anyone else.

How to tell which layer is actually stale

Before touching any clear-cache button, it’s worth confirming which layer you’re actually looking at, the same way our Acorn post asks you to rule out unrelated causes before clearing that cache. Two checks, in order, tell you almost everything:

• Test logged out first. If you’ve only ever checked your fix while authenticated to wp-admin, you haven’t actually tested the page cache path at all, per the logged-in default described above. Open a private window, load the URL with no WordPress session active, and see whether the bug reappears. If it does, you’ve confirmed a page cache is involved.
• Append a throwaway query string to the URL, something like ?nocache=1, and reload. WP Rocket, W3 Total Cache, and WP Super Cache all default to skipping the page cache entirely for URLs carrying a query string, specifically because a query string usually implies dynamic, per-request content that shouldn’t be cached as if it were static. If the page renders correctly with the query string appended but not without it, that’s about as direct a confirmation as you’ll get: PHP and Acorn are producing the correct output right now, and whatever you’re seeing on the plain URL is a saved HTML artifact from before your fix, not a live rendering problem at all.

If both of those checks still show the bug, you haven’t actually fixed the underlying template yet, or Acorn’s own view cache genuinely didn’t clear, and you’re back in the territory our Acorn post’s symptom checklist already covers. Don’t skip straight to purging a page cache plugin on a hunch; confirm the layer first, the same discipline that post recommends for the view cache itself.

The troubleshooting flow, in order

1. Confirm the Blade fix actually compiled. Run wp acorn view:clear (or wp acorn optimize:clear if config or routes are also involved), the real, documented Acorn WP-CLI commands covered in full in our view cache post.
2. Test with the query-string trick, logged out. Load yoururl/?nocache=1 in a private window. This bypasses all three major page cache plugins’ default caching rules and shows you true, freshly-rendered PHP output.
3. If the query-string test shows the fix, but the plain URL still doesn’t, the page cache plugin is holding a stale copy. Purge it using the plugin-specific steps below.
4. Reload the plain URL, logged out, with no query string. This should now trigger a fresh PHP request, Acorn serving the already-correctly-compiled view, and the page cache plugin saving a new, correct copy for the next visitor.
5. If you’re deploying a fix that was already verified locally, remember that most local development environments don’t run a page cache plugin’s caching behavior at all, which is exactly why this class of bug tends to surface for the first time on staging or production, after a deploy, not during local testing. Build “purge the page cache” into your deploy checklist alongside clearing Acorn’s view cache, not as an afterthought you only remember after a client reports it.

Quick reference: all three plugins side by side

Before the plugin-by-plugin detail below, here’s the short version: what each plugin actually stores, and the fastest way to clear it.

Plugin	Stores finished HTML at	Clear via wp-admin	Clear via WP-CLI
WP Rocket	wp-content/cache/wp-rocket/, static files	Admin bar → WP Rocket → Clear Cache, or Settings → WP Rocket → Dashboard → Clear Cache	wp rocket clean --confirm
W3 Total Cache	wp-content/cache/ (disk) or a configured object cache (Redis/Memcached)	Performance → Dashboard → empty all caches, or Performance → Page Cache → empty this cache	wp w3tc flush all
WP Super Cache	wp-content/cache/supercache/HOSTNAME/, static files	Settings → WP Super Cache → Easy tab → Delete Cache	Plugin’s own flush command

Clearing WP Rocket’s page cache

WP Rocket’s page cache saves finished HTML as static files, organized per URL (and per device type, if mobile caching is enabled) under wp-content/cache/wp-rocket/, served through its own early-loading cache file so a cache hit never has to boot WordPress at all. Clearing it, confirmed against WP Rocket’s own documented cache-management behavior, works through any of these three equivalent paths:

• Admin bar, while logged in on the frontend: hover the “WP Rocket” item that WP Rocket adds to the WordPress admin bar and choose Clear Cache to purge the whole site, or the page-specific clear option when you’re viewing a single URL you want to refresh without touching everything else.
• wp-admin settings page: go to Settings → WP Rocket, and on the Dashboard tab use the Clear Cache button to purge every cached page in one action.
• WP-CLI, for deploy scripts and server access without a browser session:

wp rocket clean --confirm

That clears the entire cache; WP Rocket’s CLI also supports targeting specific URLs rather than purging everything, useful when you only need to refresh the one page you just fixed. Because WP Rocket excludes query-string URLs from caching by default, the ?nocache=1 diagnostic from the previous section works cleanly against it without any extra configuration.

Clearing W3 Total Cache’s page cache

W3 Total Cache’s own documentation describes its Page Cache module plainly: it stores the fully generated web page and serves that stored copy to later visitors instead of regenerating it per request, the same render-time artifact described throughout this post, confirmed directly from W3TC’s documentation. Where that stored copy actually lives depends on configuration, disk-based storage under wp-content/cache/ by default, or an object cache backend like Redis or Memcached if you’ve configured one, but the clearing mechanics are consistent regardless of storage engine:

• wp-admin, site-wide: go to Performance → Dashboard and use the empty all caches action to purge every cache module W3TC manages, page cache included, in one step.
• wp-admin, page cache only: go to Performance → Page Cache and use that module’s own empty/purge action when you specifically want to refresh rendered HTML without touching minify, database, or object caches you haven’t touched.
• Admin bar, when enabled: W3TC can add its own “Performance” menu to the admin bar with direct purge actions, a faster path than navigating into Performance settings when you just need a quick purge mid-task.

wp w3tc flush all

That empties every cache module; narrower commands exist for flushing just the page cache module when you want to leave other caches (like a database cache) untouched. W3 Total Cache also ships a debug mode specifically for its Page Cache module (under that module’s settings) that appends an HTML comment to the bottom of the page’s source showing when that specific cached copy was generated and which caching engine served it. Turning that on during an active troubleshooting session is a faster confirmation than the query-string trick, because it tells you the exact generation timestamp of what you’re looking at, not just whether it’s stale.

Clearing WP Super Cache

WP Super Cache takes the most literal approach of the three: it generates static .html files from WordPress’s dynamic output and serves those files directly, via mod_rewrite or PHP depending on configuration, bypassing WordPress’s own request processing entirely for the vast majority of visitors. A separate, PHP-based cache (named with a wp-cache- prefix) handles logged-in users, comment authors, and other cases that genuinely need per-visitor output, which is also the mechanism behind its own default of not serving the static cache to logged-in sessions.

• wp-admin, the fast path: go to Settings → WP Super Cache, and on the Easy tab use the Delete Cache button to clear every cached file immediately, confirmed directly against the plugin’s own documented behavior.
• wp-admin, inspecting before you delete: the Contents tab lists cached files directly, which is useful when you want to confirm a specific URL actually has a stale cached copy before clearing everything site-wide.
• File-level access: cached files live at wp-content/cache/supercache/HOSTNAME/, organized per URL; deleting a specific URL’s subdirectory there has the same effect as using the Delete Cache button, just scoped to one page instead of the whole site.
• WP-CLI: WP Super Cache registers its own command namespace, with a flush command available for scripted or deploy-time cache clearing without opening wp-admin at all.

Like the other two, WP Super Cache’s automatic clearing on post save or new comments has no awareness of a theme-level Blade edit, since that’s a file change outside WordPress’s own save hooks entirely. A template fix always needs a manual purge here, the same as the other two plugins, because none of these three plugins’ auto-invalidation logic is watching your theme’s source files.

---

Preventing this during active development

A few habits remove this entire class of confusion going forward, without requiring you to disable page caching anywhere it’s actually earning its keep:

• Exclude your active staging or dev domain from page caching while a template is under heavy iteration. All three plugins support URL or path exclusions; pointing that exclusion at a staging subdomain during a sprint of Blade fixes means every reload is a true, live PHP request, with Acorn’s own freshness check as the only cache you need to think about.
• Always verify logged out, not logged in, for exactly the reason covered above: your own admin session is, by every major plugin’s default, invisible to the cache layer that’s most likely to be hiding a stale fix from a real visitor.
• Make “purge the page cache” a named step in your deploy checklist, sitting right next to wp acorn view:clear, not something you only remember after the first bug report. One line, added to a deploy script, removes the entire sequencing gap this post is about:

wp acorn optimize:clear && wp rocket clean --confirm

(Swap in the matching clear/flush command for whichever page cache plugin a given site actually runs, from the quick-reference table above.)

• Use the query-string trick as your default “is this actually fixed” check whenever a page cache plugin is active, rather than trusting a plain reload. It costs one extra page load and tells you definitively whether you’re looking at live output or a saved artifact.

---

Questions developers ask

Does clearing Acorn’s view cache also clear my page cache plugin’s cache?

No. They’re unrelated systems with no shared code path. wp acorn view:clear only touches wp-content/cache/acorn/framework/views/. Nothing about that command notifies WP Rocket, W3 Total Cache, or WP Super Cache that anything changed, because Acorn has no integration with any of them and isn’t expected to.

Does purging the page cache also force Acorn’s view cache to rebuild unnecessarily?

No, and this is worth knowing so you don’t over-clear out of caution. Purging a page cache plugin just means the next visitor’s request has to run through PHP in full instead of being answered from a saved file. That request will hit Acorn’s view cache exactly as it normally would, serving the already-compiled view if nothing about the Blade source has changed since the last compile, or recompiling if it has. Purging the page cache doesn’t touch, invalidate, or force-recompile anything inside wp-content/cache/acorn/.

Why did this only show up after I deployed, and not while I was testing locally?

Most local development environments don’t run a page cache plugin’s caching behavior in any meaningful way, either because the plugin isn’t installed locally at all, or because its caching is disabled for a non-production environment. The sequencing gap this post describes only exists once a page cache plugin is actually active and already holding a saved copy from before your fix, which is a staging- or production-shaped condition, not a local one.

Should I clear both caches every single time I edit a Blade file?

On a production or staging site with a page cache plugin active, yes, treat both as one combined step: clear Acorn’s view cache first so the next real PHP execution renders correctly, then purge the page cache plugin so that correct render actually gets a chance to happen and gets saved as the new cached copy. The order between the two barely matters; what matters is doing both, since skipping either one leaves a path where a visitor can still see stale output.

Can I just exclude my own session from the page cache instead of purging it for everyone?

You already are, by default, in most configurations, since all three plugins skip the cache for logged-in users. That’s precisely why your own testing can look correct while the public-facing cached copy is still stale, so excluding yourself further doesn’t solve anything; it’s the opposite problem described in this post, not a fix for it. You need to purge the cache that anonymous visitors actually hit, not add another exclusion for the session that was never affected in the first place.

Does a CDN like Cloudflare add a third caching layer on top of this?

It can, and if one’s active in front of your site, it’s worth checking as a third, separate layer using the same logic: a CDN’s edge cache also stores finished HTML, at a point even further removed from your server than a WordPress page cache plugin, with its own separate purge mechanism (typically a dashboard action or API call on the CDN’s own side, not anything inside wp-admin). If purging WP Rocket, W3 Total Cache, or WP Super Cache doesn’t resolve a stale page and you’re running a CDN in front of the site, that CDN’s cache is the next thing to check, using the exact same query-string and logged-out diagnostics described above.

Could a page cache plugin ever cache the compiled Blade PHP file itself?

No. None of the three plugins covered here read or write anything inside wp-content/cache/acorn/, and Acorn’s view cache never produces or stores HTML. The two systems operate on entirely different artifacts at entirely different points in the request, which is also why there’s no file-level overlap for either plugin to accidentally corrupt or overwrite.

Is there a real incompatibility here, or is this just a misunderstanding?

It’s genuinely the latter, and worth saying directly rather than manufacturing drama where none exists: nothing about Acorn’s view cache and a page cache plugin is incompatible at the code or architecture level. The problem described in this post is a timing gap between two independently-correct systems, not a bug in either one, and once you know to purge both after a template fix, there’s nothing left to “fix” about the interaction itself.

What’s the fastest way to confirm a fix is really live for every visitor, not just for me?

Open the URL in a private or incognito browser window, with no WordPress session active, and skip any query string so the page cache plugin’s normal caching rules actually apply. If the fix shows there, it’s live for real visitors. If it doesn’t, but the same URL with ?nocache=1 appended shows the fix correctly, you’ve confirmed a stale page cache, not a template problem, and the plugin-specific purge steps above are the next step.

Does this apply to themes other than Brndle?

Yes, entirely. Nothing in this post is Brndle-specific; it’s true of Sage, Radicle, or any other theme built on roots/acorn, run on any site that also has WP Rocket, W3 Total Cache, or WP Super Cache active. The mechanism is Acorn’s own view cache meeting a general-purpose WordPress page cache plugin, not anything particular to Brndle’s own templates or block registration.

Where this leaves you

Acorn’s view cache and a page cache plugin were never going to conflict in the way “two caching systems on one site” makes you brace for. One caches compiled template logic before HTML exists; the other caches finished HTML after PHP has already run its course. They don’t compete for the same storage, the same cache key, or the same decision, and on a quiet site they cooperate without either one needing to know the other is there.

The actual failure mode is narrower and, once named, genuinely easy to avoid: clearing one cache doesn’t notify the other that its own saved copy is now outdated, and the default that hides your own fix from logged-in testing is the same default that makes the cached copy a logged-out visitor sees the one that matters. Confirm which layer you’re looking at with a query string and a logged-out window before you touch anything, purge both caches as one combined habit after every template fix on a site that runs a page cache plugin, and the “I fixed it but it’s still broken” report stops being mysterious and starts being a two-step checklist.