Intercepting Before W3 Total Cache

Question

I am writing a plugin where I want to read user agent and send custom headers back on certain agents. Unfortunately however several people have the W3 Total Cache plugin and what it's doing is that, when I have a condition that sends back the custom header, it then sends back that custom header for ALL user agents, not running my event logic. I tried to load my event with...

add_action('plugins_loaded','MY_PLUGIN::checkRules',-1000000000);

...but W3 Total Cache intercepts via .htaccess or by some other mechanism. Unfortunately I have to do it at the plugins_loaded level because I need to query get_option.

How can I make my plugin work even if W3 Total Cache is engaged?

Answer 1

If caching is enabled at the .htaccess level, there's not much you can do through a plugin to intercept that traffic. Instead, you should work out a set of recommended .htaccess rules that work with both W3TC and your plugin to either allow traffic through or return cached content.

Perhaps, auto-generate a list of user agents you want to send custom headers for and use that list—through .htaccess—to allow certain traffic to bypass the cache.

Answer 2

I found the fix. One will need to be on the W3TC version 0.9.2.4 or higher because that's what I tested my code changes with. I had to edit the code of my plugin and find any place where I was checking user agents and returning a response. Right before I returned a negative response (like 404 or 403 -- whatever the user set in the plugin settings), I had to add this line:

define('DONOTCACHEPAGE', true);

Note also that the way I was checking user agents was from a function call via a WordPress event that was significantly high up in the event chain:

add_action('plugins_loaded','MYPLUGIN::checkAgents',-1000000000);

This add_action() is important because it needs to be high up in the chain where it loads before W3TC plugin loads. That's why the negative priority number was used.