Add 'show only on a page that contains the facet source' setting and a second facetsource plugin to include view blocks

I had a conversation with effulgentsia and he had some very interesting thoughts. Some of them aligned with what we were thinking when talking to each other.

His first thought is the one inline with what we were thinking, iterating over the block list and see if it is present.

you can look at BlockPageVariant to see how it figures out what blocks to render, which is to call $this->blockRepository->getVisibleBlocksPerRegion().
So potentially, your facet block can also ask the block repository for that, and then iterate the results to determine if the Views block you're interested is in that list.
That however would couple your facet block to an assumption about how the page is being rendered (i.e., via that query to blockRepository), which is an assumption that something like Panels might break. tim.plunkett might have more insight on that.

His second thought is, in my opinion, way nicer.

if you know the $block entity for the Views block instance you care about, you can just call $block->access('view') on it rather than asking BlockRepository to do so for all the blocks you're not interested in. That access check returns FALSE if there's any visibility condition preventing the block from showing on the current page or rather, in the current context. Again though, $block "entities" is a block.module concept, so Panels might require a different mechanism for this.

If we can pass the block as a context object to our facet block, we can call that function and directly see if we need to show it or not. This allows us to execute this at runtime and does not require a whole lot of coding. We can have similar mechanisms in place for other types of view modes, if they exists. When we get to a PanelViewFacetSourceManager and hence, the generated plugins from them, we can figure out how panels discovered how to show a certain view and act on it.

Hopefully that helps us a bit further?

We solved the problem of the views page (See borisson_'s patch) but we still need work in figuring out if the view, in block modus, will be rendered somewhere on the page. For this, we need to send the views block as a context object. This might not be as hard as it sounds. We already pass the view along, so we could most likely also send the $block->access('view') method?

@borisson_: the code in #2 will always trigger when the current page is a page view (e.g. frontpage)
If you have a search-index in a block, it will always be hidden because of this.
We need to find out first if the current facet has a page view as facetsource, and only then trigger your code.

Attached is a reworked version from #2 where I moved the logic into the datasource (as this should be implemented by the datasource plugin instead of on a global level)

I also refactored the facet interface a bit, making getDataSource return an instance of the datasource plugin.
If you only need the datasource id, you can still do getDataSourceId().
I looked into the Blocks module for this, and they seem to do it like that too.

Remarks from #6 are not addressed yet, but can now live in the datasource plugin.

We should split up the functionality for pages and blocks into different facet sources. The current facetSource should be renamed to a base class (SearchApiViewsDeriverBase) and there should be 2 classes implementing that.

Yup, that sounds like a good idea!

I'm not sure about ::isBeingRendered as a method name though, I suggest ::isRenderedInCurrentRequest as a more verbose option.

isRenderedInCurrentRequest sounds good.

WIP

Started from #8 + #12

Current patch is not rendering results anymore atm. I renamed the search_api_view id to search_api_views_page to make the plugin system use the correct plugin.

#15 with a bit of variable/documentation changes attached

So, this is a quite interesting problem. Because blocks in theory are meant to be independent of the other blocks on the page. Otherwise you can't render them independently, in parallel or via ESI.

I think I agree part of the solution is to have this "Facet-for-Views-block"-block require a "Views block" Context. But… that would mean that the Views block must expose/emit another context. Which is where we enter a catch-22, enforced by the earlier mentioned requirement that blocks can be rendered independently: the visible blocks are determined by loading all the contexts, and then checking if the visibility conditions are met (see \Drupal\block\BlockAccessControlHandler::checkAccess()). I think it's not possible for that set of run-time contexts to change during a request (i.e. before the Views block is rendered, this "views block is visible" context would be FALSE, and after it is rendered, it'd be TRUE), because then execution order matters, and hence parallelism is broken.

I think you need @eclipsegc and @tim.plunkett's input here.

What I *think* we should do is the following. We add support for having a facetsource from a block that was created by views (so not the display mode). Because this block then becomes the facet source, we can pass it as context. We can then execute a $block->access() check to see if the block where the view is in would be shown and if not, we stop rendering the facet and in effect we also don't try to execute the view to get our results. We can then continue to execute our empty behavior for the facet block or whatever we like with this state. Most likely we will need to use the exact same approach when we want to add support for panel pane's with any kind of search api view in it. The pane will be the facet source, not what is in it.

Current facet_source plugins:

• SearchApiViewsPage.php
• SearchApiViewsPageDeriver.php

New facet_source plugins:

• BlockSearchApiViewsBlock.php
• BlockSearchApiViewsBlockDeriver.php

It would create a facet source for every block defined in the blocks structure that is part of a Search Api Views object that has the block display mode.

Some remarks from @wimleers:
Just be aware then that it's possible to have different "empty" behavior for the Views block and the Facet block: it's possible to hide the Views block and have the Facet block say "no facets available", which may be confusing. I think you may want to have some `hook_requirements()` checks that does sanity checks in those areas to prevent those kinds of misconfigurations.
(or at least warn people)

For reference I include the full conversation with Wim.

wimleers [10:48 AM]
@nick.veenhof: It's an excellent question, one to which we should document the answer, because it'll come up more often

nick.veenhof [10:49 AM]
What I think we will do is read out the visibility settings of the block + the access level of the view as we have that as a context to determine if it can be shown

wimleers [10:49 AM]
@nick.veenhof: But I believe what I wrote captures why this is so difficult: the system is specifically designed to NOT do something like this AFAIK.

nick.veenhof [10:49 AM]
it might not be 100% accurate, but at least it won’t depend at run-time on something somewhere else

wimleers [10:49 AM]
@nick.veenhof: So then it still breaks if the view has an empty result set?

nick.veenhof [10:50 AM]
if the view has an empty result set, the facet will also be empty, and then it triggers the empty behavior of the facet which is show nothing or show empty text

wimleers [10:50 AM]
@nick.veenhof: "visibility + access" -> no need: calling the views block's `access()` method already checks both.

nick.veenhof [10:50 AM]
ah, cool

wimleers [10:51 AM]
@nick.veenhof: Just be ware then that it's possible to have different "empty" behavior for the Views block and the Facet block: it's possible to hide the Views block and have the Facet block say "no facets available", which may be confusing. I think you may want to have some `hook_requirements()` checks that does sanity checks in those areas to prevent those kinds of misconfigurations.

wimleers [10:51 AM]
(or at least warn people)

nick.veenhof [10:52 AM]
@wimleers: true - but at least it doesn’t depend on something in the render pipeline then

nick.veenhof [10:54 AM]
wimleers: ok if I copy/paste this discussion also in that issue?

wimleers [10:59 AM]
@nick.veenhof: of course

We could, to avoid the requirements issue (where empty behavior of a view is doing different things compared to an empty facet) execute the block as a whole. The view will be cached and we will need to execute the view anyway to get the results of the search. We are already executing the view when the facet_source is a SearchApiViewsPage, so this is not too different compared to the block.

Thoughts?

With the 'show only on a page that contains the facet source' option selected, facet blocks appear on multiple pages and not only when the facet source is visible. Fixed with my last patch + added integration tests.

I'm confused now. What did #27/#28 do, if this issue is still open?

I've detected that if the 'display_id' is the same for 2 different views (I can reproduce with different backends or indexes for example) the facets will be visible in both views. To reproduce you can create 2 indexes with the same display id by default. Then you add 1 facet per facet source. Both views will display 2 facets.

This is fixed in my last patch

needs reroll