Support » Plugin: WP Super Cache » Super Cache caches index page but not post for anonymous user

  • I’m running a single domain multisite network on a Litespeed/Centos hybrid server.
    Supercache successfully serves up the super cached version of a blog index page to a non-logged in user (/France/ Served page from supercache file using PHP.), but will not serve up the super cached version of a blog post page to the same user. Instead, it renews the file in the super cache.

    I am using mod_rewrite as my caching method.

    Log file shows:
    /France/destinations/beaune-burgundy-wine-capital No wp-cache file exists. Must generate a new one.

    The path given to the relevant super cache directory is correct. Index.html exists in the directory, but as you can see from the line above, this is apparently not seen by Super Cache, so a new one is created.

    This is driving me nuts, anyone got any ideas?

Viewing 12 replies - 1 through 12 (of 12 total)
  • Here’s an example url (but you could take any): : a blog index page showing

    <!-- Dynamic page generated in 1.370 seconds. -->
    <!-- Cached page generated by WP-Super-Cache on 2011-06-16 10:40:12 -->
    <!-- super cache --> : a post showing the changing time stamp

    <!-- Dynamic page generated in 0.968 seconds. -->
    <!-- Cached page generated by WP-Super-Cache on 2011-06-16 19:42:48 -->
    Plugin Author Donncha O Caoimh


    It’s probably because you have a capital G in Germany. Unfortunately a change to protect international characters in URLs made the url lowercase. I think I need to make that an optional feature in the next version.

    But Donncha, there’s a capital G in both pages, so why would the super cache file be served in one and not in the other? I do note that the super-cache files have a lower case germany in them (and all my other pages use capitalised countries).
    I’ve been striving to discover any differences between the two types of pages that would explain the failure to serve, but with my limited coding knowledge (I still struggle with the GET query effect on caching!) so far I’ve drawn a blank…

    Does the fact that I’m using mod_rewrite but the debug shows the index page as being “:Served page from supercache file using PHP” give any indication as to what is going wrong?

    Plugin Author Donncha O Caoimh


    Yeah, the file is stored in the supercache directory with a small “g” for Germany. The .htaccess rules can’t find it but the PHP might be able to.

    I have removed the htaccess rules in the web root and switched to PHP but unfortunately nothing appears to have changed. It’s still a puzzle to me that the index pages are served from the super cache but the post pages are not, you would have thought if it was the cap letter both would have failed!
    I’m sure this was working a short time ago (at least on some posts), and I’m wracking my brains to think of what I changed, but failing miserably. If you’ve any more ideas, I’d sure like to avoid the awful prospect of trying another caching plugin!

    I have a prototype blog on the same network that does not have a capital letter. It has a single Hello World post. The behaviour is similar to the Germany blog! Here are the two URLs:

    Oh dear, the mystery deepens…

    Moderator Ipstenu (Mika Epstein)


    🏳️‍🌈 Halfelf Rogue & Plugin Review Team Rep

    Zamba, please post your error log on pastebin and provide a link. What you posted is tripping the spam filter in a big way.

    Oops, sorry about that, I was unfamiliar with using pastebin, but I have now sorted it and so here is the debug log for 2x loads of an index page and post showing the problem (Super Cache issue):

    Plugin Author Donncha O Caoimh


    Does [PATH] in your debug output have a capital letter in it?

    No, all lower case and pretty normal, /home/xxxxxx/public_html/
    One thing happened: yesterday out of the blue supercached files were served. I did check the urls I have been checking and they DID serve the supercache files, as evidenced by the <!– super cache –>. Unfortunately, today the situation has regressed to the prior situation. I have altered nothing in the various blogs I checked, only a couple of entries have been made in different blogs.
    I really appreciate your help with this, I’m determined to get things working.

    I’ve been quiet because I thought I’d solved this, but apparently not.
    Here is the current state of the play:

    SERVER: Centos+Litespeed VPS, WordPress 3.1.3


    WordPress multisite network of 26 blogs (1 main site, 25 sub-blogs in sub-folders, including one prototype blog).
    There is a separate WordPress blog on the same server under the same domain in a sub-folder using a different database.
    The Super Cache plugin is network activated on multisite, and each sub-blog configured. Htaccess method is used, but an earlier trial of using php made no apparent difference to the non-serving of supercached files.

    Garbage collection is set at 172800 secs.
    Preload is set at 43200 minutes

    sample URL of sub-blog:

    sample RL of sub-blog post:

    sample URL of sub-blog page:

    URL of separate blog:

    Sample URL of separate blog post:


    This position is the same as that prior to my pre-load activities listed under “Recently”.

    All posts and pages are supercached.
    All blog index pages are served from supercache.
    The multisite blog network Super Cache uses .htaccess to serve its files

    Main blog: Index page and pages supercached (posts pulled from sub-blogs redirect to respective sub-blog posts as designed: SiteWideTags plugin).

    Sub-blogs: Index page served from supercache. Posts and Pages not served from supercache (supercached file not found so new one created).

    Separate blog: Supercache functions as normal, all posts and pages served from supercache. Supercache uses php to serve its files.


    The position was the same as outlined above, when I tried pre-loading all sites in the main network one by one. This resulted in the supercached files suddenly being served as they should be.

    However, a few hours after all the sites had been pre-loaded (around 12,000 files, three days later), Supercache stopped serving files from the supercache and the position regressed to the current position. This resulte in an approximately threefold increase in CPU load.


    It has been noted that the url used in the supercache directory uses a lower case as opposed to the upper case in the WordPress file, i.e.
    Actual URL:
    Supercache URL: /home/MYACCOUNT/public_html/wp-content/cache/supercache/

    The argument against this is that the blog index pages (which are served from the supercache) also have the upper case country name in them, and a corresponding lowercase URL. Similarly, prototype blog has a lower case folder name and exhibits exactly the same behaviour as those with an upper case name.

    So, that’s where I am at the moment. If anyone’s got any ideas I’d be pleased to hear them, as I’m struggling a bit. Having had an albeit brief experience of the promised land when supercaching worked, I’m determined to get it running…

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘Super Cache caches index page but not post for anonymous user’ is closed to new replies.