no super cached pages with WP Super Cache

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.

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

Thanks!

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

michaelpark – that’s strange!

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.

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.

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.

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.

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

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!