The current search box needs to be more configurable. From the original comments and posts up to #26, the basic functionality that will be added to this feature are the following:
Configurable messages, i.e. "Displaying 11-20 out of 200" or other combinations.Ability to prefix the active item with the field name a-la Search APIAbility to deselect the search keys similar to active facetsAdd a "field grouping" plugin
Remaining tasks are listed below:
Add a confirmation form when removing an item from the configurationAdd the ability to add wrapper elements and custom classes around items and individual elements- Plural / singular string tokens
i18n support for user inputted strings(See Facet API Translate)
The plan is to have a separate Current Search Blocks submodule with blocks as configuration that you can add information to via "current search item" plugins. A plugin might be a list of fields (like the current display), text with token replacements, or anything else people wish to add.
Original post
Here is a little patch that inserts some pager information into the current search block. If there are more results than will fit on one page, it will display something like: "Showing 1-20 of 1000 items." If there is only one page of results, it will show the current message: "Search found 10 items."
I thought that leaving the current display for a single page of results gave it a less machine-generated feeling :)
Comment | File | Size | Author |
---|---|---|---|
#44 | facetapi-593658-44.patch | 77.8 KB | cpliakas |
#42 | facetapi-current-search-wrapper-ui.jpg | 60.24 KB | cpliakas |
#33 | 593658.33-facetapi-current-search-block.patch | 1.53 KB | mrfelton |
#30 | airbnb-example.jpg | 214.88 KB | foopang |
#29 | facetapi-current-search.jpg | 77.46 KB | cpliakas |
Comments
Comment #1
jpmckinney CreditAttribution: jpmckinney commentedI prefer changing the signature of theme_apachesolr_currentsearch so that you can pass it the $response variable, after which you can write your own implementation of theme_apachesolr_currentsearch. I prefer not to change core's theme functions.
Comment #2
pwolanin CreditAttribution: pwolanin commentedComment #3
jpmckinney CreditAttribution: jpmckinney commentedMoving to facet API for consideration
Comment #4
cpliakas CreditAttribution: cpliakas commentedGreat idea, and I will take it a step further and say that the current search block needs to be more configurable in general. It would be great to be able to optionally build things like Amazon's current search block (see the attached screenshot) without touching the code. I think this is more than possible and a great initiative. Marking as a task, and I created the current-search-593658 feature branch since this will be a larger scale change.
In order to accomplish this task, we most likely need a few more methods in the adapter that the backend can optionally override. Then we can provide an interface for selecting which pieces should be included and where. The interface might be the trickiest part, but at least giving the ability to select which items are available would be a good start.
In addition, we would need to make the content area of the block a separate template so people have more control over the display. This will also give more flexibility for developers to add additional information via preprocess hooks if they are so inclined to do so.
Thanks,
Chris
Comment #5
cpliakas CreditAttribution: cpliakas commentedAs proposed by drunken monkey at #1216928: Address possible regressions, there should be an option to prefix facet values with field names.
Comment #6
Shadlington CreditAttribution: Shadlington commentedSubbing
Comment #7
drunken monkeyHas there been work on this yet? I don't see the branch you mention in #4.
Apart from that: +1, subscribing.
Comment #8
drunken monkeyAnother thing, of which I don't know whether it depends on the block being more configurable, is that the block currently isn't shown when there are no search keys and no active facet filters. However, as long as a search is still possible, I don't see a reason why the block shouldn't be shown, as it has still the useful information of the number of items. Also, the breadcrumb magic won't get activated in that case, which looks a bit inconsistent. (First, no breadcrumb item, and suddenly two additional ones.)
But, as said, maybe this is an entirely different issue? At least I think this will make sense in most cases where a search without keys or filters is possible. And in others, the adapter can just return
FALSE
insearchExecuted()
, I guess.Comment #9
cpliakas CreditAttribution: cpliakas commentedI actually pulled down the branch, because there are a couple of other items that are more important, such as getting the "fieldset" realm working. I forgot to post that I took the branch down. No real work has been don on this other than integrating with the token system in a local branch. I should probably throw that back up, I forget why I felt the need to explicitly remove it.
Comment #10
cpliakas CreditAttribution: cpliakas commentedWebchick says jump, I say "how high?". http://www.webchick.net/node/89
marking this as a release blocker because it is one of the more important and complex aspects of the Facet API module. Waiting until after 1.0 to add this in would be a big mistake, IMHO.
Comment #11
cpliakas CreditAttribution: cpliakas commentedAdding "Search API integration blocker", even though Search API is proceeding with the integration without this being complete. Bumping up priority.
Comment #12
tnightingale CreditAttribution: tnightingale commentedsubscribe
Comment #13
a_lawry CreditAttribution: a_lawry commentedHi All,
I've got a feature request from a client that seems like a pretty good idea to me so I'll add this to the list of feature requests here. Basically they want the current search block grouped by the facet from which the term came. So the block doesn't look like this:
- red
- blue
- yellow
- large
It looks like this:
colours:
- red
- blue
- yellow
Sizes:
- large
Real example attached. See the "You have searched for" block.
Comment #14
cpliakas CreditAttribution: cpliakas commentedExcellent request. Thanks for posting.
Comment #14.0
cpliakas CreditAttribution: cpliakas commentedSummarized posts up to #10.
Comment #15
cpliakas CreditAttribution: cpliakas commentedRemoving the "Search API integration blocker" tag, because this is no longer the case. Also re-posted the current-search branch where work will be happening for this issue.
Comment #15.0
cpliakas CreditAttribution: cpliakas commentedAdded original post back in.
Comment #15.1
cpliakas CreditAttribution: cpliakas commentedFixed issue the summary is up to, modified first item for clarity.
Comment #15.2
cpliakas CreditAttribution: cpliakas commentedAdded post from #16 into summary.
Comment #16
cpliakas CreditAttribution: cpliakas commentedSo looking into this further, I am planning on creating a "current_search" submodule for Facet API. This will allow us to separate the current search code from the facet stuff, and it will alos allow us to make use of the CTools Export UI so that we don't have to rely on Apache Solr Search Integration or Search API to recognize the additional menu items that will have to be added as a result of this. It will also reduce the code complexity of the block code in Facet API and will eliminate the need to create the various UI forms.
Comment #16.0
cpliakas CreditAttribution: cpliakas commentedFixed typos and reference to post this is summarized up to.
Comment #17
foopang CreditAttribution: foopang commentedsubscribe
Comment #18
cpliakas CreditAttribution: cpliakas commentedNo need to subscribe anymore :-) See Stop subscribing, start following.
Comment #19
foopang CreditAttribution: foopang commentedThanks @cpliakas. I was hoping to create a custom block showing the total number of indexed results on the homepage, but I have no idea how to do that. I also want to display some facet blocks on the homepage, something like the eRecruiter homepage http://drupaljobs.epiqo.com/
Can you help with that? Sorry if it is not relevant to the topic.
Thanks so much!
Comment #20
foopang CreditAttribution: foopang commentedWould it be possible to group the active facets like the airbnb.com search page?
http://www.airbnb.com/search?code=WpjESH
Comment #21
drunken monkeyI think that's in the responsibility of the specific search module, not of the Facet API. (If there is a way to do this generically I'd be happy to know, though.) If you are using the Search API, this is already possible (as demonstrated on the eRecruiter homepage) via the „Facets block“ Views display. If you are using the Apachesolr module (or any other), you should ask your question there. (Or wait if Chris contradicts me there.)
Comment #22
cpliakas CreditAttribution: cpliakas commented@drunken monkey, your answer is spot on. As an example, there is a patch at #1252648: Allow for enabling facet blocks on non-search pages to support something like this ins Apache Solr, however Search API already allows you to do this. IMHO a generic solution is not something that is a priority at this time.
Comment #23
foopang CreditAttribution: foopang commented@drunken monkey I am using the Search API, but I cannot figure out how to create a facets block using Views. I keep getting an error message:
Notice: Undefined index: theme in views_plugin->theme_functions() (line 498 of /Applications/MAMP/htdocs/recruiter/profiles/recruiter/modules/views/includes/plugins.inc).
Also, I want it to have to same look and feel as the search page I am using collapsible links to display the facets and group them into one block using Facetapi Block. Sorry for my English.
Comment #24
cpliakas CreditAttribution: cpliakas commented@beansboxchrispang, I would recommend posting a separate issue to the Search API project since this ins't directly related to making the current search block more flexible. It will be easier to have a discussion that way.
Thanks,
Chris
Comment #25
cpliakas CreditAttribution: cpliakas commentedAs per the thread posted at #1336010: Current search block: search "keyword" is not removable., it would be good to have the ability to be able to deselect the search keys in the current search block.
Comment #25.0
cpliakas CreditAttribution: cpliakas commentedRemoved "Summary" header since the issue queue already adds this.
Comment #26
acbramley CreditAttribution: acbramley commented+1 for functionality described in #25
Comment #27
rooby CreditAttribution: rooby commentedIn addition to being able to deselect the search keys in the current search block, it would be great if they were themeable.
Currently there a many excellent options for overriding the themeing of facets but the search keys don't run through a theme function.
Comment #28
milesw CreditAttribution: milesw commentedFor anyone needing a quick and dirty solution to modify the Current Search block, you can use hook_block_view_alter(). Here's what I'm using in my theme to make search terms deselectable.
This is for Apache Solr, for the default environment. Search API delta and link path will be different.
Comment #29
cpliakas CreditAttribution: cpliakas commentedAttached is the first iteration of the functionality.
Note that you will need to enable the Current Search module and configure your current search blocks. The interface is included below.
Comment #30
foopang CreditAttribution: foopang commentedAwesome! Thanks for the patch, @pliakas. Would it be possible to include the current search keyword to the Active items group? See for example: http://www.airbnb.com/search?code=wqoyfW
Comment #31
cpliakas CreditAttribution: cpliakas commentedThanks for the feedback. The goal is to provide "grouped" fields as well as html wrapper options similar to Semantic Views so that site builders can do as much configuration through the interface as possible. The available items are pluggable, so if the core functionality doesn't match exact use cases it can be extended pretty easily to add whatever custom items you want.
Thanks for the suggestion and screenshot,
Chris
Comment #32
cpliakas CreditAttribution: cpliakas commentedAs far as I see it, the following tasks are required to complete this functionality:
Comment #33
mrfelton CreditAttribution: mrfelton commentedI just needed a couple of tweaks to the current search block - Currently, the block has a title, and the item list also has a title (showing the number of results). It may just be my theme, but looks ridiculous to me! Also, none of the links in the Current search block have an active class, and with the block ids being seemingly randon, I couldn't see a sensible way to target these like to make them look like the rest of active facts.
Attached patch Sets the block title to the number of search results, rather than the title on the list item. It also adds a 'facetapi-active' class to the links, inline withe all the other active facet links in other fact blocks.
EDIT: Probably should have read this thread a little better before posting that, although I need it for my drush make file now which is the real reason I posted. The interface cpliakas is developing looks awesome!
Comment #34
cpliakas CreditAttribution: cpliakas commentedmrfelton,
Thanks for posting the patch. Even though we are going in another direction, it is definitely important important to post it both for the awesomeness that drush make has to offer and providing a good stopgap solution for others to use while the larger issue gets flushed out.
Thanks,
Chris
Comment #35
tnightingale CreditAttribution: tnightingale commentedTook this branch for a test-drive yesterday, wanted to say it's looking great so far! This is going to be a very powerful & much needed feature.
Here are some items I noticed that might want to be added to #32 or considered for future plugins/contrib:
Definitely on the right track, thanks for your hard work.
- Tom
Comment #36
cpliakas CreditAttribution: cpliakas commentedThanks a lot for testing, Tom.
I think all three of your ponts are very valid, so marking as "needs work" so that they are incorporated. Regarding the plural thing, I would be curious to see how that could be implemented because I do think that it will be common enough to warrant a solution. In terms of i18n I would like to hear your thoughts on what the best solution would be since I have only a general understanding of the issues at hand. I am trying to learn as much as I can so be more informed on issues relating to i18n.
Thanks again, much appreciated.
~Chris
Comment #37
tnightingale CreditAttribution: tnightingale commentedCool, I helped a little with adding i18n user strings to Quicktabs, but to be honest it was all pretty new to me too. I will review what was done and brush up on what is needed to make it work.
Regarding plural/singular tokens... I actually have no idea how an implementation might work. I will ask around, it seems to me that this is issue is generic enough, it must have cropped up somewhere before *crosses fingers*.
Comment #38
tnightingale CreditAttribution: tnightingale commentedRe: plural/singular tokens; now that I think about it this might actually be a rather complex problem or, at least beyond the scope of tokens...
However I think it definitely needs to be addressed as I see the "X item(s) found matching this search" scenario being a very common use case.
I'll follow up with anything I find or ideas I have.
Comment #39
drunken monkeyRegarding the tokens, a little mitigation of the problem might come by providing a few default strings as tokens. So, not only (e.g.)
facetapi:result_count
(just the number) but alsofacetapi:result_count_message
(i.e., „X item(s) found“ as a correctly plural-formatted string).(Using interface translation, admins could then even customize that phrase, and it would also be translatable.)
Comment #40
cpliakas CreditAttribution: cpliakas commentedThat's a good suggestion. Another approach I was thinking about is implementing a "results message" plugin where the replacement @count would effectively be the
facetapi:result_count
token. That way custom strings could still be used while making use of other tokens as well.Comment #41
foopang CreditAttribution: foopang commentedNot sure if it is just my own problem, but the custom text field doesn't seem to allow custom HTML tags input. For example, I want to wrap around the text with an H3 tag, when it is added, it simply gets removed in the output. I also tried some other HTML tags such as DIV and SPAN, they don't work with that either. Howerver, STRONG and EM tags work just fine. I wonder if that is something needs to be fixed? Thanks!
Comment #42
cpliakas CreditAttribution: cpliakas commentedHi beansboxchrispang.
Currently work is being done in the current-search branch, so some of the functionality you mentioned has already been committed. Check out the screenshot below for the Views-inspired interface.
I don't want to give full html rights to the text field for security reasons, although I think a relaxed filter works. Currently I am passing the value through the filter_xss() function which is probably why the elements you referenced are being stripped, however filter_xss_admin() might be a necessary alternative. Generally I would like to keep this as restrictive as possible adding the flexibility via the wrapper element and custom classes.
Comment #43
foopang CreditAttribution: foopang commentedReally excited about the current-search branch, will definitely try it out, thanks so much for putting efforts on it @cpliakas ;)
Comment #43.0
foopang CreditAttribution: foopang commentedUpdated issue summary.
Comment #43.1
cpliakas CreditAttribution: cpliakas commentedUpdated issue summary.
Comment #44
cpliakas CreditAttribution: cpliakas commentedAt this point I think the current-search branch is functional enough to get some real testing, so I am merging it into the main branch so people can start using it.
There are a couple of outstanding issues, mainly i18n and plural/singular string tokens, however I will post issues where these can be tracked. The attached patch is an overview of the differences added in the current-search branch.
Committed at http://drupalcode.org/project/facetapi.git/commit/bd08c3e.
Comment #45
a1russell CreditAttribution: a1russell commentedI have a feature request related to this...would it be possible to enable a "Reset search" button to this block that clears all of the facets and search terms? Should I open a new ticket for this? Thanks!
Comment #46
cpliakas CreditAttribution: cpliakas commentedYes, a new issue would be great!
Thanks for posting,
Chris
Comment #46.0
cpliakas CreditAttribution: cpliakas commentedUpdated issue summary.
Comment #47.0
(not verified) CreditAttribution: commentedUpdated issue summary.
Comment #49
screon CreditAttribution: screon commentedHas the feature request from #25 ever been implemented? I'm using the latest stable version but can't seem to find a setting to deselect active search terms (using views exposed filter, fulltext search). #28 provides a 'quick and dirty' solution, is there another way to do this?
Comment #50
jibize CreditAttribution: jibize commentedComment #51
rerooting CreditAttribution: rerooting commentedHeads up, this adds a configuration option to item_text