WIP: the Super Cache admin page

A small update, I’m slowly working through the WP Super Cache admin page in an effort to make it better. You can in fact download the development version if you want to follow along.

What you see above is my first pass. An effort to make the first options section match the look and feel of the standard Settings pages in WordPress. It’s all likely to be mixed around and moved about before the next release, so please, dig in and lend a hand!

17 thoughts on “WIP: the Super Cache admin page

  1. I have my site set up to not cache pages for logged in users. Sometimes, though, logged in users see pages loaded as though they were the post author. Is this a known issue? Is there any way I can prevent it?

  2. WP super cache works brilliantly for a few days on my blog (www.simplifyinginnovation.com) then stops serving cached pages after a few days and the cache tester shows different or missing timestamps.

    Would love to use it since you have such great support for mobile, but I’ve tried deleting and reactivating it several times and after a few days it just stops – any suggestions?

  3. ”Sorry, the WP Super Cache admin page only works on the main site of this network.” (development version)

    But it IS the main site. Clicking the link leads to a 404. It thinks it is a WPMU site rather than a 3.0.1 site.

    Also, since adding custom menus in a child theme of Twenty Ten, a few new ”published” items have been added to the database. They are not really ”published”, just placeholders/aliases of some kind, with urls like /2010/08/25/2467/ which go nowhere. However, when Super Cache does its preload thing, it tries to access those placeholders, which leads to a bunch of 404:s.

    A third complaint is that the preload mechanism stalls too easily. Maybe something with WP Cron, but nevertheless it is not reliable at all.

  4. Why not explaining next to each item how it will affect caching? for example: what’s the difference between serving cached files with PHP (or not)?
    I know I would benefit from that.
    Anyhow, thanks for your effort!

  5. Hi, First off thank you so much for the great plugin and all of your continued effort and support.

    We average 100k users / 1 million page views /day. We find that the load on our site fluctuates depending on the time of the day. This leaves us to either modify the expire time manually throughout the day to keep to an ideal level or to set the number based on our peak to avoid getting to many cached files built up. The latter obviously results in us having a very small number of posts cached during low load times.

    If the ideal situation is to keep the number of files below ~500, would it be possible to have a self tuning expire time based on the number of files found during last GC? If the value is > 500 adjust expire down, if it is < 500 adjust up.

    1. Frank – I really have to change that text. The 500 file limit really only applies if you’re using PHP caching in half-on mode.

      I preloaded all the posts on this blog and there are over 5000 cached pages here!

  6. Thanks for the quick reply. We’re using caching in full-on “SuperCache”mode.

    Is it still advisable to adjust the expiry time to keep the half-on cached file level below 500?

    How about the “refresh preload” time? What do you set yours to? We have a similar number of posts so I’m trying to get my head around how “expensive” it is to keep thousands of super cached files around from a resource perspective.

    Thanks again.

    1. I have my preload time set to 2 days but there’s no real reason why it couldn’t be 7 days or longer as I don’t really care if sidebar widgets update very often.

      You probably do want to keep the half-on cached files below 500. When posts or comments are made, the plugin has to go through each of those files to decide which ones to delete because they’re now obsolete.

      1. Thanks, that is exactly what I was after.

        Regarding half-on cached files, then that raises the original question of whether a self tuning expire time makes sense since the ideal expiry time could vary wildly during low and high volume times of day.

        1. I would suggest keeping that figure lower actually. Those cached files are only good for on user visiting one page as the key for each file is made up from the user’s cookies and whatever else you decide.

          The big boost comes from the anonymous supercache files that are generally served to 99% of visitors.

    1. I added a “Clear cache” link in the “New Post” dropdown at the top-right of the admin. I didn’t implement that menu action. First I’d heard of it. Thanks for the heads up.

      1. Adding a “clear cache” to the quick post/page menu and bulk action drop down would be a nice to have as well for forcing an immediate deletion of any supercached versions of a specific post/page as opposed to clearing all of the cache.

Leave a Reply

%d bloggers like this:

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.