need help understanding the cache-override mechanism

Current cache override mechanism works by setting up common WP cache related flags, and sending one HTTP cache header. To recognize these flags and process them is something that depends on caching plugins, server side caching software, CDNs, ISP proxy caches and users’ devices/browsers. At any point these flags may be ignored by caching software, however any software built and configured up to standards would likely respect the flags.

This feature can be turned on or off in Patreon Settings menu. Default is on, if you turn it off it will just go away. Any conflict should go away as well.

This feature was added to prevent gated content from being cached so that when a patron unlocks a gated content he or she would not end up with a stale cached version of the content. Or, vice versa – a non-patron still accessing content s/he lost access to. This was causing pretty difficult to track support cases that went like “content doesnt unlock”, “locking doesnt work”, “Patreon doesnt work” and it was very confusing for creators and users alike.

For the code technicals:

Two methods in Patreon_Compatibility class set the flags for gated content.

set_do_not_cache_flag_for_gated_content method sets flags for internal WP code. The flags are each well commented so you can immediately see which plugin or flag do they belong to and search the flag via plugin documentation or just Google it.

Main one is DONOTCACHEPAGE that is common throughout WP ecosystem. It tells caching plugins to not cache the page. How the plugin does ‘not’ cache the content is up to itself.

Then there are a few specific flags for specific plugins. Like WPSC_SERVE_DISABLED to tell WP Super Cache to not use cached version of a gated content if cached version already exists. Otherwise with only DONOTCACHEPAGE flag WP Super Cache does not cache non-cached gated content when it is processing the cache, but if there is already a cached version, it just uses the cached version. WPSC_SERVE_DISABLED flag bypasses it entirely.

Its similar for other flags related to W3 Total Cache and Litespeed cache plugins.

modify_headers method in the same class sets a HTTP header no cache flag if the content is gated:

Cache-control: private, max-age=30, no-cache

This should tell every CDN, ISP proxy or device/browser that sees that header to avoid caching the content long time, and every device to revalidate the content if the version it has is older than 30 seconds. This should prevent hitting the server again if the user refreshes or goes back-forth immediately, but it should be short enough that a patron who lost access to some content should not access that content.

…

Now, dealing with not caching the gated part of the content and leaving rest of the page cached. That’s a bit complicated.

The gating happens by replacing the content with a gated content interface by hooking to the_content filter with very low priority number to ensure the gating kicks in last. So far so good.

But since there is nothing being done out of the ordinary WP hooks/filters, the content would behave like normal WP content and caching should work as it works for every other WP content at a given site.

So since i dont know what kind of server side caching you are using, im just going to hypothesize and use a makeshift example:

One way i can think of for doing that would be to use a server side cache or a cache plugin that allows compartmentalized caching of pages. Then somehow check whether the content is gated, and if so, leave the content part of the page not cached. Or however caching can be compartmentalized.

For this it must be checked that the post is gated or not. To have this happen server side will either involve triggering WP code (kinda beats the purpose) or using PHP or other code with Patreon API or a local cached version of patrons/pledges and decide whether to use caching or not depending on content being gated. That also beats the purpose since it could add some server load.

A best way can be to use a WP cache plugin’s any compartmentalized cching feature, and set up a flag for that plugin to not cache content part of a page if the content is gated. So every time that page is loaded, every part of the page will come from cache but the content part.

Anything that allows you to leave out caching for the content part of a specific page from server side cache will just work.

If you give more info on what kind of caching setup you have, something more relevant can be suggested.

…

I personally recommend finding a way to not cache gated content – at least the content part. And any other patron-specific part like dynamic widgets related to Patreon etc. Otherwise many patrons seem to encounter erratic ‘content does not unlock’ issues which come up and go away on their on depending on the behavior of caching at a given site.

Also s a sidenote – we provide support at official forum at https://www.patreondevelopers.com/c/patreon-wordpress-plugin-support

Thanks so much for that in-depth explanation. We’re using LiteSpeed Cache plugin on LiteSpeed server (obviously).

I was hoping to use either of the following tactics:
– ESI function to allow full-page cache for the entire page except the gated/ungated Patreon content area.
– Caching only for non-logged-in users. Logged-in users see uncached version of the pages.
– Caching everything for all users and praying somehow that Patreon content area stays uncached, or caches both versions (logged-in vs non-logged-in users).

Hooking to the end of the_content by maxing out the priority variable and using Patreon WordPress lock_or_not function on post id to check if the post should be gated, and based on the result wrapping the output in ESI code may work i believe?

<esi:inline name=”/gated”>
gated content here
</esi:inline>

… orsomething similar? Im not familiar with Litespeed or ESI.

– Caching only for non-logged-in users. Logged-in users see uncached version of the pages.

Making caching for non logged in users only could definitely reduce the load while also mitigating ‘content doesnt unlock’ issues. Even if it may occasionally cause newly gated or un-gated content to appear at the opposite state to anonymous visitors. We may look into this and experiment with it for future releases.