To reproduce:

  1. Use the Views module to create a page view with an exposed filter.
  2. Use Firebug or similar to watch your cookies. Make sure to clear any existing NO_CACHE cookie if you have one.
  3. Browse the site and verify that the NO_CACHE cookie is not added.
  4. Visit the page you created above. Notice that a NO_CACHE cookie has been added merely by visiting the page.

This happens because views exposed forms are method=get forms and Views uses the form API's "always_process" flag such that these forms will always be validated and submitted when displayed. Thus the Cookie Cache Bypass Advanced module responds by setting the cookie.

The result is that users who simply browse to one of these pages won't get cached pages on the site at all for a while afterwards, for no good reason.

One way to fix this is to check if there is anything in $_POST before setting the NO_CACHE cookie. This has the added benefit that it prevents setting the cookie even if the user decides to interact with the views exposed form and physically submit it (there is no reason to set the cookie in that case either since these kinds of forms do not change the site's dynamic content when submitted; it is fine for the user to keep seeing cached pages afterwards).

Comments

David_Rothstein’s picture

Status: Active » Needs review
StatusFileSize
new2.35 KB

Here is a patch that implements the above.

hey_germano’s picture

Status: Needs review » Reviewed & tested by the community

This fixed the issue for us, and the patch applies fine. Thanks!

pacproduct’s picture

Confirming patch #1 fixes the issue for us too.