I was trying to create a page for viewing items for a custom entity that is indexed in local database through Search API. The issue is that for the anonymous users, the page cache is not updated when an item is added.
I was able to reproduce the issue with a custom node type as well.
Reproduction scenario:
- Create an content type (Let's call it Article)
- Create a Search API Server (Backend: Database Backend, Word length: 3)
- Create an articles Index (with the "Index immediately" selected)
- Create a view of Indexed articles that has a page that shows either fields or rendered entity as an HTML list (Add a url like "articles")
- Set the cache in the page (views page) to be either "None" or "Search API specific"
- Visit the page "articles" as an anonymous user (The page is cached). BTW You can view it also after creating a new article so that the page is cached with an item.
- Create a new article as a logged in user.
- (Optional)Visit the index configuration to verify that 1 item is indexed
- Revisit "articles" page as an anonymous user without triggering any cache rebuild
- Page is still cached with no items shown
Is there something I am missing there? Shouldn't a tag based cache rebuilt be triggered whenever an item is added and the option "Index immediately" is selected?
Edit: Weird thing, when I was testing a behat test, I was forcing the reindexing after the creation of the collections and the items were recached for the anonymous users as well. But this is not occurring for the UI.
Comments
Comment #2
dimilias commentedComment #3
borisson_Views based on a search api index should not be cacheable, see http://cgit.drupalcode.org/search_api/tree/src/UncacheableDependencyTrai... so if those are cached, this is a bug and the http://cgit.drupalcode.org/search_api/tree/src/Tests/CacheabilityTest.ph... is not specific enough.
Comment #4
drunken monkeyJust tried it out myself, but it seems to work as expected. Are you sure you're using the latest version of the module?
Comment #5
dimilias commentedActually, I had a similar issue with the above. Indeed I could not reproduce it in all times.
Searching more on this, the actual issue is described in https://www.drupal.org/node/2616804 so this could be closed.
Comment #6
drunken monkeyComment #7
acbramley commentedHere's a test that proves the issue. The problem is that there is no node_list or similar tag added to search api views blocks so the whole page is still cached after adding a new item to the index.
Setting to Needs review to show the failing test.
Comment #9
acbramley commentedChanged the tests up a bit so here's another failing test patch plus the fix. Happy to change the placement of both the test and the fix if required.
Comment #12
acbramley commentedFixed failure.
Comment #13
borisson_I think this looks good, let's get this in.
Comment #14
drunken monkeyThanks for providing a test, and a patch to fix the problem.
However, this should then also be done when deleting items, right?
Furthermore: Wouldn't it be more sensible to have index-specific tags? Clearing views on index A when indexing on index B doesn't seem useful, and it seems this would be very easy to implement.
And, if we have that: doesn't that make the existing entity-type list tags useless and actually detrimental?
Finally, not included in my revision: Why is the new test in the (functional)
CacheabilityTestclass instead of the (Kernel)ViewsDisplayCachingTest?That being said, though, this is definitely already a big improvement. However, it should also be clear that tag-based caching for search queries currently just doesn't work reliably. You can use it, if you want, but you shouldn't expect it to work in all scenarios.
Patch attached, please test/review!
Comment #16
drunken monkeyComment #17
acbramley commentedNice improvements, thanks @drunken monkey. Reason the test was there is simply because I failed to find ViewsDisplayCachingTest before posting the patch, sorry about that!
Comment #18
borisson_Can we improve this comment?
// Check that the newly indexed node is visible on the search index.Check that the deleted entity is now no longer hidden.Comment #19
acbramley commentedFixed #18
Comment #20
borisson_Looks great
Comment #22
drunken monkeyExcellent, thanks for the review and thanks for the improved patch!
Committed.
Thanks again, everyone!