Has the content of the page changed since it’s publication date of July 16? Or has any newer comment been made since the one on the cached page, from July 28?
Or has the newer page only changed contents in the Latest Posts widget (LPW) panel on the right of the page, as new posts have been published but are not showing there?
If the latter, there’s actually a limitation in APO for WordPress in handling pages with LPW and similar widgets. The content in that case is only updated dynamically when a new request arrives at the origin. That page hasn’t been saved anew just because some new post was published elsewhere, and therefore the trigger that would have made Cloudflare plugin request purging the cache was not triggered. Currently, the only workaround I know, which I’ve extensively tested, is to 1) make sure your origin sets the “Last-Modified” header properly; and 2) create Cache Rules for requests to every page with a LPW. I’ve described this in detail in an answer to a related post:
Alternatively, of course, you can always open each of the posts with LPW, make minor editing (adding or removing a space character, for example) and saving the post. You’d need to do this every time a new post is published on your site, so you may want to create a script to do this automatically.
Thank you for the information. I’ll have to dig into this when I have a bit more time. It’s disappointing that CF seems to be having this issue when it used to work in the past. I even tried to change some content in the page and it still won’t refresh in the cache.
Putting aside any auto purging, what am I doing wrong that prevents CF from showing a new version of a page when a manual purge is completed via the CF panel? The only way I’m getting the new page served is via purging the whole site (also via CF panel).
Cache is a complex matter in and by itself, with several headers combining to tell different browsers what to cache, what not to cache, if and when to purge or revalidate etc.
Then there’s the complexity of Cloudflare many caching layers (APO, but also Page Rules, Cache Rules, Cache settings, Smart Edge Revalidation, Tiered Cache, etc.), as well as the many layers where your origin could be handling/mis-handling cache (server config, Varnish or other server-level caching, WordPress core, WordPress theme, WordPress caching plugins, WordPress performance plugins, or any other WordPress plugin for that matter), and you realize it’s a big challenge to find out the definite source of any cache-related trouble.
That’s also the reason why I don’t quite buy the idea that “me too, I’m having the same issue” kind of attitude when it comes to caching. Though understandable — as when you have such a big pool of users as Cloudflare has, you’re bound to have many users seeing what appears to be the same problem — when you start sorting things out the similar issues may turn out to be coincidental results of different settings.