• Hello there. I’ve installed the plugin and I’ve stared it successfully but now wherever I am logged out, the plugin generate new cache file when I refresh the page. Now instead of static pages, I get static pages generated all the time which make much more cpu usage. Is this normal?!
    I want opposite behavior, because I am the only one logged in. I want the posts to be cached for the anonimous users, not for me.
    And the settings are like default.
    Do someone have the same problem?

Viewing 15 replies - 1 through 15 (of 22 total)
  • ktomov – just use it in half-on mode.

    i had the same problem with my other sites. Have you tried re-installing the plugin?

    Same problem here. I tried all the steps in readme.txt and everything seems fine, but still on every call a new cache page is generated. Half-on mode works though.

    I checked the Rewrite Rules. There seems to be an error in
    RewriteCond %{DOCUMENT_ROOT}[path to cache file] -f
    The [path to cache file] starts at root (file system root). That error may be due to the fact that I use a symbolic link as my document root that points to the wordpress directory. But even after fixing the broken rule it didn’t work. Disabling this rule, which means forcing the redirect even if the cache file is not there, didn’t work either – a new cache file was created. Error must be somewhere in the script though.

    Any idea where to look at? Or isn’t it worth the trouble, as half-mode caching is as effective as super-caching?

    splintering – you should fix the rule rather than disable it, or just run the plugin in half-on mode.

    “run the plugin in half-on mode”… this is not good enough.
    There is clearly a bug here: the plugin works fine in “Super” mode when a user is loggen in.
    It completely fails to work when a user is not logged in.

    Why is it not working?

    I’ll see if I can find out how to debug the Apache rules.

    Super cached pages aren’t served to logged in users (read the readme!), they’re getting the half-on mode cache files.

    That’s why I think the rewrite rules aren’t working properly.

    I am having trouble debugging the rewrite rules, is there any tool you can point out?

    I need to get this working.

    Ok, I have noticed three problems in the rewrite rules:

    1) RewriteCond %{REQUEST_METHOD} !=POST should be replaced with RewriteCond %{REQUEST_METHOD} !POST (it is a regex and does not need the “=” sign);

    2) RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$ does not work (when a user logs out of wordpress, a cookie permains, making this rule fail). What is this intended for, is it to filter logged in users? As it is it does not work.

    3) the paths do not work on my local machine. I was able to define a good path by trial and error with the help of mod_rewrite logs. Have to figure out how I can fix it for the MediaTemple (gs) path architecture too, without logs.

    I confirm that on my local machine, commenting out the second issue and fixing the others, I got Super Cache working.
    Will keep you posted.

    For reference, I will append the log info about the second issue:

    RewriteCond: input='wordpress_test_cookie=WP+Cookie+check; wp-settings-1=m0%3Do%26m1%3Dc%26m2%3Dc%26m3%3Dc%26m4%3Dc%26m5%3Dc%26m6%3Dc%26m7%3Do%26m8%3Do%26align%3Dnone%26urlbutton%3Durlpost%26imgsize%3Dfull; wp-settings-time-1=1250760657' pattern='!^.*(comment_author_|wordpress|wp-postpass_).*$' => not-matched

    another error is on the user agent rule: it must be all upper case, like this: %{HTTP_USER_AGENT}, not %{HTTP_user_agent}

    Ok, after a full day of work and a series of headaches I hoped this plugin would save me, here is a new set of rewrite rules. I am in no way a regex or mod_rewrite expert, so please keep both eyes open for problems.

    By the way, if anybody knows of a valid regex tool for mac, I once used to use a fantastic one on Windows, but there apears to be no professional apps on Mac for that.

    Here we go:

    # BEGIN WPSuperCache
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    AddDefaultCharset UTF-8
    
    RewriteCond %{REQUEST_METHOD} !POST
    RewriteCond %{QUERY_STRING} !.*=.*
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
    # RewriteCond %{HTTP_USER_AGENT} !^.*(Android|2.0\ MMP|240x320|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|hiptop|IEMobile|iPhone|iPod|KYOCERA/WX310K|LG/U990|MIDP-2.0|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|Playstation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|Windows\ CE|WinWAP).*
    RewriteCond %{HTTP:Accept-Encoding} gzip
    RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
    RewriteRule ^(\w+(?:/\w+)*)/*$ /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]
    
    RewriteCond %{REQUEST_METHOD} !POST
    RewriteCond %{QUERY_STRING} !.*=.*
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
    # RewriteCond %{HTTP_USER_AGENT} !^.*(Android|2.0\ MMP|240x320|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|hiptop|IEMobile|iPhone|iPod|KYOCERA/WX310K|LG/U990|MIDP-2.0|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|Playstation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|Windows\ CE|WinWAP).*
    RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
    RewriteRule ^(\w+(?:/\w+)*)/*$ /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
    </IfModule>
    # END WPSuperCache

    Basic modifications:

    1) corrected regex pattern typo against REQUEST_METHOD;
    2) corrected a lack of precision in the regex pattern against HTTP:Coockie, looking now for “wordpress_logged_in” rather than “wordpress”, left in the other cases (this should be bugfixed specifically, I did not replicate all use cases: only log in-log out);
    3) commented out HTTP_USER_AGENT rule (I don’t see why mobile devices should be fed live data while desktops see the cached pages.. unless you need to give them a mobile-specific “supercached” file), left it there for who needs it: I tend to make one-size-fits-all websites unless mobile devices are a major share of the target audience;
    4) corrected the regex pattern in the RewriteRule to strip out trailing slashes (I’ve noticed they are harmless on a UNIX server, but always better be more elegant than less).

    Left to do:
    I can not figure out why the hell the homepage is shown when I type the address to the public root (that is with NO REDIRECTION taking place at all).
    This has been driving me nuts for the past few hours, and I’m sick of it so will leave it there for now. This means that your frontpage will be served through the Legacy WP Cache, which only marginally cuts the script footprint (in my case only 40% less than the uncached page).

    ..to be continued..

    Nice work Acolonna!

    I noticed that if WordPress is not installed at the top of the domain, then WP Super Cache doesn’t seem to build the rules properly — it will set RewriteBase to the appropriate directory but doesn’t then use that folder in RewriteCond and RewriteRule, causing the matches to fail.

    For example, if WP is installed into the /xx folder, the rules built will be:

    RewriteBase /xx/
    ...
    RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/xx/$1/index.html.gz -f
    RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/xx/$1/index.html.gz [L]

    when it should be:

    RewriteBase /xx/
    ...
    RewriteCond %{DOCUMENT_ROOT}/xx/wp-content/cache/supercache/%{HTTP_HOST}/xx/$1/index.html.gz -f
    RewriteRule ^(.*) /xx/wp-content/cache/supercache/%{HTTP_HOST}/xx/$1/index.html.gz [L]

    I like your modification of the RewriteRule too; I noticed I was seeing an extra trailing backslash (in the RewriteLog) like:

    path//index.html.gz

    Another way to fix this up is:

    RewriteRule ^(.*?)/*$ /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]

    thanks for the side view, I’ll definitely check out the expressions!

    Thanks Ken, I’ve applied some of your changes although I’ve never noticed any problems with POSTs.

    The mobile user agent check works too even though it’s lower case.

    I had the same problem today as the OP. WP Cache works, but Super doesn’t, so odds are it was a mod_rewrite problem. I’m using version 0.9.6.1.

    My blog is not at my domain root. That is, it’s at https://example.com/myblog/

    After some fruitless troubleshooting, I copied the mod_rewrite rules generated by the plugin from public_html/myblog/.htaccess to public_html/.htaccess.

    This solved it.

    I don’t know why the plugin writes “RewriteBase /” and then “RewriteCond %{DOCUMENT_ROOT}/myblog/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f” on my site, but it does.

    I hope this helps someone.

Viewing 15 replies - 1 through 15 (of 22 total)
  • The topic ‘[Plugin: WP Super Cache]The plugin make new cache page all the time’ is closed to new replies.