Replies: 1
We are using a WordPress rewrite rule to have a custom URL alias the content from one of our feeds:
^show/podcast$ -> index.php?feed=podcast
When we turn on page caching in W3TC, it correctly caches the response from the feed in the proper cache directory according to our rewrite rule:
../cache/page_enhanced/www.site.com/show/podcast/_index_ssl.xml
Further requests are served directly from the cache as expected (notice the .xml extension since XML content was cached).
The issue arises when we try to purge the cached page in the Purge Policy. Whenever a new podcast post is created, we’d like to purge the cached feed response for the location above. We added show/podcast to the Additional pages section but the the cache is never purged for this URL. The only way to clear it is to do a Purge All Caches.
After some debugging, we determined the reason why it’s not getting purged per the policy config. When W3TC attempts to purge the Additional pages URLs it’s expecting HTML content was cached and the cache keys it’s trying to flush are like:
../cache/page_enhanced/<em>siteurl</em>/show/podcast/_index_ssl.html
(notice .html extension)
Nothing matches this key because it was XML content that was cached. It would be nice if W3TC could somehow determine the content type that was originally cached and correctly purge cache entries based on this. As it stands right now, we have to nuke the cache every time we publish a new podcast and can’t really benefit from scheduled posting since the feed going out to podcast directories isn’t automatically updated.
Is there any existing feature / config that could help us achieve this short of waiting for a future W3TC version?
Thanks kindly!