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.

CommentFileSizeAuthor
#1 views-1469950-1.patch564 bytesnicksanta
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nicksanta’s picture

FileSize
564 bytes

And here it is

tim.plunkett’s picture

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

tim.plunkett’s picture

nicksanta’s picture

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

Jake081’s picture

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?

antoniopironti’s picture

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?

giorgio79’s picture

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

heatherwoz’s picture

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.

tim.plunkett’s picture

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.

tim.plunkett’s picture

Status: Needs work » Needs review

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

giorgio79’s picture

Status: Needs review » Needs work

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

giorgio79’s picture

Status: Needs work » Needs review

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

giorgio79’s picture

phenaproxima’s picture

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?

heatherwoz’s picture

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.

johnv’s picture

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.

johnv’s picture

Status: Needs review » Closed (duplicate)