WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

closed as off-topic by gmazzap, birgire, Johannes Pille, Pieter Goosen, ialocin Aug 26 '14 at 7:54

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Your question should be specific to WordPress. Generic PHP/JS/HTML/CSS questions might be better asked at Stack Overflow or another appropriate site of the Stack Exchange network. Third party plugins and themes are off topic." – gmazzap, birgire, Johannes Pille, Pieter Goosen, ialocin
If this question can be reworded to fit the rules in the help center, please edit the question.

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.

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.