4

I noticed recently that the full page cache for category pages isn't getting updated. Other pages seem to work fine (home, posts, etc) but categories cache files stay untouched for days until I manually rm -rf them.

What could cause this?

Plugin updated to latest version.

3 Answers 3

6
+50

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.

  1. 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); }

  2. 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.

6
  • Point #1: the category pages are served via the standard wordpress routing as specified in the permalink settings and handled by the archive.php page template. If I manually remove them, they are correctly recreated in the page cache directory, so I guess W3tc knows well about them Aug 13, 2011 at 11:07
  • Point #2: that's not the case as I can see the _index* files in the page cache directory as being old and clearly not invalidated server side. Anyway, if this was a problem, it could be fixed by a hard refresh on the browser (but it's not) Aug 13, 2011 at 11:08
  • hard refresh on the browser? Depending on the browser involved, it would require manually clearing the cache to get the browser to fetch the page from the server, rather than pulling it from the local cache on disk. There's also potentially caching proxy servers that might exist between you and the server - that could also come into play - which could be the case in a corporate setting.
    – marfarma
    Aug 14, 2011 at 5:48
  • Additional technical info on cache treatment of assets with expires headers - code.google.com/speed/page-speed/docs/caching.html
    – marfarma
    Aug 14, 2011 at 6:26
  • It would be useful to confirm the details of the category page header - can you install firefox and pagespeed to examine the show resources details as on the previous link - code.google.com/speed/page-speed/images/cachingheader1.png
    – marfarma
    Aug 14, 2011 at 6:30
0

I also had a problem with category page cache refusing to be cleared, even after manually clearing it in W3TC.

My solution was to click Browser Cache, then check "Prevent caching of objects after settings change" and then click "Deploy" at top.

I think this fixed it but it could also be that the time-to-expire was reached while I was performing that action. I can't be sure.

0

I found that my wordpress user wasn't able to delete the cache files... I had to manually chmod the permissions to 777 on the files first.

Not the answer you're looking for? Browse other questions tagged or ask your own question.