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

dimilias created an issue. See original summary.

dimilias’s picture

Component: Framework » Database backend
Issue summary: View changes
borisson_’s picture

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.

drunken monkey’s picture

Status: Active » Postponed (maintainer needs more info)

Just tried it out myself, but it seems to work as expected. Are you sure you're using the latest version of the module?

dimilias’s picture

Actually, 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.

drunken monkey’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)
acbramley’s picture

Status: Closed (duplicate) » Needs review
StatusFileSize
new921 bytes

Here'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.

Status: Needs review » Needs work

The last submitted patch, 7: 2676468-page-cache-7.patch, failed testing.

acbramley’s picture

Status: Needs work » Needs review
StatusFileSize
new2.21 KB
new3.35 KB

Changed 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.

The last submitted patch, 9: 2676468-page-cache-failing-test-9.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 9: 2676468-page-cache-9.patch, failed testing.

acbramley’s picture

Status: Needs work » Needs review
StatusFileSize
new3.98 KB

Fixed failure.

borisson_’s picture

Status: Needs review » Reviewed & tested by the community

I think this looks good, let's get this in.

drunken monkey’s picture

Title: Page cache for anonymous users are not cleared when using Views » Page cache for anonymous users is not cleared when using Views
Component: Database backend » Views integration
Status: Reviewed & tested by the community » Needs review
StatusFileSize
new5.23 KB
new6.3 KB

Thanks 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) CacheabilityTest class 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!

Status: Needs review » Needs work

The last submitted patch, 14: 2676468-14--search_api_list_cache_tag.patch, failed testing.

drunken monkey’s picture

Status: Needs work » Needs review
StatusFileSize
new967 bytes
new7.01 KB
acbramley’s picture

Nice improvements, thanks @drunken monkey. Reason the test was there is simply because I failed to find ViewsDisplayCachingTest before posting the patch, sorry about that!

borisson_’s picture

Status: Needs review » Needs work
  1. +++ b/tests/src/Functional/CacheabilityTest.php
    @@ -57,4 +57,30 @@ public function testFramework() {
    +    // Get the page again.
    +    $this->drupalGet('search-api-test-search-view-caching-tag');
    +    $this->assertSession()->pageTextContains('Displaying 6 search results');
    

    Can we improve this comment?

    // Check that the newly indexed node is visible on the search index.

  2. +++ b/tests/src/Functional/CacheabilityTest.php
    @@ -57,4 +57,30 @@ public function testFramework() {
    +    // Get the page again.
    

    Check that the deleted entity is now no longer hidden.

acbramley’s picture

Status: Needs work » Needs review
StatusFileSize
new7.07 KB
new862 bytes

Fixed #18

borisson_’s picture

Status: Needs review » Reviewed & tested by the community

Looks great

drunken monkey’s picture

Status: Reviewed & tested by the community » Fixed

Excellent, thanks for the review and thanks for the improved patch!
Committed.
Thanks again, everyone!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.