Support » Plugins » [Plugin: WP Super Cache] Latest Version: GZ not Supercaching, cache not expiring

  • Think I’ve got a couple bugs…

    I’ve used WP Super Cache for quite some time now, never had a problem, it’s always worked great, until the last version or two. I’ve got two issues with it and I’ve seen the same thing across several other sites/hosts for people I help support.

    First Super Cache does not seem to work now with GZ Compression, or at least it reports it as a WP Cache page. Rather than getting:

    <!– super cache gz –>

    Can only ever get:

    <!– Cached page served by WP-Super-Cache –>
    <!– Compression = gzip –>

    Also, cached pages do not seem to be naturally expiring/refreshing. So if you go to the previous post, up to a couple days, there will be no next button. This is with the default 3600 second setting. I’ve gone ahead and forced cache clearing on posting.

    Others seeing this too?

    Tyler Martin

Viewing 11 replies - 1 through 11 (of 11 total)
  • You don’t get the <!– super cache gz –> anymore. That was changed in favor of what you see now. Prettier.

    I think you’re missing it.

    The stamp <!– super cache –> still exists and returns without GZ.

    With GZ all are returning <!– Cached page served by WP-Super-Cache –>, meaning they are returning a WP Cache page not a Super Cache page.

    Even if it has been changed, I should be seeing something more like:

    <!– super cache –>
    <!– Compression = gzip –>

    “If a visitor who is logged in or who has left a comment views a cached page, it will be served from the standard WP Cache function and the last line in the source code will read <!– Cached page served by WP-Cache –>”

    Hi Tyler–

    I’ve just started using WP Super Cache, but have been making some mods to it so I’m pretty familiar with the code (many kudos to Donncha for his efforts to extend the original WP Cache spaghetti code!).

    With all my recent fresh installs, gzip has worked out of the box with no problems. You should still see either the “<!– super cache gz –>'” or “<!– Compression = gzip –>” comments in your page footer if gzip is working.

    The good news is your server is still sending gzipped pages, but only because it’s running Apache 1.x w/ mod_gzip. 🙂

    Can you verify that cache files are still being written to the cache/supercache directory? (i.e. it’s not a disk permissions thing)

    Is it possible PHP on your server got upgraded and it doesn’t have zlib support? You can check for --with-zlib in the output of phpinfo() or run a quick test like php -r "echo strlen(gzencode('abcd'));" from the CLI.

    Cache files are being written. Does have –with-zlib on server.

    I am seeing these results for people running the latest WordPress and Super Cache on Dreamhost and Media Temple (grid) for sure, need to check into some of the other servers being used.

    Again, with GZip enabled, only displays the non Super Cache cache pages (or at least reports that). And cache does not expire, cache must be cleared on posting or your previous post will not have a next post link.

    This is happening for a lot of people I work with across multiple host setups.

    I’ve reverted back to Super Cache version 0.6.3 and it works great. Expires and reports <!– super cache gz –>.

    Found the Super Cache version repository. All versions output <!– super cache gz –> for me up until version 0.8.3

    Not sure about expiring pages (though with 0.8.2 it can be forced on posting).

    I saw somewhere that one of the results of the 0.8.3 advancement (stopping it from gZipping twice–hence the ‘speedy’ nomenclature of WP Super Cache 0.8.3 ‘Speedy’), was that it no longer placed that output in the HTML…

    TylerMartin – you should use one of the mod_gzip online testers on an already generated page. Do it twice just to make sure the cache file is generated.

    Yeah, it reports the zipped pages are coming through just fine zipped.

    The problem is that since 0.8.3 turning on GZ it only reports WP Cache pages on the site and not Super Cached.

    It seems to me that since v0.8.3 the html comments have been causing a lot of confusion as to what is being served from where to the extent that a significant number of punters are doubting whether it’s working properly.

    The problem that Donncha was trying to solve was not being able to tack different html comments onto wp-cache and supercache gzip files without gzipping each of them separately. It’s either gzip the content once, or gzip twice with different comments. Gzipping twice is a waste of cycles.

    As you may or may not know/care; I have a [parallel|tangential] cache plugin based on WPSC under development and to solve the same gzip problem I pondered long and deep and finally elected to use a generic comment <!-- Served by WP-SuperCache-Plus - See X-WPSCP response header --> in every file and add a response header that specifies the extra info like Dynamic, SuperCache etc. on the basis that anyone who cares that much should be capable of using FireBug or Dragonfly to look at the response headers.

    The variants that I use are:

    X-WPSCP: Dynamic
    X-WPSCP: Cache
    X-WPSCP: Cache, mfunc/mclude
    X-WPSCP: SuperCache (via “Header set” in cachedir .htaccess)

    It takes a little extra effort to see the info, but there’s no ambiguity.

    Just a suggestion.

    So I’m still a little unclear…

    Is it possibly still directing the viewer to the Super Cache page, but reporting the WP-Cache page since it is a copy of the WP-Cache page (to avoid double-zipping)?

    Although that would contradict joelhardi above.

    TylerMartin – yes, the html comment at the end of the page looks exactly the same. joelhardi was saying the exact same except he writes info about the cache to the page headers which is a good idea and I may try to replicate. (thanks joelhardi for sharing the idea!)

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘[Plugin: WP Super Cache] Latest Version: GZ not Supercaching, cache not expiring’ is closed to new replies.