There are two ‘expires’ setting you can configure in W3 Total Cache, one is the static page cache on your server, the other is the browser cache settings that the browser will use to decide whether to use a local cache for a page, or to re-request that page from the server.
-
W3 TC should be invalidating the index, category and tags pages on the server cache when you insert or update a new post. If your archive pages are not automatically generated through the ‘normal’ wordpress url rewriting — if, for instance, you have archives that actually live in a custom page-template, W2 TC may not recognize that page as a category archive page, and may not automatically invalidate it. In this case you can look at adding a post-save action to force-invalidate specific pages. From the FAQ:
How can I flush the cache without using the WP Admin interface?
It’s possible to empty the entire cache or simply purge the cache of a single post / page:
Purge the entire page cache: if (function_exists(‘w3tc_pgcache_flush’)) { w3tc_pgcache_flush(); }
Purge a single post / page by passing it’s ID:
if (function_exists(‘w3tc_pgcache_flush_post’)) { w3tc_pgcache_flush_post($post_id); } -
Frequently the behavior you describe is the result of the browser respecting the expires tag in the headers as the page is served. Even though the server side cache was invalidated, the browser doesn’t actually request a new page, but uses its locally cached version, based on the http headers for the URL. The solution, in this case, is to reduce the time to expires for the browser cache.
You can control the length of this on the browser tab of the admin settings panel for W3 TC.