The Facet API dependency system allows for progressive disclosure of facets. For example, you can configure things like taxonomy facets to only be displayed when content types the field is attached to are active. Refer to #551620: Type dependent facet blocks for the use case.
For some reason the dependency system is not working with Search API. Specifically, the dependency form is not accessible. The path to the dependency form shoudl be admin/config/search/facetapi/%facetapi_adapter/%facetapi_realm/%facetapi_dependencies/dependencies and should show up as a contextual link. Navigating to that page manually shows a "page not found".
Comment | File | Size | Author |
---|---|---|---|
#18 | 1215526--facetapi-bundle-dependency-18.patch | 1.47 KB | drunken monkey |
#17 | search_api-1215526-17.patch | 1.09 KB | cpliakas |
#1 | dependency-link.png | 127.6 KB | cpliakas |
#1 | dependency-form.png | 84.89 KB | cpliakas |
Comments
Comment #1
cpliakas CreditAttribution: cpliakas commentedThe attached screenshots show the dependency link and form respectively.
Comment #2
cpliakas CreditAttribution: cpliakas commentedAlso, very open to this being a Facet API bug.
Comment #3
drunken monkeyI could imagine this not working for nested fields (e.g., taxonomy terms on the author) as Facet API probably wouldn't know that those are fields, too. However, no real idea what could cause this for normal fields, as I don't know how this is constructed in the first place.
Comment #4
cpliakas CreditAttribution: cpliakas commentedWell, Facet API does know about the fields it is attached to based on the "field api name" key. There is an isssue posted at #1215520: The "field api name" key should only be set for Field API fields, not all properties. But even if that key isn't present or valid, then the "A content type this field is attached to must be active" option isn't presented and you still have the option to select the content types manually. Regardless, the form isn't even showing up to select the options. I suspect that the dependency plugins aren't being set in the facet info.
Comment #5
cpliakas CreditAttribution: cpliakas commentedLooks like the dependency plugins aren't getting set. I added them in commit 43f3220. The "A content type this field is attached to must be active" option will start working once #1215520: The "field api name" key should only be set for Field API fields, not all properties is resolved. The only thing that needs work is that we don't want a "bundle" dependency for "bundle" facets. Not sure how to check for that. Marking thread as "needs work" for that reason.
Comment #6
drunken monkeyWhat do you mean by that?
Comment #7
cpliakas CreditAttribution: cpliakas commentedSo let's take a simple example. Vocabulary "A" is attached to content type "B" via a term reference field. That field is exposed as a facet. We would use the dependency system to say, only show the facet for Vocabulary A when content type B is selected as an active item, and not content types C, D, E, and so on.
If bundles can be dependent on bundles, then the facet would never be displayed. In other words, the facet would only be shown if one of it's own values was selected, which makes no sense because how would you select it in the first place?
Comment #8
drunken monkeyAh, OK, now I get the whole system! Thanks for clearing that up!
However, how does the Facet API know whether a bundle facet is active? This currently doesn't seem to work with the Search API – do we have to do something for that?
Comment #9
cpliakas CreditAttribution: cpliakas commentedThinking about this further, there may be some assumptions I have to battle. Dependencies are simply "plugins", and all of the logic can be found in the execute() methods of the appropriate plugins. Take a look at the FacetapiDependencyBundle::execute() method for a working example. An evil troll must have come down in the middle of the night and hard coded "bundle" in there. Then he left and I never saw him again.
Comment #10
drunken monkeyOh, OK, that's nasty … Then I guess you'll really have to change that somehow. Or we could just use "bundle" as the key for bundle fields as a work-around. If that would work … (Hm, it wouldn't, without us then re-converting when doing the actual filtering.)
Or we just remove "bundle" from the dependency plugins for now.
Comment #11
cpliakas CreditAttribution: cpliakas commentedPosted an issue at #1222754: Resolve assumptions in the "bundle" dependency plugin to resolve this assumption. Also gave credit to Search API in the "Attribution" section of the Facet API project page for helping to identify such assumptions.
Comment #12
drunken monkeyI removed the declaration of the "bundle" dependency plugin support for now, so users won't be confused. Supporting it will then be a feature request, I guess.
Comment #13
cpliakas CreditAttribution: cpliakas commentedI don't mind working on this. Adding support should be pretty straight forward, we just need to know the machine readable names of the Field API fields and whether is contains bundle data or not. I ended up resolving the remaining assumptions in the Facet API module, so HEAD should be ready for Search API integration.
Comment #14
cpliakas CreditAttribution: cpliakas commentedAssigning to myself, just as a reminder to work on it. Of course, anyone who wants to take this on is more than welcome.
Comment #15
cpliakas CreditAttribution: cpliakas commentedMoving to Search API module.
Comment #16
cpliakas CreditAttribution: cpliakas commentedTagging with "Facet API Integration".
Comment #17
cpliakas CreditAttribution: cpliakas commentedThe attached patch adds the "field api bundles" key for fields that contain bundle data. For all other fields, the bundle dependency is activated.
Comment #18
drunken monkeyOK, that seems easy enough. Had to fix some notices and Entity API weirdnesses, though. Revised patch attached.
However, as long as dependencies don't work at all at the moment (#1337292: Facet dependency system doesn't work) it's probably rather pointless to add this now. As well as hard to test.
Comment #19
cpliakas CreditAttribution: cpliakas commentedAgreed. My work on this issue is what helped discover the issue, and clearly this one is dependent on the other.
Thanks for reviewing! Like your changes. At least we have this on the back burner.
~Chris
Comment #20
drunken monkeyEverything seems to work fine now with #1337292: Facet dependency system doesn't work committed and the patch in #18.
Unless there are any objections, I'm gonna commit that on Monday or Tuesday.
Comment #21
cpliakas CreditAttribution: cpliakas commentedConfirming that the patch in #18 works.
Comment #22
drunken monkeyThanks for testing!
Committed.