Is W3 Total Cache compatible with Bad Behavior and Ozh’s Who Sees Ads plugins?
My testing shows that Ozh’s Who Sees Ads does work (at least for the permutations I’ve seen). Bad Behavior on the other hand (and similar to WP Super Cache in only this regard) would require an add-on to be compatible. Such an add-on does not yet exist unfortunately.
Frederick, thank you for the update,
I tried Who Sees Ads, but it didn’t work for me – If first visit of the post would generate ad, all later visitors would see it (plugin rules would not work) 🙁
This is from BB website (can we somehow apply this to your plugin?):
WordPress Advanced Cache / Super Cache
Bad Behavior now works with WordPress Advanced Cache 2 and WP Super Cache. If you’re using a previous version of Advanced Cache, or if you’re using Staticize Reloaded or some other plugin, please upgrade. By simply activating the Bad Behavior plugin, you will receive protection from comments and trackbacks, however spambots will still be able to crawl your site. To enable Bad Behavior to protect cached pages, you will need to make a change to Advanced Cache / Super Cache. (When using Super Cache, Bad Behavior cannot protect Super Cached pages, only Cached pages with the change below.)
Edit the wp-content/plugins/wp-cache/wp-cache-phase1.php or wp-content/plugins/wp-super-cache/wp-cache-phase1.php file and find the following two lines at around line 34 (line 56 in WP Super Cache):
if (! ($meta = unserialize(@file_get_contents($meta_pathname))) )
Immediately after this, insert the following line:
require_once( ABSPATH . ‘wp-content/plugins/bad-behavior/bad-behavior-generic.php’);
Then visit your site. Everything should work normally, but spammers will not be able to access your cached pages either.
Thanks I’m aware of the wp super cache implementation and have put support for bad behavior in my queue. Meanwhile Many cases for who sees ads do work and unfortunately it’s not fully compatible with any caching plugin as far as I can see, without some theme modifications, which again has been queued for full support before release (v1.0).
I had a Bad Behavior user who also uses W3 Total Cache complain. The source of the issue seems to be that negative (400/403 etc) responses are being cached, when they should not be. I only just heard of W3 Total Cache this afternoon, so I haven’t dug in too deeply, but I was able to reproduce the problem on my local testbed.
I don’t think the Super Cache hack would be appropriate, or even necessary, for W3 Total Cache, since the designs are completely different. The only real problem I can see is the 4xx pages being cached.
Make that “MUST NOT” be cached. RFC 2616 is quite clear on this:
A response received with a status code of 200, 203, 206, 300, 301 or 410 MAY be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a cache-control directive prohibits caching. However, a cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial Content) responses.
A response received with any other status code (e.g. status codes 302 and 307) MUST NOT be returned in a reply to a subsequent request unless there are cache-control directives or another header(s) that explicitly allow it. For example, these include the following: an Expires header (section 14.21); a “max-age”, “s-maxage”, “must-revalidate”, “proxy-revalidate”, “public” or “private” cache-control directive (section 14.9).
W3TC is not compatible with Bad Behavior yet.
W3TC does not cache 404 pages, it uses the provided is_404() core function to determine if a page is 404 so that it won’t be cached. Furthermore, it’s a known issue that WordPress has issues with response codes: http://core.trac.wordpress.org/ticket/10930 – so as you can see, until reliability of is_404() is properly addressed by WordPress itself, it’s impossible to reliably handle this case.
So thanks for the input, but I don’t fail to see the importance of properly handling this case.
Some kind of “plugin” will have to be added to W3TC in an upcoming release to resolve this issue. W3TC is not generating these unacceptable responses on it’s own.
I tried the Who Sees Ads plug-in and just like TomasM, I noticed that ads etc were only shown for the first post only. It’s as though once the page has been cached, plug-in rules are no longer respected.
Hopefully a work around for this will show up some day.
Have a great weekend guys 😉
You might want to add the tag for WSA here to see if the author has some advice. There are 8000+ plugins, it’s hard to support them all.
Hi Frederick, the autor of Who Sees Ads has stated several times that he cannot find a way to make it work with cache plugins.
It would be SO cool if you could figure it out!! Who Sees Ads is a wonderful plugin and I can’t live without it, but my blog is becoming huge and I really need to use W3TC 🙁
If maybe one could find a way to tell W3 Total Cache to exclude Who Sees Ads php directive, it would be heaven.
I know it’s hard to support all plugins, but this one is very special – it’s the only one that provides such functions as to show different ads per country, etc (and it is popular, contrary to the low amount of people commenting on in on its WordPress plugin page).
I hope to make some sense, English is not my first language.
Thanks for this wonderful plugin, and I hope that sometime we could use it with Who Sees Ads!
It’s on my list of things to do, feel certain.
So…I have been a longtime user of W3 Total Cache (word!) and just installed Bad Behavior to combat the spam that’s clogging up my database.
Thus far I haven’t noticed any issues. Can you tell me what exactly doesn’t work with the two of them together?
Hi Frederick, just checking in on the compatibility of W3TC with Who Sees Ads (WSA).
Seems there are two paths for a solution:
2. Somehow alter W3TC to allow for the WSA plugin.
- The topic ‘[Plugin: W3 Total Cache] Bad Behavior and Ozh’s Who Sees Ads compatibility’ is closed to new replies.