WordPress.org

Ready to get started?Download WordPress

Forums

[Plugin: WP Super Cache]The plugin make new cache page all the time (23 posts)

  1. ktomov
    Member
    Posted 4 years ago #

    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?

  2. esmi
    Forum Moderator
    Posted 4 years ago #

  3. Donncha O Caoimh
    Member
    Posted 4 years ago #

    ktomov - just use it in half-on mode.

  4. gioliciouswp
    Member
    Posted 4 years ago #

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

  5. splintering
    Member
    Posted 4 years ago #

    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?

  6. Donncha O Caoimh
    Member
    Posted 4 years ago #

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

  7. Acolonna
    Member
    Posted 4 years ago #

    "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.

  8. Donncha O Caoimh
    Member
    Posted 4 years ago #

    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.

  9. Acolonna
    Member
    Posted 4 years ago #

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

    I need to get this working.

  10. Acolonna
    Member
    Posted 4 years ago #

    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

  11. Acolonna
    Member
    Posted 4 years ago #

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

  12. Acolonna
    Member
    Posted 4 years ago #

    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..

  13. KenMorse
    Member
    Posted 4 years ago #

    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]

  14. Acolonna
    Member
    Posted 4 years ago #

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

  15. Donncha O Caoimh
    Member
    Posted 4 years ago #

    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.

  16. Pinoy.ca
    Member
    Posted 4 years ago #

    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 http://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.

  17. Pinoy.ca
    Member
    Posted 4 years ago #

    I'm sorry, please disregard my last post.

    KenMorse's tweaks to Acolonna's tweaks is what does the trick, not mine.

  18. Pinoy.ca
    Member
    Posted 4 years ago #

    Question: Isn't it better to rearrange the RewriteConds such that the conditions most frequent to occur and least expensive to test come first?

    RewriteCond %{HTTP:Accept-Encoding} gzip
    RewriteCond %{HTTP_REFERER} !(google|yahoo|msn)\. [NC]
    RewriteCond %{QUERY_STRING} !.*=.*
    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 %{REQUEST_METHOD} !POST
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{DOCUMENT_ROOT}/blog/wp-content/cache/supercache/%{HTTP_HOST}/blog/$1/index.html.gz -f
    RewriteRule ^(\w+(?:/\w+)*)/*$ /blog/wp-content/cache/supercache/%{HTTP_HOST}/blog/$1/index.html.gz [L]

    P.S. I snuck a line there because I'm using the Landing Sites plugin.

  19. splintering
    Member
    Posted 4 years ago #

    With both tweaks applied to the rewrite rules the super cache works like charme, except for the homepage, as mentioned by Acolonna above - on my page it is not cached at all, a new cache page is generated with every call.

  20. Acolonna
    Member
    Posted 4 years ago #

    Pinoy.ca, very acute suggetsion. The first attempt at optimization that can be performed on any conditional in any language.
    Great!

    As regarding the homepage I must admit I haven't taken the time to tackle it yet, I've been covering thousands of kilometers on my bike to get back home from my holidays.

    Will get back to work tomorrow and hunt it down. If anyone comes up with an idea, be my guest!

  21. Donncha O Caoimh
    Member
    Posted 4 years ago #

    Pinoy.ca - thanks, must try some of those tweaks.

    The main reason for the rewrite rules being broken for some is because of the many ways WordPress can be tested. You can put it in:
    1. In the root folder.
    2. In a directory.
    3. In a directory but loaded from the root folder.

    Can you put it in a directory and load it off another directory?

    I spent a lot of time trying all the different permutations but if anyone wants to help, the code that generates the .htaccess rules is in wp-cache.php

  22. dpark
    Member
    Posted 4 years ago #

    I'd just like to chime in and let you know that the malformed rewrite rules bit me, too. I've been trying to figure out why WP-super-cache isn't working for some time, and today I finally realized it was a problem with the rewrite rules. In particular, my blog is installed at "/blog/" instead of "/", so these rules don't work:

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

    Instead, I needed:

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

    A similar modification was needed for the gzip rules of course. Alternatively, this also works (and might be simpler to add to the rewrite rules generation code):

    RewriteRule ^(.*) /blog/wp-content/cache/supercache/%{HTTP_HOST}%{REQUEST_URI}index.html [L]
    RewriteCond %{DOCUMENT_ROOT}/blog/wp-content/cache/supercache/%{HTTP_HOST}%{REQUEST_URI}index.html [L]

    I really appreciate all the work you put into this plugin, and I hope these comments help. :)

  23. Donncha O Caoimh
    Member
    Posted 4 years ago #

    Thanks dpark - I think this problem should be fixed in the development version (wait at least 15 minutes until after the timestamp on this post for it to regenerate). Can you give it a go?

    Not sure why I didn't use the REQUEST_URI variable.

Topic Closed

This topic has been closed to new replies.

About this Topic