Context:
- I have a View based on a S.API. index of nodes of given type with an exposed filter (Search: Fulltext search) that acts as a search box
- Views is patched with https://drupal.org/node/1055616#comment-8610445 (to kill a remarkably similar bug to this reported here, seen with the default Drupal search system used previous to this context)
- Both exposed filter and search results displays are in panel regions on a panel page (panel caching DEACTIVATED)
- Views caching is activated "Search Specific" + "1hour/1hour" for the caching of query and rendered results respectively
A first search in the exposed filter returns results listing as expected.
A second search for totally different terms (with no chance of overlap mistake) return exactly the same results
>>> Deactivate "Rendered results" caching and the problem goes away...
So, the patch above to views fixed almost exactly this issue (as seen from the UI) ... so is it possible that code in S.API views interaction is causing this? Perhaps the patch is causing this...
Any one seen this?
Comment | File | Size | Author |
---|---|---|---|
#12 | search_api_views-patch_views_cache-2281535-11.patch | 1.79 KB | areynolds |
#10 | search_api_views-patch_views_cache-2281535-10.patch | 2.11 KB | areynolds |
#4 | search_api_views-patch_views_cache-2281535-4.patch | 1.88 KB | mariacha1 |
#2 | patch_views_cache.patch | 1.36 KB | nicola85 |
Comments
Comment #1
aheimlichI know that there were changes made to the way Views generates cache keys in 7.x-3.8 (see http://cgit.drupalcode.org/views/commit/?id=0cb96e5269a5479498b6ca9f5176...). Looking at Search API's Views cache plugin, it doesn't appear to take those changes into account. Specifically,
$this->view->result
is no longer used in generating the output cache key.Comment #2
nicola85 CreditAttribution: nicola85 commentedThe attached patch fix "Search-specific" caching system with Views 3.8
Comment #3
daveferrara1 CreditAttribution: daveferrara1 commentedYep seeing it on our site. Cache set in views causing queries to fail. Trying the patch now.
Comment #4
mariacha1 CreditAttribution: mariacha1 commentedThis was happening for us as well. The patch fixed it and looks sound.
The only issue is that if you haven't upgraded to views 3.8, the previous patch breaks caching in exactly the same way. So we'll need to make sure the site is running the latest version of views as well.
Adding that to the .info file with the enclosed patch, which is otherwise identical to the patch in comment #2.
Comment #5
drunken monkeyThanks for reporting this problem and thanks to nicola85 for already providing this patch!
However, I wouldn't want to add a versioned dependency to the module, and especially not to such a recent version (that might also break other contrib modules, I guess).
Can we not just also add a
get_results_key()
method that contains exactly the same as the parent in 3.8? Would that maybe work with both? I'd really like to be compatible with both, if possible.Comment #6
drunken monkeyComment #7
dbassendine CreditAttribution: dbassendine commented+1 - we were seeing the same issue, and the patch resolved it.
Comment #8
Exploratus CreditAttribution: Exploratus commentedI was having the same problem. Patch worked for me.
Comment #9
drunken monkeyAs said, it would be great if someone could provide a patch that works with both Views versions.
Comment #10
areynolds CreditAttribution: areynolds commentedOk, re-rolled this based on @drunken monkey's suggestion, works based on my testing.
One (semi-related) question: why is the cache plugin .inc file called plugin_cache.inc in search_api_views? The handler name for the cache plugin is "SearchApiViewsCache", but the hook_views_plugin() documentation says that the "handler" attribute should be both the name of the file and the handler function. I'd expect the .inc file to be called "SearchApiViewsCache.inc" (or to rename everything to "search_api_views_cache", which would follow the Views naming convention better). I can't even get the search_api_views cache plugin to load in my debugging unless I do one of those two things...
Comment #12
areynolds CreditAttribution: areynolds commentedOops, that patch was based on 7.x-1.x, here's one for 7.x-1.12.
Comment #13
areynolds CreditAttribution: areynolds commentedComment #14
mariacha1 CreditAttribution: mariacha1 commentedPatch #12 works with both views 3.7 and views 3.8, from my tests. Setting to RTBC.
Comment #15
drunken monkeyGreat job, thanks a lot. Seems to work fine for me, too.
Committed.