W3 Total Cache allows for fine-tuning of page and object caches, and can automatically prime the cache. For example see this thread:
At a lower level, caches are primed by loading the pages. W3TC offers an option to automatically pre-load pages in the background. The same could be done with any script that iterates the site map and loads the pages after clearing the cache.
Right, we are using LiteSpeed Cache and NOT W2TC, and this question is NOT about the page cache but the object-cache used by pods! So please do not hitchhike the ticket.
The fundamentals are the same.
Loading the page will prime all caches, including object cache.
Whether you do it with a browser, with a scripted cURL, or with W3TC’s solution.
- This reply was modified 39 minutes ago by .
not really. So the loading the page will prime the PAGE-cache which in turn loads the pods data from cache also then prime the OBEJCT-cache if the data is not already in the cache. Then the page stays in cache for one week (in our setup).
Now we will have our nightly data-job which at the end will flush the object-cache. But the final pages now will stay in the cache and “pinging” the page will still result into a cache-hit in the page-cache.
Now the esi comes into, so once we expire the price-block any subsequent page load will create a cache creation for the esi which in turn also will go to the object-cache and prime it.
But in fact we will produce and much higher traffic on the web-server but warming up the object-cache directly. Currently we think about to warm the cache by calling all pods with changed prices to make this happen.
But the question here was actually to check if a function like the above was already implemented somehow.
best
Carsten
As far as I know, it’s not possible to clear the object cache per-page, so my recommendation would be the same: flush the cache, run your updates, then load each page after it’s updated to prime the cache.
The Pods object cache is flushed with wp cache flush. It’s the standard WordPress object cache.
Scott or Jory may be able to correct me, but as far as I know, the object cache for Pods can’t be flushed at the page level.
So my recommendation is still that you stop “hitchhiking” on a caching solution that doesn’t automate priming the cache, and instead try W3TC, which does.
Or simply include a cURL call to the pages being updated yourself.
W3TC will also allow you to set an appropriate page cache expiry.
Or you can cache a baseline page and load the dynamic data via AJAX.
hmm, beside wp_cache_set and wp_cache_get there is also wp_cache_delete. BUT the flushing is already done, and now we need to warm-up the drained objects again …
One warms up the objects by loading the page, through a browser, cURL, wp_remote_get() or any other scripted request.
One could also write a PHP script that iterates only over the objects in question, but then you’re looking at a very custom solution.
The simplest solution is still likely W3TC.
This gist might be helpful if one is interested in managing caches for specific objects manually:
https://gist.github.com/danlamanna/1325185
ok, thx this is a good one. I have to check, if we can find a way to only “de-cache” the objects which had changed prices …
Building on the logic of the Gist, one might disable the Pods object cache and then wrap each price query with a cache assigned to a unique cache_group ID. This would allow the object cache for each to be cleared selectively.