While I haven't tested this myself, one of my users reported a new scheduled post failed to show up - I'm assuming the cache didn't clear. Don't know if WP fires an action when it adds a scheduled post or not. It should if it doesn't!
I'm waiting to hear back if a manual clear of the cache fixes it - but it seems likely the issue is that a new scheduled post doesn't force a cache rebuild.
While the post will eventually show up, it was critical in this particular case because it was a special sales event that was supposed to show up.
Thanks for reporting this. I was able to reproduce this also. It seems we need to add a hook to the wp_insert_post() function in WordPress. @raamdev This is something we should take a look at for a future maintenance release.
So if I understand this right - it is a design weakness in core WordPress which provides the action calls needed to notify any cache plugin when a post or page (or menu, etc.) is updated from the admin interface, but fails to provide notification to the cache plugin when a scheduled post is added.
Kind of surprising this has been overlooked for so long.
I looked at the code in wp_insert_post, and see there is a point where the post changes from 'future' to 'publish', so that probably is where the missing notification goes.
But... the code in wp_insert_post won't necessarily even be triggered because the cache will be delivered before the need to execute that code. I guess it will only be triggered when in admin, or when the cache performs a scheduled update. This is a difficult problem after all. Very interesting.
@raamdev Sorry for the confusion. Regarding wp_insert_post(), this hook ALREADY takes care of this.
add_action('save_post', array($this, 'auto_purge_post_cache'));
This hook save_post is fired on all calls to wp_insert_post() and also on calls to wp_publish_post(). In addition, is also fired indirectly on calls to check_and_publish_future_post().
So, this functionality DOES work expected.
@raamdev @weavertheme All of that said, I encountered this problem myself while attempting to reproduce the issue. The issue is NOT with the cache being cleared as intended. The problem rather, is related to the location of an archive view that might also need to be updated automatically.
To clarify, when a post is published (either immediately, or in the future); the cache IS cleared for that post (but ONLY for that particular post). If there is a "Home Page" or "Posts Page" which displays an archive view, this is only purged too; if the current configuration of Quick Cache dictates that it should.
In addition, this requires the use of Quick Cache Pro as seen in the screenshot below.
@JasWSInc Your last point about the "Home Page" and "Posts Page" cache clearing require Quick Cache Pro is no longer true, as v131224 added the following to Quick Cache Lite:
New Lite Enhancement. The Home Page cache and Posts Page cache are now automatically purged when necessary (such as when a new post is published). See: #40
It's not possible to disable this functionality with Quick Cache Lite, but the "Home Page" and "Posts Page" caches are now automatically cleared.
@JasWSInc @weavertheme Regarding some archive views, other than the "Home Page" and "Posts Page", not being cleared when a new post is published: This is related to the issue with the Category and Tags pages not clearing when a post is updated (see #57), which I intend to work on as part of the branched cache structure feature (#3).
I wonder if it makes sense to handle this problem by allowing site owners to specify a list of URIs that contain archive views which should be cleared upon updates to a post (publish/edit/delete)? Since there's no way for Quick Cache to predict what pages a theme may designate as an archive view, this may be the only real solution anyway.
This issue has (mostly) been fixed by #117, so I'm going to close this issue. The changes will go out with the next release.
There is a related feature request open: User-defined URIs to purge with post cache (#111).