Make the current search block more configurable

I 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.

Moving to facet API for consideration

Great 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

As proposed by drunken monkey at #1216928: Address possible regressions, there should be an option to prefix facet values with field names.

Subbing

Has there been work on this yet? I don't see the branch you mention in #4.

Apart from that: +1, subscribing.

Another 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 in searchExecuted(), I guess.

I 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.

Webchick 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.

Adding "Search API integration blocker", even though Search API is proceeding with the integration without this being complete. Bumping up priority.

subscribe

Hi 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.

Excellent request. Thanks for posting.

Summarized posts up to #10.

Removing 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.

Added original post back in.

Fixed issue the summary is up to, modified first item for clarity.

Added post from #16 into summary.

So 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.

Fixed typos and reference to post this is summarized up to.

subscribe

No need to subscribe anymore :-) See Stop subscribing, start following.

Thanks @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!

Would it be possible to group the active facets like the airbnb.com search page?
http://www.airbnb.com/search?code=WpjESH

Thanks @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.

I 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.)

@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.

@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.

@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

As 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.

Removed "Summary" header since the issue queue already adds this.

+1 for functionality described in #25

In 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.

For 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.

function theme_block_view_alter(&$data, $block) {
  if ($block->module == 'facetapi') {

    // Need to dereference FacetAPI block delta first.
    $map = facetapi_get_delta_map();
    if (isset($map[$block->delta]) && $map[$block->delta] == 'apachesolr@solr:current_search' && $data['content']) {

      // Loop through all active items.
      foreach ($data['content']['block']['#items'] as $i => $item) {

        // If one is not already link, then it *should* be a search term,
        // and not a facet. This is dirty.
        if (strpos($item, 'href=') <= 0) {
        
          // Build up a link array.
          $variables = array(
            'text' => 'Search: ' . check_plain($item),
            'path' => 'search/apachesolr_search',
            'options' => array(
              'attributes' => array(),
              'html' => TRUE,
              'query' => drupal_get_query_parameters(),
            ),
          );
          
          // Replace the existing item.
          $data['content']['block']['#items'][$i] = theme('facetapi_link_active', $variables);
        }
      }
    }
  }
}

This is for Apache Solr, for the default environment. Search API delta and link path will be different.

Attached 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.

Awesome! 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

Thanks 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

As far as I see it, the following tasks are required to complete this functionality:

• Add a "field grouping" plugin
• Add a confirmation form when removing an item from the configuration
• Add more semantic CSS classes around items using the machine names is the configurations
• Add the ability to add wrapper elements and custom classes around items and individual elements

I 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!

mrfelton,

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

Took 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:

• token module added as a dependancy
• plural/singular string tokens i.e: "X item(s) found matching this search" - not sure how this would be implemented but wouldn't be surprised if someone has come up with a solution elsewhere.
• i18n support for user inputted strings (though this could be worked around by creating search blocks per language).

Definitely on the right track, thanks for your hard work.
- Tom

Thanks 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

Cool, 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*.

Re: 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.

Regarding 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 also facetapi: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.)

That'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.

Not 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!

Hi 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.

Really excited about the current-search branch, will definitely try it out, thanks so much for putting efforts on it @cpliakas ;)

Updated issue summary.

Updated issue summary.

At 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.

I 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!

Yes, a new issue would be great!

Thanks for posting,
Chris

Updated issue summary.

Has 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?

Heads up, this adds a configuration option to item_text