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?
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.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:
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:
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.