As the title describes, there is an inherent bug in the "Query results" (AKA "results" in code) caching system.

When the standard cache plugin builds the cache key, it uses the following code to produce a SQL string to use in the md5 hash:

<?php
class views_plugin_cache extends views_plugin {
  ...
  function
get_results_key() {
    ...
   
$query = clone $build_info[$index];
   
$query->preExecute();
   
$build_info[$index] = (string)$query; // <<< This is the line I am referring to
   
...
  }
}
?>

Reproduction

I created a basic view with the following basic configuration:

  • Filters:
    1. "Content: Type", hardcoded to "page"
    2. "Content: Published", exposed
  • Caching: (time based)
    • "Query results": 1 hour
    • "Rendered output": Never cache

When the view is executed, that line, (string)$query produces the following string for the view I built:

SELECT node.nid AS nid
FROM
{node} node
WHERE (( (node.type IN (:db_condition_placeholder_0)) AND (node.status = :db_condition_placeholder_1) ))

As you can see, there is nothing in that query that specifies the "Content: Published" filter. Test it for yourself: if you change the exposed filter once the cache has been built once, the view will show the same results.

I think we should change that single line to the following:

<?php
  $build_info
[$index] = strtr($query, $query->getArguments());
?>

For the same view, that will produce the following string:

SELECT node.nid AS nid
FROM
{node} node
WHERE (( (node.type IN (webform)) AND (node.status = 0) ))

That is an improvement, as exposed filters will now work correctly with query caching. Patch coming.

Files: 
CommentFileSizeAuthor
#1 views-1469950-1.patch564 bytesnicksanta
PASSED: [[SimpleTest]]: [MySQL] 1,392 pass(es).
[ View ]

Comments

StatusFileSize
new564 bytes
PASSED: [[SimpleTest]]: [MySQL] 1,392 pass(es).
[ View ]

And here it is

Not RTBCing until #1473628: Establish criteria for requiring tests is resolved, but that looks correct to me.

It's probably a competing patch, to be honest. I'll post this as a suggestion in the other issue.

Are there any news regarding this problem? A official solution?

I use exposed filters for some of my cached views. Yesterday (after some calls from my customers) I found out that these views do not respect the exposed filters once they are cached

I found some issues here, and all of them have different patches. For example:
http://drupal.org/node/1352362
http://drupal.org/node/1055616
http://drupal.org/node/1469950

So what is the right/best solution to solve this problem?

All the issues linked in #5 duplicates each other, I guess. Anyone knows which is the best issue to follow in order to know when this problem will be fixed in the next views release?

The best solution is that you / we test out the patch and if it works set the issue to reviewed and tested...

I applied the patch in #1 and it seems to work, but some of the filters still behave strangely. I think it is returning the right results, but sometimes the value shown in the field changes to something other than what was selected. This could be confusing to users because they can't tell if they're looking at the right results.

Version:7.x-3.3» 7.x-3.x-dev

Changing version for the testbot.

Status:Needs review» Needs work

The last submitted patch, views-1469950-1.patch, failed testing.

Status:Needs work» Needs review

#1: views-1469950-1.patch queued for re-testing.

Status:Needs review» Needs work

I dont see this patch in the queue, http://qa.drupal.org/pifr/queued, no result for 2 days?

Status:Needs work» Needs review

#1: views-1469950-1.patch queued for re-testing.

I have been having this problem in 6.x-3.0 as well. My temporary workaround has been to disable caching for my views which use exposed filters, but obviously this is unacceptable as a long-term solution. Is this going to be backported to 6.x?

I had better results with the patch in #1055616: Query arguments should be replaced before generating cache ID which seems to address the same issue.

marking this as a duplicate of #1055616: Query arguments should be replaced before generating cache ID.
Both address the same problem in a different way.

Status:Needs review» Closed (duplicate)