Search results category filter count
Hi again,
I've got a search results tag which has category filter drilldown links, which works fine, but the only hiccup I have is getting the total number of results that are tagged with that category _within_ the search results. It's only a one level drilldown i.e.
Content type
-----------------
Document (12 results)
Article (9 results)
and you would only ever have one 'active'. I'm currently thinking about outputting the non-limited results and Stashing them as a list which would then have a limit param, and then having to do some shonky PHP to count distinct occurrences of the category IDs, but can you think of a nicer way?
Thanks for any ideas,
Rob Hodges
Replies
Low 17 Apr 2012 13:32
There isn't an elegant way to achieve this natively, I'm afraid. I'd go for the option you describe...
electriclabs 17 Apr 2012 13:38
No problem,
Maybe it could be something to add to the feature request pile, i.e. a bit like an online stores filter/narrow options. I'm aware it would be a massif amount of work though!
Cheers,
Rob
electriclabs 19 Apr 2012 09:46
We're having some performance issues with Low Search (mainly because we're trying to crowbar it into a situation where it doesn't exactly fit).
Our current method is to give Low Search a limit of 2000, then Stash all the results, and use the Stash list output method (which has limit + offset) to build the page. We are also stashing all the category IDs and a custom date field, which we are passing to a custom plugin to count the unique ones and build a year and category filter.
We've found that any limit above 200 results on a search will run out of memory (not surprisingly), especially as the channel entries tag will call the playa/matrix hooks once for every 'record' causing the memory usage to spike.
So, we were thinking of another way to do this, so that we can go back to using limit and offset on the Low Search tag, as well as outputting the data we need for the filtering options.
Getting down to brass tacks, is there a way to output a pipe delimited list of all the entry IDs, ordered by search score, so that we can pass it to a plugin to do a nice memory less-intensive SQL lookup.
We tried var_dumping the $results array at line 849 of mod.low_search.php, just before you pass it to the channel entries tag, but we got some strange outputs, search queries with a lot of results would all have a score of 0, and the actual number of records in the array seemed to sometimes be double that of the actual number of results.
Is there a better place to try and grab this?
Sorry for the essay, and thanks in advance for any help you can provide.
I promise sometime soon I will stop bombarding you with tickets.
Thanks,
Rob
Low 19 Apr 2012 10:08
Yeah, grabbing the results from the mod.low_search.php file isn't going to work. I'll explain why:
Keyword searches simply query the index table and retrieve entry_ids, regardless of status, category or other filters. This gives us a set of relevant ids (ordered by relevance) that is set in the fixed_order parameter of the native channel:entries tag, thus limiting the retrieval of entries only to the relevant ones. Native filtering (by status, category, search:-params etc) is then applied to that set by mod.channel.php. This is why it's fast (limiting the channel:entries tag by entry_ids found) and robust (using the channel:entries tag ensures that all extra processing, extension hooks and whatnot keeps working for search results). It also means that the set of ids is almost always more than what will be displayed.
This is why generating a list of categories + entry count is hard to do. It doesn't exist natively (i.e., the channel:entries tag doesn't provide that info) and adding it to Low Search would mean *all* filtering options save limit will have to be accounted for in generating it.
Outputting all entries with a limit of 2000 will probably cause a memory usage spike for the regular channel:entries tag, too. But it's the only way I can see that it could work now, without changing the add-on.
I'll do a bit of brainstorming to see if I can come up with something else.
electriclabs 19 Apr 2012 10:13
Yeah, that's what I thought, our further filters currently work on a category="" or a search:custom_field="" so it's not going to work there :S
Thanks for taking the time to reply!
Rob