Support » Plugin: WP Super Cache » RSS feed not getting GC'd

  • amattie


    We recently upgraded from an old version of WP Super Cache (0.9 I believe) to 1.2, and we’re now having problems with our RSS feed being stale. I did some digging, and it looks to me like the garbage collector isn’t cleaning up the feed perhaps due to a bug. Here’s the relevant debug log:

    // hit feed for the first time w/ an empty cache dir
    15:43:19 /blog/feed/ supercache dir: […]wp-content/cache/supercache/
    15:43:19 /blog/feed/ No wp-cache file exists. Must generate a new one.
    15:43:20 /blog/feed/ In WP Cache Phase 2
    15:43:20 /blog/feed/ Setting up WordPress actions
    15:43:20 /blog/feed/ Created output buffer
    15:43:23 /blog/feed/ Output buffer callback
    15:43:23 /blog/feed/ Feed detected. Writing legacy cache files.
    15:43:23 /blog/feed/ Supercache disabled: GET or feed detected or disabled by config.
    15:43:23 /blog/feed/ Writing non-gzipped buffer to wp-cache cache file.
    15:43:23 /blog/feed/ Renamed temp wp-cache file to […]wp-content/cache/blogs/feed/wp-cache-feed0671fa3f67fb255e6141869e80660f1f.html
    15:43:23 /blog/feed/ Sending buffer to browser
    15:43:23 /blog/feed/ wp_cache_shutdown_callback: collecting meta data.
    15:43:23 /blog/feed/ Writing meta file: […]wp-content/cache/blogs/feed/meta/wp-cache-feed0671fa3f67fb255e6141869e80660f1f.meta

    // hit feed after it’s been primed in the cache
    15:44:09 /blog/feed/ wp-cache file exists: […]wp-content\cache\blogs\feed\wp-cache-feed0671fa3f67fb255e6141869e80660f1f.html
    15:44:09 /blog/feed/ Serving wp-cache static file
    15:44:09 /blog/feed/ exit request

    // hit wp-cron when a GC is scheduled
    16:01:46 /blog/wp-cron.php In WP Cache Phase 2
    16:01:46 /blog/wp-cron.php Setting up WordPress actions
    16:01:46 /blog/wp-cron.php URI rejected. Not Caching
    16:01:46 /blog/wp-cron.php maybe_stop_gc: GC flag not found. GC will go ahead..
    16:01:46 /blog/wp-cron.php wp_cache_gc_cron: Set GC Flag. ([…]wp-content/cache/
    16:01:46 /blog/wp-cron.php Cache garbage collection.
    16:01:46 /blog/wp-cron.php Cleaning expired cache files in […]wp-content/cache/
    16:01:46 /blog/wp-cron.php Doing GC on supercache dir: […]wp-content/cache/supercache
    16:01:46 /blog/wp-cron.php gc: deleted […]wp-content/cache/supercache/, older than 600 seconds
    16:01:46 /blog/wp-cron.php gc: could not delete […]wp-content/cache/supercache/ as it’s not empty: blog
    16:01:46 /blog/wp-cron.php GC completed. GC flag deleted.
    16:01:46 /blog/wp-cron.php scheduled wp_cache_gc for 10 seconds time.

    // hit the feed again just to show the cached file is still being served
    16:22:55 /blog/feed/ wp-cache file exists: […]wp-content\cache\blogs\feed\wp-cache-feed0671fa3f67fb255e6141869e80660f1f.html
    16:22:55 /blog/feed/ Serving wp-cache static file
    16:22:55 /blog/feed/ exit request

    As you see, when the feed is requested, WP Super Cache generates the static cache file and then stores it in the wp-content\cache\blogs\feed\ dir. Later, when the GC uses wp_cache_phase2_clean_expired to clean up the expired files, the “while … readdir” loop only looks at the files in that directory alone instead of recursing through all directories and files. The feed ultimately isn’t GC’d then because it’s in the blogs/feed/ folder instead of the top-level directory.

    Can someone confirm that this is actually a bug and not somehow a misconfiguration?

Viewing 5 replies - 1 through 5 (of 5 total)
  • _ck_


    Unless donncha has addressed it in newer versions, feeds aren’t cached (any longer?) as static files because of the header difference for feeds.

    But I sure would like to fix that and make feeds static too.

    Plugin Author Donncha O Caoimh


    @amattie – is your blog installed in /blog/ ? The feed should be stored in ../cache/blogs/HOSTNAME/, and not in cache/blogs/feed/

    @_ck_ – they’re cached, but using legacy caching so those headers can be sent 🙂



    “legacy caching” means php loads to send the headers and then dumps the static file?

    there has to be a way to avoid that – I’ll study it this weekend, not sure why feeds would need any kind of special headers for logged out users



    Yeah, our primary blog is installed in /blog/. Other blogs in our MU setup are on that same path prefix (/blog/blog2, /blog/blog3, etc). It appears that only the primary blog has feed caching broken for us.

    Is this setup not currently supported? It seems to be a problem with $blogcacheid assigned in wp-cache-base.php — the value gets set to “feed/” on line 27 since the blog name isn’t in the primary blog’s URL.

    Still a problem! I’m having exactly the same issue and it’s starting to drive me crazy. It’s a pretty serious issue because it’s easy to not notice a stale RSS feed. It is likely affecting many more people than have noticed.

    Like amattie I have multisite running and the main site is set up as /blog/, my other sites are not /blog/$x/ though, they are root directories on the domain (

    Like amattie I can see the cache file for the main feed in /wp-content/cache/blogs/feed/***

    If I push the “Delete cache” button on the main site it does not clear the cache for this RSS feed, however if I click the “Delete cache on all blogs” button in the “Contents” tab of Supercache it does refresh the RSS feed.

    I believe the core issue is that Supercache is treating /feed/ on sites with subdirectory-configs as a separate site and caching based on that assessment. We’re noticing it because the “/feed/” subsite doesn’t exist, so the garbage collection for it never runs.

    I think the fix will involve ensuring that /feed/ urls are correctly associated with the main site and their garbage collected during that site’s run.

    Thanks for any help you can provide Donncha, I’m sure overall this is a rare and hard-to-reproduce bug. I had a hell of a time just finding this thread 🙂

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘RSS feed not getting GC'd’ is closed to new replies.