Rendered output caching displays the same page content on two different views queries

Eldon.T
Can you provide instructions to reproduce this bug using basic fields from common content types as well as an export?

.

This could also be used by a wrong caching plugin.

Closing from a lack of activity.

I'd like to reopen this issue, as I can replicate it too. When using views caching with 2 different views pages that have the same results, the first page accessed is displayed in both places. This is because the get_output_key() function is basically only using the result to create the key. I think this should use the build_info like the get_results_key() function does, so we can better determine unique view displays.

The example I came across this with was a view with an argument of Taxonomy: Term. If two terms each had the same results, ie one node had 2 terms. Which ever page was visited first would be displayed for both.

I have attached a patch that should fix this.

Hi, I had exactly the same problem.
Your patch fixed the issue, thanks.
I mark it as reviewed by the community, it would be great if this could be commited.

I am experiencing this same bug (output caching displaying the same content for two different views queries) in 6.x-3.x when the result set is empty because the output cache key is dependent on the result, but not on the query itself. This is a problem because, for instance, if using exposed filters, searching with one value in a Node: Title filter (eg. One Fish) which returns an empty result will cause the output to be cached. Searching for a different value in Node: Title filter (Two Fish) will match the first (because both have an empty result set) and the cached output will be returned. This causes the Node: Title filter value to show the first value (One Fish) entered instead of the second, making it appear the second filter failed when in fact it did work.

Here's a patch rolled against 6.x-3.x to fix the above problem. If I should have opened a new issue instead of updating this one, please feel free to reset version and status.

I discovered that substitutions are also ignored in both result and output caching. Because views query substitutions can drastically alter a query, I believe these should also be part of both the result and output cache key. This patch adds substitutions to the result cache key and uses the result cache key (rather than the result itself) as part of the output cache key.

@pdrake, The some remarks about this patch:
- The following line should not be necesary:
+ 'substitutions' => $this->view->substitutions(),
Check out #1055616-22: Query arguments should be replaced before generating cache ID, where $this->view->exposed_input is added to the input key to differentiate between 2 different queries on the same view.

views query substitutions can drastically alter a query

[EDIT]Do you have an example? all substitutions I've seen are regarding display, not the query. (titles, etc.)

Indeed they do, an example is the argument in the URL, like /nodes/%/showsomething, where % is translated as substitution '!1'.

PS , I come from #1606292: Share result-cache between displays with same results and different output

In this case, I'm not referring to exposed filters or title substitutions but views substitutions made via hook_views_query_substitutions. These do need to be accounted for when generating the cache id as they do not exist in the other elements currently used for this purpose. One example of this is ***CURRENT_USER*** when using the User: UID argument with "Currently logged in user".

Can you test #1469950-1: "Query results" caching does not respect changed values of exposed filters ?

Does this patch automatically include 'your kind of subsitutions' in the query string. (Or are they applied after the query is run?)
In which part of the structure are your substitutions declared?

[EDIT] I think #1055616: Query arguments should be replaced before generating cache ID is another variant of the same problem: not adding all query-details to the result_key.