Hello
I have updated to domain views 7.x-1.5 today and have a problem with the "Time-based Per Domain" cache in Views:
My views have several exposed filters, that are in an external block (views setting "Exposed form in block"). Once I activate the "Time-based Per Domain"-cache, my views do not filter their content by these exposed filters any more. The views always show the same content, independent of the filters that are used.
If I deactivate the "Time-based Per Domain"-cache, my views work normally again and filter the content by the exposed filters.
I used domain views 7.x-1.4 until yesterday, and with that version, the "Time-based Per Domain"-cache worked correctly.
Any idea what is causing that problem?
I am using Drupal 7.18, Views 7.x-3.5, Domain Access 7.x-3.7, Domain Views 7.x-1.5. I cleared the drupal cache several times after updating the module.
Comment | File | Size | Author |
---|---|---|---|
#11 | domain_views-exposed-filter-cache-no-altermetadata-1882094-11.patch | 4.53 KB | zerolab |
#9 | domain_views-exposed-filter-cache-1882094-9.patch | 5.57 KB | zerolab |
Comments
Comment #1
agentrickardIt is likely related to #1705168: The cache class is always nonsense by using view->build_info to create a cache key.
Please export and attach the View here.
Comment #2
Phoenix2020 CreditAttribution: Phoenix2020 commentedAll the views of my website have this problem. Here is one example view:
Comment #3
agentrickardConfirmed.
Comment #4
agentrickardAs far as I can tell, this fails for the default Views: Cache by Time plugin as well.
It may be that Views caching is incompatible with exposed filters. Moving to the Views queue for an opinion.
Comment #5
agentrickardTo work as intended, it would appear that we have to add the exposed filter data to the cache key.
Comment #6
johnvThis problem (Views caching incompatible with exposed filters) is for all views caches, see #1055616: Query arguments should be replaced before generating cache ID
Comment #7
agentrickardGreat. Thanks @johnv.
I'm going to move this back to my queue because I'll have to change some methods once that patch lands.
Comment #8
zerolab CreditAttribution: zerolab commentedI can confirm that that while #1055616 solves the issue with Views and arguments, caching per Domain is still broken.
Will try to see if I can come up with a patch.
Best,
Dan
Comment #9
zerolab CreditAttribution: zerolab commentedAs https://drupal.org/files/issues/views-1055616-152.patch is already in Views 7.x-3.8, here is the first attempt at a patch based on it.
Feedback is very much welcome.
Comment #10
agentrickardIt's been a long time since I looked at this code, but I wonder why we touch AlterMetaData and Views does not.
Compare https://drupal.org/files/issues/views-1055616-152.patch
Comment #11
zerolab CreditAttribution: zerolab commentedGood question. It comes from #1705168: The cache class is always nonsense by using view->build_info to create a cache key and the reason for it was that
***CURRENT_TIME***
is unique.The login in the patch from #1055616: Query arguments should be replaced before generating cache ID works well, even with query subsitutions. I take it was a Views issue, rather than Domain Views.
I have done a few tests without AlterMetaData and the results are encouraging. Here's the simplified patch.
Cheers,
Dan
Comment #12
agentrickardGiven that this works better than the current code, I'm tempted to commit it. I'd like someone else to review the functionality, though.
Comment #13
NitebreedThis works great
Comment #15
agentrickardThanks for the review!