A few people stumbled across a strange bug in WP Super Cache. If your index.php was cached by the plugin then feeds or other pages that hadn’t been cached would show the front page!
A simple way to fix this is by adding “index.php” to the list of rejected URIs, but then it won’t be cached at all. This release fixes the problem but also allows index.php to be cached by the WP Cache engine, much better than excluding index.php completely.
Also included is a new feature that inserts your rewrite rules in a new .htaccess block. That will stop WordPress overwriting the rules after doing an upgrade, or after changing permalinks. The plugin won’t update your .htaccess if it finds the rules already in the “WordPress” section, but if you visit your permlinks options page and hit “Save Changes” the plugin rules will be deleted. Go to the WP Super Cache admin page where you can update the rules again. They’ll be inserted in a “WPSuperCache” block above the WordPress rule block.
If all that seems a bit technical, just go to your permalinks options page and hit “Save Changes” without changing anything, then update your rewrite rules on the Super Cache options page!
Go grab the plugin from the usual place.
I never saw this obscure problem because I redirect hits to /index.php to / using this mod_rewrite rule and php code. This used to help avoid duplicate content rules but I think Google is smarter now. It probably will help reduce pagerank dilution because all requests will go to one homepage url, rather than two.
.htaccess:
RewriteRule ^index\.html / [R=301,L]
wp-config.php:
if( $_SERVER[ 'REQUEST_URI' ] == '/index.php' ) {
header( "Location: http://ocaoimh.ie/", 301 );
die();
}
Thanks to Dax (NSFW text) who figured out the problem with index.php caching.
Good deal! Funny about the the rewrite rules being inserted in it’s own WP Super Cache block. It seems the previous version did that as well, at least that’s where it stuck them in my .htaccess. Right above the WordPress entries. So now I’m curious…which previous version did not use it’s own .htaccess block?
Ain’t I a pain though?
Could you add the following line into the next release?
RewriteCond %{HTTP_USER_AGENT} !Google*
below
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
Otherwise google adsense will display odd adds because it is not capable of reading gzipped content.
Kirk – I noticed I hadn’t checked in a few tags which is probably why you saw that. You were using development code! It’s stable anyway so no harm done.
Mike – I don’t think it’s necessary because the Google bot shouldn’t tell the server that it can support gzip if it can’t. The adverts here are on-topic, and I’ve been using the plugin for months.
The google bot can read gzipped stuff just fine.
A future version of WordPress may do that redirection. It was in my original canonical redirect function, but on some crazy setups we can’t tell the difference between
/and/index.phpso it would create an infinite loop (boo).Thanks Mark – for the life of me I thought it did that now but I guess it was my own little hack doing it’s thing.
Hi Donncha,
I am still experiencing this bug, despite using Super Cache 0.6.3.
I figured out the problem relates to the URL structure.
WP super cache always prompts the front page when you use the url format ocaoimh.ie/?p=100 while if you use for example ocaoimh.ie/index.php?p=100 the plugin works perfectly.
Please, fix this bug.
Thank you for your great work!!
I am using Alex King’s WP-Mobile plugin because I have several mobile readers. Because of this I am a little reluctant to use WP Super-cache: I am concerned that a mobile reader will read a page that has not been cached, and that this will trigger the page being cached with the mobile style sheet, appearing ugly when viewed on regular machines.
Is there a way I can exclude the mobile pages from being cached? I’d really like to use Super Cache but do not know how to overcome the potential problem with mobile viewing.
Hi Donncha,
please can you change line 407 from wp-cache-phase2.php into
$comment = get_comment($comment_ID, ARRAY_A);
because like you sure know, get_commentdata is deprecated
Have a nice day! 🙂
greetings
Chris
Thanks Lazy, applied in trunk!