I've come across quite a tricky bug for caching of views with exposed filters, so let me just give a brief background.

I had a view (panel pane inside panel page) which displays a list of content (10 results + pager) with a single exposed filter which links to select a taxonomy term.

The options were

Any
Term 1
Term 2
Term 3

For some reason whenever Term 1 was selected (done with AJAX) the result was that it was reset to Any while Term 2 and Term 3 worked fine.

After a lot of time running through the code I belive that the error is that the way views create the cache key for the view is:

<?php
$key_data
= array(
       
'result' => $this->view->result,
       
'roles' => array_keys($user->roles),
       
'super-user' => $user->uid == 1, // special caching for super user.
       
'theme' => $GLOBALS['theme'],
       
'language' => $GLOBALS['language'],
      );
?>

This is fine for a lot of cases, but in the case where a single selection of an exposed filter matches another result ("Any" in my case) views will handle those two results like they are the same and return the cached version, Any or Term 1 whichever was rendered first.

Editing one of the 10 first nodes and changing the term "fixed" the issue.

Files: 
CommentFileSizeAuthor
#1 views_cache_key-1802056-1.patch716 bytesgoogletorp
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

Comments

Status:Active» Needs review
StatusFileSize
new716 bytes
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

I created a pretty simple patch to add the exposed filter raw input to the cache key if it's there.

I don't know if there is a better solution but this fixes my problem.

Version:6.x-2.16» 6.x-2.x-dev
Status:Needs review» Reviewed & tested by the community

We use this fix in production, as it does solve the problem.

Status:Reviewed & tested by the community» Closed (duplicate)

Issue #1055616: Query arguments should be replaced before generating cache ID has a more extensive patch, tested by many.