From the architecture (#2348781: Architecture):

SearchersFacet sources

For example, search api has a server A, and an index A1 and we want to create a facet A1Title on top of this. The form to add facets gives you the option to give your facet a name and whether or not to add a block for it. It then will load all plugins of the type "Facet source" with the filters "search_api" and "index A1". There will be a general plugin for full page contexts (SearchApiFacetSourcePlugin) but also Views specific plugins, which are created automatically (ViewsFacetSourcePluginDeriver).

These plugins come with their own configuration and allow you to select the field that you want to facet on. In both cases, the search api index is known by the plugin and we can fetch the list of fields that are indexed.
The Facet Source Plugin also passes a list of allowed Query Types along, since the Facet Source knows exactly which field you want to facet on.

TODO

- Create FacetSourcePluginManagerInterface interface in src/FacetSource
- Create FacetSourcePluginManager class in src/FacetSource
- Create FacetSourceInterface interface in src/FacetSource
- Create FacetSourcePluginBase class implementing the FacetSourceInterface in src/FacetSource

First define the interfaces, especially the FacetSourceInterface. It should contain methods to retrieve:

  1. Allowed query types
  2. Allowed fields
  3. Any other things?

Furthermore it might be an idea to add a method executeQuery, which is able to execute the native query it is attached to (for instance the view), so the adapter can ask the facet source to execute it's search (the Facet should not be able to do this. Only the adapter).

Comments

jurcello created an issue. See original summary.

borisson_’s picture

Title: Create searcher plugin manager » Create Facet source plugin manager
Issue summary: View changes
borisson_’s picture

Assigned: Unassigned » borisson_

  • borisson_ committed c5e99b3 on 8.x-1.x
    Issue #2581297: Create Facet source plugin manager
    
borisson_’s picture

I added my work in progress to the main branch. This broke the Integration test, but that's one thing I'll fix today.

There is currently a bug in the code that produces the subform for selecting the facet field twice, that needs to be fixed still.

  • borisson_ committed 0187c89 on 8.x-1.x
    Issue #2581297 - Fix facet add form.
    
  • borisson_ committed 139e48c on 8.x-1.x
    Issue #2581297: Facet source plugin manager wasn't defined as a property...
  • borisson_ committed eb7c0de on 8.x-1.x
    Issue #2581297: Create Facet source plugin manager - make sure the...
borisson_’s picture

@Nick_vh worked on this issue earlier today and posted some of his findings in irc:

20:41 Nick_vh: borisson_: so what you are trying to fix is that double form or what exactly?
20:42 borisson_: Nick_vh: double form should be fixed now. It looks like the ajax-form for facet sources triggers on the widget ajax now.
20:42 Nick_vh: so that’s the only thing right?
20:42 borisson_: Strangly enough, without javascript everything works as it's supposed to.
20:42 borisson_: Yes. That should be the last thing. Probably test will still fail but I think that is related to the actual test code.
20:46 Nick_vh: borisson_: so what I see is that when you select something in that field it submits using the wrong button in ajax
20:46 Nick_vh: it submits it using facet_source_configure
20:47 borisson_: that shouldn't happen. :)
20:58 Nick_vh: borisson_: indeed confusing
21:18 Nick_vh: borisson_: this is really freakingly weird
21:18 Nick_vh: from what I see, it submits the whole scope
21:18 Nick_vh: and somehow takes the facet_source as the true source
21:19 borisson_: Nick_vh: I agree that is really weird.
21:22 Nick_vh: borisson_: somehow the 'trigger_as' => ['name' => 'widgets_configure'], isn’t functioning correctly
21:22 Nick_vh: in the JS it sends to drupal it shows _triggering_element_name:widgets_configure
21:22 Nick_vh: so that’s correct
21:23 Nick_vh: what happens after seems to be very vague
...
21:31 Nick_vh: I identified the cause more or less
21:31 Nick_vh: find FormAjaxSubscriber.php
21:31 Nick_vh: and see the function onException(… $event)
21:31 Nick_vh: there is the Ajax response being built
21:31 Nick_vh: they have $event->getException()->getFormState()
21:32 Nick_vh: for some reason, that form_state is wrong OR cached
21:33 Nick_vh: and if you look at the cache tags
21:33 Nick_vh: there’s nothing that separates it
21:34 Nick_vh: user.roles:authenticated and config:facetapi.facet.user_facet
21:34 Nick_vh: I wonder if these separate facet forms (read: ajax) need special cache tags
21:34 Nick_vh: so maybe it is a Wim Issue
21:35 borisson_: it might be, yeah.
21:36 Nick_vh: borisson_: can you try to disable all caching
21:36 Nick_vh: and see if it works?

I followed up on Nick's last suggestion by disabling page_cache and dynamic_page_cache; that didn't seem to make any difference.

borisson_’s picture

This ended up being a really stupid typo, thanks for figuring it out @Nick_vh.

borisson_’s picture

Priority: Normal » Major
Status: Active » Needs work

This needs more work for:

  1. Allowed query types
  2. Allowed fields
borisson_’s picture

Assigned: borisson_ » Unassigned
borisson_’s picture

Status: Needs work » Fixed

@Nick_vh already did this. Closing the issue.

Status: Fixed » Closed (fixed)

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