WordPress.org

Ready to get started?Download WordPress

Forums

no super cached pages with WP Super Cache (25 posts)

  1. olivers
    Member
    Posted 6 years ago #

    hi donncha,

    I'm in the process of restructuring our blog, which content wise is quite dynamic and I have managed to migrate pretty much everything to AJAX requests that need to be kept dynamic. So far so good, except a major issue I'd need to get resolved concerning Super Cache: no super-cached pages are being delivered.

    (1) I installed the Super Cache plugin per the instructions and it seems to run fine, except for actually delivering <!-- super cached --> pages. The admin page does show both wp-cached and super-cached pages, super cached pages triggered by unknown visitors (file system/folder structure is intact).
    3 observations:
    (1.1) on occasion, completely unkonwn users get a dynamic page (even though it's already cached!)
    (1.2) on reload, unkonwn users then get the <!-- Cached page served by WP-Cache -->
    (1.3) but they never get a <!-- super cached --> page?!

    Notes:
    *) I use PHPSESSION (COOKIE based) on the blog
    *) I use add'l COOKIES on the site, but non would match the .htaccess rules
    *) .htaccess rules are the std ones

    Any ideas?
    Thanks!
    Oliver

    PS: the site has access restrictions in place, but I'm happy to send you an email on how to access.

  2. olivers
    Member
    Posted 6 years ago #

    I think I got it down to these two lines .htaccess that won't work:

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

    If I comment out the RewriteCond line (knowing that the index.html file in fact exists on the server), the RewriteRule now kicks in, but produces a 500 error.
    It seems that somehow the path:
    /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html
    is broken....

    Any ideas? Anyone?

  3. michaelpark
    Member
    Posted 6 years ago #

    It's not working for me, either. That directory is empty.

  4. olivers
    Member
    Posted 6 years ago #

    I've also noticed an inconsistency between reported, super cached pages and actual present super cached pages:

    WP-Super-Cache
    * 0 cached pages
    * 0 expired pages.

    is shown even though the file system shows super cached index.html files with current timestamps.

  5. Donncha O Caoimh
    Member
    Posted 6 years ago #

    Please include some details about your server environment. Are you using Apache? mod_php or fastcgi?
    Any other plugins?

  6. Donncha O Caoimh
    Member
    Posted 6 years ago #

    Olivers - Can you remove the last slash from those two lines so the end looks like this?
    $1index.html

    Does that help?

  7. olivers
    Member
    Posted 6 years ago #

    $1index.html didn't do the trick. Let's take is step by step and forget about the last condition rule (I commented it out).

    This is what is left:

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

    The [L,R] is for testing purposes.

    Here is another interesting observation:

    If I uncomment the older 3 WP lines:

    # RewriteCond %{REQUEST_FILENAME} !-f
    # RewriteCond %{REQUEST_FILENAME} !-d
    # RewriteRule . /index.php [L]

    (1) all of a sudden url/about works and delivers the super-cached page (showing the exploded rewritten URL).
    (2) url/about/ however results in an infinite loop: producing url/wp-content/plugins/cache/super.../wpcontent/plugins... etc

    Which leads to two questions:
    Q1) Why do need to remove the WP lines which of course breaks WP normal pages? Shouldn't the processing stop after the super-cache rewrite [L]?
    Q2) To make sure that URLs with and without a trailing slash work, I guess another rule is required to compensate for a missing trailing slash ('equalizing' the URL).

  8. Donncha O Caoimh
    Member
    Posted 6 years ago #

    Are the supercache rules before or after the regular WordPress ones? They should be before.

  9. rhapsodyv
    Member
    Posted 6 years ago #

    Hi,

    I was getting this same problem. Seeing the rewrite logs I had noticed that the rules didn't match because the files path was incorrect.

    Reviewing the instalation procedure, I saw that my virtual host configuration didn't match with wpmu instalation instructions.

    I had installed the wpmu in ~home_folder/public_html/wpmu, but I didn't create a virtual host to point to this folder.

    When I fixed the virtual host configuration to point correctly to my wpmu folder, I get it working fine.

    Perhaps the super-cache must be patched to work with non-virtual hosts, but in this case I think the error was mine.

    I wish it can help you.

    []s
    Victor

  10. olivers
    Member
    Posted 6 years ago #

    Thank you rhapsodyv. I'm sure it is a related issue but I can't quite put my finger on it.
    Our provider did let us know that we'd to ditch %{DOCUMENT_ROOT} and instead use a full path, as well as that we'd need to use %1 vs. $1 - still, same issues...I'll stay on it, it's against my nature to give up on software.

  11. olivers
    Member
    Posted 6 years ago #

    OK I f-i-n-a-l-l-y got it working. With some mod_rewrite trickery.

    Here is what helped me, since my host has issues resolving paths correctly I had to hard code these. Also, I needed to make sure that for URL/permalink (without the trailing slash) it would also work and avoid any recursive rewriting.

    Long story short, for what it's worth:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    
    RewriteEngine On
    RewriteBase /
    
    RewriteCond %{REQUEST_URI} !^.*/.+\..+$
    RewriteCond %{REQUEST_URI} ^.*[^/]+$
    RewriteRule ^(.*)$ $1/
    
    RewriteCond %{QUERY_STRING} !.*s=.*
    RewriteCond %{HTTP_COOKIE} !^.*comment_author_.*$
    RewriteCond %{HTTP_COOKIE} !^.*wordpressuser.*$
    RewriteCond %{HTTP_COOKIE} !^.*wp-postpass_.*$
    RewriteCond /my/full/path/wp-content/cache/supercache/www.deliciousdays.com/$0/index.html -f
    RewriteRule ^(.*)/$ /wp-content/cache/supercache/www.deliciousdays.com/$1/index.html [L]
    
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    
    </IfModule>
    # END WordPress
  12. michaelpark
    Member
    Posted 6 years ago #

    That doesn't work for me unfortunately.

  13. AgnostosX
    Member
    Posted 6 years ago #

    It worked for me.

  14. michaelpark
    Member
    Posted 6 years ago #

    "/my/full/path/" should be something like "/home/username/public_html/"?

  15. olivers
    Member
    Posted 6 years ago #

    correct. I don't expect a lot of hosting providers to have the same 'funny' requirements, %{DOCUMENT_ROOT} ought to have worked, but if you provide your full path starting from root / then you don't take chances.

    PS: this can fix .htaccess / rewriting issues, of course it doesn't address any 'my super-cache dir is not being populated' type problems.

  16. michaelpark
    Member
    Posted 6 years ago #

    ...of course it doesn't address any 'my super-cache dir is not being populated' type problems.

    No wonder... :(

  17. olivers
    Member
    Posted 6 years ago #

    Unfortunately, I just found out (I happily stand corrected) that super-cached-pages really only work on pages that have no interdependences with other pages!

    E.g. changing the title of a post, will invalidate and correctly re-render the post's URL (permalink), but it will still show the old title on the archive/category etc. pages (if they had been super-cached earlier)

    So this unfortunately makes super-cache only useful for pages that won't change (title, content or comment wise) again in the future (or one would have to simply erase the complete cache to be sure)

    The alternative would of course be nice, which is a pruning logic that would consider page dependencies,e.g.:

    Changes to a post would then invalidate:
    (a) index page, (b) cat pages, (c) archive pages etc.

  18. michaelpark
    Member
    Posted 6 years ago #

    After putting "index.php" to be cached, it started to work!

    Thanks!

  19. Donncha O Caoimh
    Member
    Posted 6 years ago #

    olivers - that's unavoidable unfortunately unless you clear the whole cache because the static cache has no idea about that.

    michaelpark - that's strange!

  20. olivers
    Member
    Posted 6 years ago #

    donncha,

    right, but it could be relatively easy implemented. e.g. allow the function wp_cache_post_change() to not only unlink the actual URL/file of a post but also associated cache-sub-trees.

    the definition of what sub-trees are associated with post changes could be as simple as another text-area config field, allowing multi-line input for the respective super-cache-subdirs:

    let's say a post is located at:
    /archives/2008/02/29/my-new-post/

    then the additional dirs to consider could be:
    /wp-content/cache/supercache/U.R.L/archives/{YYYY}
    /wp-content/cache/supercache/U.R.L/archives/{YYYY}/{MM}
    /wp-content/cache/supercache/U.R.L/archives/{YYYY}/{MM}/{DD}
    /wp-content/cache/supercache/U.R.L/category/{CCC}

    The variables {YYYY}, {MM} etc. of course would be adjusted dynamically based on the post.

    This would add a lot more flexibility around super-cached-pages...unless I'm missing something.

  21. michaelpark
    Member
    Posted 6 years ago #

    I had Hotlink rules after the WP ones when it wasn't working. Could Hotlink rules have messed with SuperCache?

    I'd test it, but I don't wanna break things.

  22. Donncha O Caoimh
    Member
    Posted 6 years ago #

    michaelpark - no, that shouldn't interfere with the supercache rules, except if they were slightly buggy maybe.

    olivers - actually you've given me an idea. WP-Cache already stores meta data with each cached file. I could use that meta data to delete related content.

  23. olivers
    Member
    Posted 6 years ago #

    donncha,

    sounds good :-) also, it be great if the wp-cache part (kicking in for known users) could invalidate - if needed - super-cached pages (if present) as well.

    this would help to keep the creation/expiration process of super-cached pages somewhat automatic and one wouldn't have to daily flush expired pages manually.

    the automatic process should work fine, since one usually has a fair distribution of known and unknown visitors.

    just a thought.

  24. ChrisSamuel
    Member
    Posted 6 years ago #

    OK, because I'm using vhosts in my Apache 2.2 config I found that %{DOCUMENT_ROOT} was being set to just /htdocs. So to fix it
    I just needed to prefix it with /var/www/%{HTTP_HOST}. You can verify whether or not this is happening for you too by looking at the output of the phpinfo() "Server variables" section.

    My patch was:

    --- .htaccess.hmm       2008-04-06 18:58:17.000000000 +1000
    +++ .htaccess   2008-04-06 20:06:50.000000000 +1000
    @@ -5,12 +5,12 @@
     RewriteCond %{QUERY_STRING} !.*s=.*
     RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
     RewriteCond %{HTTP:Accept-Encoding} gzip
    -RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
    +RewriteCond /var/www/%{HTTP_HOST}/%{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
     RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]
    
     RewriteCond %{QUERY_STRING} !.*s=.*
     RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
    -RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
    +RewriteCond /var/www/%{HTTP_HOST}/%{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
     RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
     </IfModule>

    Hope that helps!
    Chris

  25. akosma
    Member
    Posted 6 years ago #

    I've resolved the issue my way :) actually the folder "supercache" inside "wp-content/cache" was not created, so I created and "voila!" the cache started to fill itself automagically.

    Hope this helps!

Topic Closed

This topic has been closed to new replies.

About this Topic