Closed (fixed)
Project:
Facet API
Version:
7.x-1.x-dev
Component:
Documentation
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
17 Dec 2011 at 20:23 UTC
Updated:
12 Jan 2012 at 21:30 UTC
From within a facetapi dependency plugin class, i need to deactivate the dependency's facet as a reaction to a dependency situation. How can this be done? How can you deactivate a facet from within its dependency plugin?
Comments
Comment #1
cpliakas commentedSorry, but I don't understand what you are trying to do. A dependency is a condition (such as a user's role or the an active facet in another field) that must be satisfied in order to display the facet. If I can get some more specifics on you use case and what you are trying to accomplish, I can provide some assistance.
Thanks,
Chris
Comment #2
danielnolde commentedI wrote a plugin class FacetapiDependencyFacet that enables/shows a facet "Product categories" if another facet "Content type" is active, so you can see and filter by product categories if you first filter the search by content type. This all works great. Okay, so now both of these facets are active (user selected maybe "product" in facet "content type" and then "magazine" in the depending facet "product category"). So far, so good.
But next, the user unchecks the "product" item in the "content type" facet.
Now what happens currently is that the "content type" facet becomes inactive (as intended), but the "product category" facet, which depends on the "content type" facet being active, still stays active - which is not what's intended by the defined dependency.
What i want is to be able to deactivate the depending "product category" facet once the "content type" facet, on which it depends, becomes inactive itself.
How could i do that?
Comment #3
danielnolde commentedSet to "active". For a better and more tangible description see #2.
Comment #4
SergeyR commentedin fact "product category" is active only in sense to be presented in URI -actually no filtration (see temprary tests:)
http://kantor.akku.ru/test initial point -results count 5
http://kantor.akku.ru/test?f[0]=type%3Aproduct content type -"products" selected -results count 3
http://kantor.akku.ru/test?f[0]=type%3Aproduct&f[1]=field_pc%3Akey1 product category "magazin" selected -
results count 2
http://kantor.akku.ru/test?f[0]=field_pc%3Akey1 content type -"products" unselected -results count 5 (again as at initial point)
if you select content type -product again -next step -selection of product category will be repeated automatically the same as before -i dont know is it good or not? -case by case ))) may be you meaned for desactivation "cleaning of history" ???
Comment #5
danielnolde commentedInteresting tes, Sergey – but when i repeate your steps on my facetted search, the behaviour is different:
1. No facets active: 148 results
- vm.local/en/search?s=magazine
2. Facet "content type" set to "product":102 results
- vm.local/en/search?s=magazine&f[0]=unified_content_type%3Avalue%7Cproduct
3. Facet "product category" additionally set to "Mobile": 7 results
- http://ringier.local/en/search?s=magazine&f[0]=unified_content_type%3Ava...
4. Facet "content type" from step 2 now deactivated (leaving only depending facet "product category" active): 7 results
- http://ringier.local/en/search?s=magazine&f[0]=field_product_category%3A27
Expected behaviour after step 4: 148 results (no filtering by "product category" when depenency facet "Content type" is deactivated).
Actual behaviour observed: dependent facet "product category" stays active in url _and_ filtering of search results when dependency facet "Content type" is deactivated.
So my initial question seem to stay on the table: How can an active facet be deactivated from within a dependency plugin class configured for that facet?
Comment #6
cpliakas commentedThanks for the clarification, guys!
Just to parrot back, I am thinking that the request here is that the dependent facets should be deactivated when the facet item they depend on is deactivated. This would be similar to how hierarchical facets work, in that all children are automatically deactivated when the parent is deactivated.
SergeyR brings up a great point that Facet API does respect this and doesn't process facets that don't meet their dependencies even though the values still exist in the query string. The dependent facets are also stripped from the FacetapiAdapter::activeItems property, so any code that correctly implements the API to get the active items (e.g. uses FacetapiAdapter::getActiveItems() or FacetapiAdapter::getAllActiveItems()), shouldn't list the dependent facets as active.
Ideally these values would be removed from the query string, but there are technical challenges that would need to be overcome in order to meet that requirement. We would probably have to re-execute the dependency plugins or test whether values in the query string a re valid and explicitly deactivate them when the query string is built. I haven't looked into it too deeply, but to me this is pretty low priority and would need a community contribution to drive this home in the near term.
Comment #7
cpliakas commentedI just tested this with the core Content type dependency plugin and it works as expected. Which search module are you using?
Comment #8
SergeyR commentedDaniel
i made test more close to yours (starting with fulltext search "magazin" )
see again: http://kantor.akku.ru/test
result is perfect anyway
PS i use search api with solr search
Comment #9
danielnolde commentedSergey, you're absolutely right, thanks!
In my custom dependency-plugin code there was still a part that kept the depending facet active if it has an active term itself, no matter whether the main dependency is met. Refactered that, now everything works as described by Sergey - thanks again for pointing me in the right direction here!
So this works for me a.t.m.! As you both say, it would of course be a really nice to have (but not more) to have such depending facets (who's dependency is not met) removed from the url, too - but this is rather nerd-cosmetics for most use cases, so i'm fine here.
Thanks guys!
So, i'm going to commit a module with these three components to my git sandbox soon (have to run coding standards compliance test still):
* dependency plugin to make one facet depend on another facet or a specific facet item being active (regexp enabled)
* filter plugin for rewriting facet item (by configuring a callback function in the facet filter interface, regexp enabled, e.g. to change item values before display)
* filter plugin for excluding configurable facet items (by value or markup, regexp enabled)
All three are very handy in many cases, complement the facetapi builtin filters and dependencies very well, and are rather lean, so perhaps it makes sense to integrate them into facetapi.module rather than an facetapi_bonus.module in a git sandbox?
Chris, what do you think?
Comment #10
SergeyR commentedhttp://drupal.org/node/1218714
Comment #11
cpliakas commenteddanielnolde,
Thanks for the contribution! Very excited to try it out, and the items you mentioned sound very useful. I would actually recommend that the project exist outside of Facet API for a few of reasons. One is that the more people who maintain Facet API related code the better, as it increases the expertise pool which is good for Drupal in general. I see that you currently aren't maintaining any modules, so this would be a perfect entry point to get started. The second reason is that I want to keep Facet API as lean as possible so it is easier to maintain. The final reason is that the more contributed modules that are hammering on the API the stronger it will become.
Thanks again, and I think many pople will find your code useful.
~Chris
Comment #12
danielnolde commentedOkay, thanks for the feedback, Chris! And Sergey, interesting other issue at http://drupal.org/node/1218714 you point to, the code in http://drupal.org/files/facetapi-1218714-parent-dependency.patch looks a lot like my dependenc filter (i could have spared some time, had i known of this issue <:), i mighty connect to Yuriy to discuss putting our code together. Thanks again, guys!
Comment #13
danielnolde commentedI commited the dependency plugin to the new Facet API Bonus module: http://drupal.org/node/1388266. It contains:
* dependency plugin to make one facet depend on another facet or a specific facet item being active (regexp enabled)
* filter plugin for rewriting facet item (by configuring a callback function in the facet filter interface, regexp enabled, e.g. to change item values before display)
* filter plugin for excluding configurable facet items (by value or markup, regexp enabled)
The module is tested and already used in production environments. Reviews are welcome, ideally in my full project access application at http://drupal.org/node/1388266 - some feedback would be great! :)
(Just seen, that Yuri Gerasimov has also just freshly created facet api extra module, but with much less functionality)
Comment #14
cpliakas commentedPosted a review at http://drupal.org/node/1388266#comment-5412862. Couple of minor things to resolve, then there is no reason not to move this along. I'll be pushy about it in the queue so it doesn't get ignored :-P.