Or email me at donncha @ ocaoimh.ie giving me a login/password to your site (ftp and WordPress) so I can debug it myself. Could be another plugin that’s causing the status to be draft.
I’d be very interested in seeing if the Dev version helps correct this, so anyone trying it please post!
@cldswm – If reverting to 1.0 (I did the same), I’d make sure that you also replace the .htaccess rewrite rules (if using the advanced caching mode) just in case.
I suspect this might be related to the introduction of a new filter I used to clear the cache and the function that does the clearing checked if it had been called twice.
I have made a change to the plugin. You can either:
1. Edit wp-content/plugins/wp-super-cache/wp-cache-phase2.php in your favourite text editor and remove the line that mentions “clean_post_cache”
add_action( 'clean_post_cache', 'wp_cache_post_edit' );
2. Download the development version and overwrite all the files in wp-content/plugins/wp-super-cache/ with those files.
If you update to the dev version that filter is still there because it’s a regular part of WordPress, but I moved the “check if it runs twice” bit of code around so it only checks after a post is published. If it’s a draft post then it doesn’t remember that run. Confused? Just try it and tell me if it helps please.
Donncha,
Thanks for tracking this down. The fix works. On the same test installation where I experienced the problem with 1.1, I removed 1.1 and installed the dev version. Now, when a scheduled post is published via wp-cron, the cache is cleared as expected. Here’s a log excerpt:
16:05:38 /...wp-admin/plugins.php Not caching wp-admin requests.
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 In WP Cache Phase 2
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 Setting up WordPress actions
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 Not caching POST request.
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 wp_cache_post_edit: draft post, not deleting any cache files.
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 wp_cache_post_change: draft post, not deleting any cache files.
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 wp_cache_post_edit: Clearing cache for post 16 on post edit.
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 supercache dir: /...wp-content/cache/supercache/.../2012/06/21/scheduled-to-publish-62112-at-1205-p-m-edt/
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 wp_cache_post_id_gc post_id: 16 http://.../...2012/06/21/scheduled-to-publish-62112-at-1205-p-m-edt/ clearing cache in /...wp-content/cache/supercache/.../2012/06/21/scheduled-to-publish-62112-at-1205-p-m-edt/.
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 wp_cache_post_id_gc clearing cache in /...wp-content/cache/supercache/.../2012/06/21/scheduled-to-publish-62112-at-1205-p-m-edt//page/.
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 wp_cache_post_id_gc clearing cache in /...wp-content/cache/supercache/.../.../page/.
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 Post change: deleting cache files in /...wp-content/cache/supercache/.../...
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 prune_super_cache: wp_cache_rebuild_or_delete( /...wp-content/cache/supercache/.../...index.html )
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 rebuild_or_gc: rename to /...wp-content/cache/supercache/.../...index.html.needs-rebuild
16:05:39 /...wp-cron.php?doing_wp_cron=1340294738 wp_cache_post_edit: draft post, not deleting any cache files.
16:05:59 /... supercache dir: /...wp-content/cache/supercache/.../...
16:05:59 /... No wp-cache file exists. Must generate a new one.
16:05:59 /... In WP Cache Phase 2
16:05:59 /... Setting up WordPress actions
16:05:59 /... Created output buffer
16:05:59 /... Rebuild file renamed to cache file temporarily: /...wp-content/cache/supercache/.../...index.html
16:06:00 /...wp-cron.php?doing_wp_cron=1340294759 In WP Cache Phase 2
16:06:00 /...wp-cron.php?doing_wp_cron=1340294759 Setting up WordPress actions
16:06:00 /...wp-cron.php?doing_wp_cron=1340294759 Not caching POST request.
16:06:00 /... Output buffer callback
16:06:00 /... Anonymous user detected. Only creating Supercache file.
16:06:00 /... Writing non-gzipped buffer to supercache file.
16:06:00 /... Renamed temp supercache file to /...wp-content/cache/supercache/.../...index.html
16:06:00 /... Sending buffer to browser
16:06:00 /... wp_cache_shutdown_callback: collecting meta data.
16:06:00 /... Did not write meta file: wp-cache-3602706326b6e23414dfaba913b8bd78.meta *1* *0* *1*
Thank you.
It’s really weird. The clearing functions see a draft post but the second time they run they see a published post. Really odd but glad this fixes it. Expect a new release soon!
Donncha,
Bonus points to you, as this fix appears to resolve the other issue I experienced with 1.1, where requests not desiring compression would nevertheless get gzipped responses (request headers lacking an accept-encoding:gzip header would still get gzipped output–see href=”http://wordpress.org/support/topic/plugin-wp-super-cache-gzip-bug).
Now compressed content is returned only if a client says it’s OK to:
$ wget --header="accept-encoding: gzip" -S -O wpsc11.html http://####/crain/wpsc11/feed/
--2012-06-21 15:03:03-- http://####/crain/wpsc11/feed/
Resolving #### (####)... ####
Connecting to #### (####)|####|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Thu, 21 Jun 2012 19:03:04 GMT
Server: Apache
X-Powered-By: PHP/5.3.3
Content-Encoding: gzip
Vary: Accept-Encoding,Cookie
X-Pingback: http://####/crain/wpsc11/xmlrpc.php
ETag: "1d7e411dd3ae8bf6be9d96dd8d6b17a0"
WP-Super-Cache: Served legacy cache file
Wx: 3
Content-Length: 1166
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/xml; charset=UTF-8
Length: 1166 (1.1K) [text/xml]
Saving to: 'wpsc11.html'
100%[=======================================================================================>] 1,166 --.-K/s in 0s
2012-06-21 15:03:03 (11.1 MB/s) - 'wpsc11.html' saved [1166/1166]
$ file wpsc11.html
wpsc11.html: gzip compressed data, from Unix
$ wget -S -O wpsc11.html http://####/crain/wpsc11/feed/
--2012-06-21 15:03:21-- http://####/crain/wpsc11/feed/
Resolving #### (####)... ####
Connecting to #### (####)|####|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Thu, 21 Jun 2012 19:03:22 GMT
Server: Apache
X-Powered-By: PHP/5.3.3
Vary: Cookie
X-Pingback: http://####/crain/wpsc11/xmlrpc.php
ETag: "1d7e411dd3ae8bf6be9d96dd8d6b17a0"
WP-Super-Cache: Served legacy cache file
Wx: 8
Content-Length: 6540
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/xml; charset=UTF-8
Length: 6540 (6.4K) [text/xml]
Saving to: 'wpsc11.html'
100%[=======================================================================================>] 6,540 --.-K/s in 0s
2012-06-21 15:03:21 (82.2 MB/s) - 'wpsc11.html' saved [6540/6540]
$ file wpsc11.html
wpsc11.html: XML document text
Very happy about this! Thanks!
Have had the same issue reported to me from readers, the site auto tweets new posts, yet people visiting the home page couldn’t find them.
Turned on debugging on a post I just scheduled and got the same issue with post is draft do nothing.
About to install the dev version.
Hi, just to say that I’m having the same issue on both my blogs where I use WP Super Cache.
I’ve just edited the wp-cache-phase2 file, I hope this should solve the problem.
Thanks!
Doc75 – or try the development version, that should fix it and I’d love to get some feedback, artesea – did it help?
http://ocaoimh.ie/the-development-version-of-wp-super-cache/
I’m having this same problem on a blog that receives a lot of views. Is there somewhere that I can download v.1.0 to revert to?
Not comfortable using the aforementioned hack or a dev version–need stability.
Thanks!
tbadorrek – the dev version will be the stable version in a day or two, it is very stable.
Hi, editing the file did not solve the problem. I’m now installing the development version.
I’ll let you know.
Thanks.
Editing the file did not work for me either.
tbadorrek – so try the dev version. That will fix it.
