Currently only those items that are returned by the searcher are passed to the "map callback", working from the implicit assumption that "active" items will always be among them. However, I can imagine at least one use case where this wouldn't be the case: users might decide to use facets to filter a search directly through the URL, passing some filter value(s) as the query in a link. This would be possible without the facet block actually showing (although in the Facet API the facet would at least have to be activated, I think), but currently this would lead to the value not being processed by the mapping callback.
This might also be the case, e.g., for range facets that let the user freely set the range (although they could compensate this in advance). And additionally there might be search systems in which selected facets aren't normally returned.

Not knowing the internals very well, I don't know how much effort this would take, but I'd say it would be a sensible addition.

CommentFileSizeAuthor
#8 facetapi-1223686-8.patch1.43 KBdrunken monkey
#6 facetapi-1223686-6.patch1.44 KBcpliakas

Comments

cpliakas’s picture

cpliakas commented

Thanks for the post. Trying to wrap my head around this one. Could you provide an example of what the query string might look like in this case, and where the active facets wouldn't be picked up? I think I see where you are going, but I am not entirely certain.

Thanks,
Chris

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

For example we might link tags to a search filtered by that tag via a facet. Then the URL would, e.g., look like this: /path-to-search?f[0]=field_tags%3A51, but you might not want to actually show the facet block, so no facets would be returned there. OK, that one isn't possible anyways … (Maybe another feature request, for facets with hard limit 0?)

But you might want to do the same with a range. Best example (except dates, where this would also work (at least with the Search API)) I can think of would be to filter by the first letter of, e.g., the title, or the author's username: /path-to-search?f[0]=title%3A[a TO azz].

OK, when you assume the query type plugin will normally return active facets, too, there are really only rather edgy edge cases. I just think that this isn't a necessary restriction, if we can just pass the active facet values with the available ones, merely to be on the safe side.

cpliakas’s picture

cpliakas commented
Category: feature » task

I am starting to pick up what you are saying. So just for a quick overview if the internals, the system works like this:

If the facet is enabled, it first checks to see if any active facets are enabled. When the backend calls initActiveFilters(), the facet information is returned by the backend and the values are mapped at this point. Effectively all of the back-end level processing is completed at this point.

Then the facetapi_build_realm() method is called, which turns that information into a render array. In the case of block facets, all of the processing has already been done so if the block is not displayed then the value will still be "mapped" while the facets won't be displayed. It is the widget's responsibility to convert the data returned by the server to the render array, so in the case of the range facets the available facets would never be displayed. I **think** this satisfies what you are saying, but again I may not fully understand the problem.

I do see your point about mapping assuming that the active facet is an available facets. I think it would be easy enough to merge the active facets and available facets so that the value is mapped no matter what. Changing to a task so we can add that functionality.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

I do see your point about mapping assuming that the active facet is an available facets. I think it would be easy enough to merge the active facets and available facets so that the value is mapped no matter what. Changing to a task so we can add that functionality.

Great, thanks! I hoped it wouldn't be too hard to do …

As for the rest, I'm also not sure whether we aren't talking at cross-purposes here – but then again, adding the active facets to the mapped values is all I wanted, so maybe it doesn't matter anyways. ;)

cpliakas’s picture

cpliakas commented

OK, cool! Let's see if the feature addresses what you want and we can reconnect once there is a patch.

cpliakas’s picture

cpliakas commented
StatusFileSize
new facetapi-1223686-6.patch1.44 KB

Here's a patch that adds the active items to the list of values being mapped.

cpliakas’s picture

cpliakas commented
Title: Add selected items to the argument for the "map callback" » Add the active items to the values that are mapped by the "map callback"
Status: Active » Needs review

Marking as "needs review", changing title slightly.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Needs review » Needs work
StatusFileSize
new facetapi-1223686-8.patch1.43 KB 
+++ b/plugins/facetapi/adapter.inc
@@ -1179,9 +1189,12 @@ class FacetapiFacetProcessor {
+      $values = array_unique(array_keys($build) + array_keys($this->getActiveItems()));

I guess this is just an oversight, correct would be:
array_unique(array_keys($build + $this->getActiveItems()))
Patch attached.

Otherwise this works great!

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Needs work » Needs review
cpliakas’s picture

cpliakas commented
Status: Needs review » Reviewed & tested by the community

Looks good to me. I think your method of combining the values is definitely cleaner, so I will commit the patch in #8.

cpliakas’s picture

cpliakas commented
Status: Reviewed & tested by the community » Fixed

Committed at 720e8d9.

Status: Fixed » Closed (fixed)

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