How to bypass Page Cache created by W3 Total Cache


In our recent WordPress plugin development, a bridge between Invision Power Board (IPB) forum software and WordPress, we needed to handle the user login through IPB and get the logged in user details in the WordPress. Post getting the IPB user session in the WordPress, our plugin opened up the comment section in the WordPress that would allow the comments to be posted in IPB thread. This is a very basic overview of the plugin and it can be seen working LIVE at The plugin can do a lot more. If you have any questions about the plugin, you can contact us through our official website, AxeFinch.

The above process worked well in our development server where we didn’t have W3 Total Cache (W3TC) installed and activated. When we rolled this to LIVE server with W3TC activated, we ran into issues with Cached version (with not logged in message) of pages those were kept appearing to the users those logged in from IPB forum and coming to WordPress posts for commenting. We started investigating the issue and found that W3TC will keep throwing cached version of pages if a proper WordPress logged in user is not found which is legitimate. What we were doing in the plugin was checking the IPB Member object details and if it is found that a IPB user session is on, we show the comment form otherwise, the “Login” message for the visitor. But, even our code checks the IPB user session details correctly, when a user is in the WordPress comment section for a post, they could see the non-logged in version of the page till the cache is purged by W3TC. So, what’s the solution?

We could create a WordPress user session easily from the IPB Forum’s Login Extension that could resolve the issue, but the requirement is such that we couldn’t implement the same. So, we started investigating the W3TC plugin code and found that it looks for a cookie name starting with “wordpress” and if found, it bypasses the page cache and reloads a fresh page as it assumes that a WordPress user is logged in. Bingo! this was the solution.

In our plugin, we implemented a function that checks whether an IPB user session is on. If yes, we create a cookie name “wordpress_xxxx” and if not, we check for the existence of the cookie and removes it (as the IPB user might have logged out). We hook this function in the ‘init’ action of WordPress.

Here’s a sample code that could help you to handle this kind of situation where you cann’t create a WordPress user session but need to bypass W3TC generated Page Cache.

function bypass_w3tc_pagecache() {
   $your_cookie_name = 'wordpress_bypassw3tc';
   /* Do whatever check you need to do here to get a true flag before you set the cookie */
   // Let's say the flag variable is $flag
   if ( !$flag ) {
      // If the flag is false, remove the cookie if it exists
      if ( isset( $_COOKIE[$your_cookie_name] ) ) {
         setcookie( $your_cookie_name, time()-3600, COOKIEPATH, COOKIE_DOMAIN, false );
   else {
      // If the flag is true, creates the cookie
      setcookie( $your_cookie_name, strtotime('+1 month'), COOKIEPATH, COOKIE_DOMAIN, false );
add_action( 'init', 'bypass_w3tc_pagecache' );

Please note that COOKIEPATH and COOKIE_DOMAIN are available in WordPress.

I hope this could help someone. I would like to hear back from you with your experience, solutions, feedback etc.


One thought on “How to bypass Page Cache created by W3 Total Cache

I will be happy to answer your queries

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s