W3 Total Cache – Issues with HTTP 301/302 PageCache [workaround]

  • Greetings,

    I was having issues with redirects showing up blank pages if the page had a previous request (was cached).

    I’ve encountered a few reports mentioning similar issues with redirects, and previously with 404 which has been fixed in code.

    I’ve made a patch to ignore 301 and 302 when caching, but a better patch would be to cache these pages alongside with status and headers (out of my programming skills though).

    Here’s the patch, for version 0.9.4.1, if it helps someone. I wonder if there’s any chance it might be included in W3 Total Cache while there’s not a better solution:
    #### PgCache.php.patch ####

    --- PgCache.php	2015-05-19 18:09:13.783922562 +0100
+++ PgCache.php.new	2015-05-19 18:09:13.783922562 +0100
@@ -572,6 +572,13 @@
             return false;
         }

+	/**
+         * Don't cache redirects (301,302)
+         */
+        if (function_exists('http_response_code') && in_array(http_response_code(),array(301,302)) ){
+                return false;
+        }
+
         return true;
     }

    Regards,
    Manuel

    https://www.ads-software.com/plugins/w3-total-cache/

Viewing 3 replies - 1 through 3 (of 3 total)

  • I am seeing these problems too (pages that should be redirected are getting cached), Will do a bit more research, I think it might be caused by a wp_redirect that doesn’t have an exit immediately following it… might be wrong as this is just my initial evaluation

    From what I know, redirects should be called in the get_header hook.

    I’ve programmed all my redirects that way and I’m facing no problems in a MU-setup, and also be sure to exit the redirect as Eddie said.

    If you’ve programmed your own redirects be sure to check out when they’re called and adjust those when possible.

    Thread Starter msousa

    (@msousa)

    Thank you both for your comments, and in one of the cases I’d also noticed the hook that was getting called wasn’t get_header and read it should be.

    However I didn’t go this route since this issue also happens with plugins we don’t develop, such as the domain mapping one, and probably others.

    I don’t think there’s any case in which the W3TC, as it’s working now, should cache the 301/302 and as such opted to deliver the workaround at the W3TC plugin instead of all possible plugins that might have the wrong hook.

    The plugins should fix the issue, but W3TC shouldn’t cache responses that will produce issues. 404 already has the exception, 301/302 have caused issues to me and other, but probably anything other then 200 shouldn’t be cached.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘W3 Total Cache – Issues with HTTP 301/302 PageCache [workaround]’ is closed to new replies.