Oliver Krautscheid (oliversk)

Can you simply remove this from .htaccess and it will stop redirecting search engines?

RewriteCond %{HTTP_COOKIE} w3tc_referrer=.*(google\.com|yahoo\.com|bing\.com|ask\.com|msn\.com) [NC]

 RewriteRule .* - [E=W3TC_REF:_search_engines]

Same issue here and I totally agree we need another option for the purge policy as stated by nadiamode

“plugin should have an option for “when posts are created, edited, or comments posted. ” separately ”

Installed latest version today. Getting same error .. Is this a critical error?

PHP Notice: Array to string conversion in /public_html/wp-content/plugins/w3-total-cache/lib/W3/Cache.php on line 52

Also I wanted to let you know that sometimes it is still using the ?p=xxx codes and fails to rewrite to the correct URL – I believe it only happens when I am logged in but I need to do further testing.

Last, but not least I would like to ask where you store the index.html for the index page (blog homepage!) .. I can’t find it in w3tc/pgcache/..

One solution is to host the images on another domain, but that is obviously a bad idea for SEO reasons.

Just an update on this.

The problem is still there. I believe it has to do with posting comments and the file wp-post-comments.php

I upgraded to the lastest W3 total cache but still.. will probably switch to supercache again and try to find the problem

I posted a solution my webmasterblog.

If you get a division by zero error in W3 Total Cache’s PGCache on line 436 (check your error_log in your apache dir) then W3 Total Cache will start using regular links like ?p=3000 instead of fancy permalinks until you clear the cache.

For me personally the fix was to copy the original comments.php from the twentyten theme and copy it into my own comments.php

I think it would be possible to fix this problem in W3T, but this is probably only a minor error.

The issue resolves when you clear the page cache, but will reappear after a while.

The basic disk mode seems to be buggy as well.

I’ve been using it for a couple days and today I noticed that when W3T Page cache (basic disk) is enabled, it sometimes turns the permalinks into the regular links (p=2039), disabling the permalinks completely.

How would I create a debug report?

May I second that, I’d even be willing to pay for this feature.

Please let us know if we can remove the RewriteCond or if we’ll run into any problems

For SEO reasons its impossible to add a trailing slash and I’m sure that there are many others out there who don’t want to update their permalink structure and mess around with some 301 redirects. Goolge will index both in the end if you don’t take care..

Anyway, W3T is pretty cool, nice work!
Oliver

I had the exact same problem. It was caching me as logged in. After reading this I figured it is related to the comments form.

Maybe you want to create a list of plugins that are incompatible?
Here’s the one that does not work for whatever reason:
– growmap-anti-spambot-plugin

Other problems I found recently
When you deactive Superache 0.9.9.9 and get the message you need to remove WP_CACHE it will display that message even after removing it. Strange!

Another problem, the entire site breaks when you have an invalid wp-cache-config.php or if you copy the sample config into wp-content. Could be fixed in 1.0?

And another problem is the mfunc tag does not always work with Late-Init in 0.9.9.9 .. but I need to look into it don’t know how to reproduce the bug.

Yep, I am using 0.9.9.9 already not 0.9.9. Also it only happens when you enable late-init, I will try to reproduce the bug on some other sites when I have time.

Glad to hear you are considering minify, I am really looking forward to it because it can boost performance quite a bit.

Anyone? I can’t be the only one with this problem ??

I still have this problem. I also suggest that the next WP version should add some basic checks via javascript if a users enters name/email instead of sending them to an ugly error page that accesses install.css from wp-admin folder.

I’m using WP-Supercache, could this be a problem?

I’m slowly starting to understand mod_rewrite rules. Here are the final rules that I put together:

Final rules
RewriteCond %{QUERY_STRING} ^[A-Za-z0-9-]=(.*)
RewriteCond %{REQUEST_URI} /page/[0-9]/?
RewriteRule ^(.*) $1? [L,NC,R=301]

Put above:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

I use two conditions,
(1) whenever there is a query string using letters or characters a-z
(2) whenever the requested URI is /page/number between 1-999)
then rewrite to last $1 request permanently

I’ll probably remove the lines from robots.txt ..and I might change the second condition to remove all query strings after verifying that I don’t need them.

Little update on this if someone has the same error:

This will redirect the query q=*anything* to index.php
RewriteCond %{QUERY_STRING} q=(.*)
RewriteRule ^(.*)$ $1? [L,NC,R=301]

This will already help, but I want to redirect it to the correct page instead of index.php

Also put this into robots.txt (unconfirmed)
Disallow: /page/*?*
Disallow: /page/*?q=*
Allow: /page/*

This could possibly block all /page/ sites.. I’m still testing this. If Google works as I think it does it should index all /page/1 /page/2/ but not /page/1?q=query