Include better support for cache purging on page caching layer

[tcrsavage]

Use case:
We want to implement longer ttl caches + cache purging for some selected API request paths (generally single post/page/cpt api responses)

In order to support this, we need to be able to purge our object caches, the page cache and the CDN cache

Currently the page caching layer has 2 main limitations which make this difficult.

• Batache does not support s-maxage, Joe has made a PR for this already Support setting cache-control s-maxage batcache#26 . s-maxage control is a requirement in order to allow long TTL CDN caching with short TTL browser caching
• Currently batcache.php is not loaded via altis cloud, only advanced-cache.php
  This means the utility functions are not easily accessible, and have to be manually loaded from vendor, or code copied as custom functionality if we want to manually purge a page path from batcache --- this is a requirement to enable CDN cache purging with page caching enabled, as batcache url also needs to be purged beforehand to avoid CDN caching an old version of the page

[joehoyle]

Thanks @tcrsavage , following up from my comment in humanmade/batcache#26 (comment) too, yes-- the batcache.php plugin is not loaded. TBH I'm not totally confident that it works, as we've never used it. In https://github.com/humanmade/longcache/blob/main/inc/namespace.php#L115 I basically copied it out, and fixed up a couple things.

In order to support this, we need to be able to purge our object caches, the page cache and the CDN cache

Perhaps a nitpick, but you need to purge the page cache (batcache, which is stored in the object cache) and CDN cache. AFAIK (unless you have something custom) there's no other object caches that would need to be cleared.

Perhaps you could use Longcache directly if that's solving the same issue you have?

[tcrsavage]

Perhaps a nitpick, but you need to purge the page cache (batcache, which is stored in the object cache) and CDN cache. AFAIK (unless you have something custom) there's no other object caches that would need to be cleared.

We have a made a custom mysql backed persistent cache - with all the wordpress wierdness around cache invalidation via key changes, can't rely on cached data being in the object cache even with ttl unexpired

In https://github.com/humanmade/longcache/blob/main/inc/namespace.php#L115 I basically copied it out, and fixed up a couple things.

Cheers, we'll do the same in that case

Perhaps you could use Longcache directly if that's solving the same issue you have?

Our solution is quite a bit more over-engineered than this already, as we've gone for a primarily cron powered cache update mechanism, particularly important for our use case, as we do lots of bulk content updates, and we need a system which could recover from the CDN purge url count limits and API rate limits