While testing https://www.drupal.org/node/2611812 I encountered a strange issue with facet block display.

I have created a search server with an index and a view as well as a facet related to displaying a list of dates. I then added a view with a page display and inserted my facet block to the first sidebar without any display conditions.

Everything works as excepted when visiting the page for the first time as when selecting a facet, but when I remove the facet again using the widget, the entire block disappears. After clearing cache the block returns, and if I refresh the page is vanishes again. I tested using several different selection, but every time I revisit a selection I have visited before the block is hidden.

Comments

jespermb created an issue. See original summary.

strykaizer’s picture

Priority: Normal » Critical

Thanks for reporting. We are just noticing the same, investigating right now...

strykaizer’s picture

Quick fix: turn off your views caching for your search api view.

We need to provide a patch so other users wont run into this.

strykaizer’s picture

Patch in #2809469: Set search api caching as default for new search api views for new views.

Fix for existing views, see #3

duaelfr’s picture

Status: Active » Closed (duplicate)
Related issues: +#2809469: Set search api caching as default for new search api views

I can confirm this is going to be solved by the related issue and can be manually solved by selecting the "Search API specific" cache engine for your view (or no cache at all if you like to live dangerously ^^).

trickfun’s picture

Sorry but after a lot of time this issue is not fixed. i have the same behaviour.
Only selecting none cache, facet works fine.

drupal 9.3.8
facet and seache api deve version

Thank you

trickfun’s picture

Any news here?
facet works only with no cache.

thank you

richarddavies’s picture

Version: 8.x-1.x-dev » 2.0.2
Status: Closed (duplicate) » Active

I can also confirm this behavior with Drupal 9.3.16, Search API 1.23, and Facets 2.0.2. My view is using Search API (tag-based) caching. Upon the first page load of the view (or after clearing all caches) the facets display as expected. After refreshing the page the facets disappear. Setting the view caching to 'none' seems to fix it, but according to the comments above it should work now with Search API caching.

bob.hinrichs’s picture

Same problem, confirmed.

mkalkbrenner’s picture

Version: 2.0.2 » 2.0.x-dev

Facets now support caching with the latest dev versions of facets and search_api.

szeidler’s picture

I can confirm #10. With both modules on the recent dev versions it works.

Note: When using https://www.drupal.org/project/facets_block it appears to be failing with the same bug like reported here.

mkalkbrenner’s picture

Category: Bug report » Support request
Priority: Critical » Normal
Status: Active » Fixed

We just wait for the upcoming Search API release to be able to release Facets 2.0.3.

wouter.h’s picture

I just did an implementation where there was a need to have proper caching.

I upgraded search api to 8.x-1.24, upgraded facets to 2.0.4 in a drupal 9.3.15 installation.

For views without facets, the "Search API (time-based)" caching works perfectly. Unfortunately on views with facets the facets disappear when reloading the page.

I tested the implementation against the latest development versions with the same results.

mkalkbrenner’s picture

Status: Fixed » Active

Until the release of Facets 2.0.4, facets never supported views caching. It is also still mentioned in our README.txt:

Q: Why do the facets disappear after a refresh?
A: We don't support cached views, change the view to disable caching.

The caching support introduced by Facets 2.0.4 is still very young and now we ran into issues:
#3295570: Search API views caching is broken with facets 2.0.4
#3295564: Views caching is broken with facets 2.0.4
#3296006: In case of an exception thrown by the backend, Search API Cache plugins always cache an empty result

Without these patches the cache metadata stored within a views config is totally random because views asks facets for their metadata during saving while facets asks views build theirs.
Please test these patches. It is very important that you re-save your views after applying them! And clear your caches.

BTW People who just upgraded the module and didn't reconfigure their views to use caching should not be affected by the issue.

mkalkbrenner’s picture

Title: Facet block vanishes after refresh » Facet block vanishes after refresh if view uses caching
Category: Support request » Bug report
mkalkbrenner’s picture

Our processor base class declare a max-age of "0".
But due to the latest changes in Search API and Facets we should consider to set it to CACHE_PERMANENT.

richarddavies’s picture

I've updated to Drupal 9.4.5, search_api 1.25, search_api_solr 4.2.8, and facets 2.0.5. I'm still having issues with disappearing facets after re-enabling Search API (tag-based) caching on a view. The facets still disappear whenever I refresh the page. Clearing the cache restores the facets, but they disappear after another page reload.

Update: Most of my search API views with facets do appear to be working correctly, but I have one problematic view where the facets always disappear after a page refresh.

Update #2: After much experimentation, I've discovered that it is the `Use hierarchy` facet setting that is causing the facet to disappear. It's a taxonomy facet and when caching is enabled and use hierarchy is checked, the facet disappears after a page refresh. If unchecked, the facet no longer disappears.

hitchshock’s picture

I can confirm that patches from #14 don't help. The issue is still reproducible.

mkalkbrenner’s picture

I maintain a big site with lots of facets, including some hierarchical ones based on taxonomy. We use time based and tag based caching there and both work very well.

But I trust you that you run into issues with your setups. But I assume that it might not be a general issue but edge cases caused by configuration detail or custom code.

So we need much more details. Ideally you debug the cache metadata throughout the initial request and the first request aterwards.

And be aware that not all sub-modules and custom or contrib modules might be compatible yet, For example: #3264284: Facets summary should be cacheable, in case facets are using cacheable source.

richarddavies’s picture

Ideally you debug the cache metadata throughout the initial request and the first request afterwards.

Can you please elaborate on how to "debug the cache metadata"?

bryandenijs’s picture

I ran into the same problem, but after some debugging I figured out that is was caused by the metatag_views module (part of the Metatags module). I will try to explain why:

Normally, when getting the view cache, the method \Drupal\search_api\Plugin\views\cache\SearchApiCachePluginTrait::cacheGet is used. When the cache hits and has results, this method will also call the $this->getQueryHelper()->addResults($results);. This stores the results in the QueryHelper and those results are later used to build the.

But the metatag_views module overrides this cacheGet method it with its own \Drupal\metatag_views\MetatagViewsCacheWrapper::cacheGet. This method does basically the same as the SearchApiCachePluginTrait::cacheGet, except that it is doing something extra for the metatags. The important thing is that is misses the call to the addResults. Therefore, when the facets are being build, the results are not added.

I got around this problem by uninstalling the metatag_views since I was barely using it. I don't really know what the solution is if you cannot or don't want to uninstall the module.

hitchshock’s picture

@bryandenijs You are right, the metatag_views module breaks facets for me too. But in my case, unfortunately, I need that module and can't uninstall it.
metatag module already has a ticket for the same issue: #3261473: Views cache wrapper overrides other modules cache logic
That patch helped me.

mkalkbrenner’s picture

Category: Bug report » Support request
Status: Active » Fixed

Thanks for sharing that information!
So I mark this support request as fixed.

Status: Fixed » Closed (fixed)

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