Hi,
I’ve been testing the issue you’re facing, and the issue seems to be related to both how APO handles cache invalidation, and how WordPress tells visitors that content has changed.
When you update a post, this post is updated on WordPress database and the “Last-Modified” header is updated accordingly. That is a signal for browsers to request the new version, instead of using the one it has on cache.
WordPress is known for messing up with the Last-Modified header, which is understandable, since when we talk WordPress we are actually talking all kinds of configurations (server, wp-config.php, .htaccess, theme, plugins etc.)
One issue is that when post 1 is updated, post 2 is not, even when it has a “Latest Posts” widget or similar feature to show the most recent posts on a page. So WordPress does not change the Last-Modified header for post 2 when post 1 is updated, rendering post 2 from the cached, outdated version of the content.
This blog post explains the issue in detail and has a good solution that you’d need to adjust to your needs. It makes WordPress update the homepage if other posts are updated, but not all pages with the Latest Posts widget on them.
On the APO end, it seem that APO in trying to maximize efficiency and reduce visits to the origin server does not revalidate correctly. I don’t know why, so I can’t explain. But I’ve spent some time testing different configurations and here one that worked on a test website under APO with both a page and a post with the Latest Posts widget.
-
Implement proper “Last-Modified”, if needed.
-
Create a Cache Rule for the pages with cacheable dynamic content (those with the Latest Posts widget or similar features.):When incoming requests match:
Hostname equals apo.example.com (whatever hostname you're running APO on.)
URI Path is in "/path-1/ /path-2/ /path-3/"
then
Eligible for Cache
Edge Cache TTL: 10 seconds
-
Alternatively, you may implement the Cache Rule above withEdge Cache TTL: Respect origin
.But then you must send a header from the origin defining the Edge Cache TTL:Cloudflare-CDN-Cache-Control: max-age=10
Obs.: A Cache-Control header with “s-maxage” will not work.
-
After testing, and confirming it’s working as expected, you may want to adjust the time set with the either method for Edge Cache TTL according to how often your content changes, and how soon users must see the updated content. It should go without saying that the smaller the time, the less efficient the caching will be. I started with 10 seconds to make testing easier.
Remember to purge the Cloudflare Cache for the relevant pages after implementing the changes. To test, make minor content changes that would affect the Latest Posts widget, such as changing the title or excerpt, or removing/adding a post. As with anything WordPress, I can’t guarantee it will work for every one. It worked for me,