In current search show active search term, just like a facet

Hi kotnik.

Thanks for the patch. Marking as "needs work" for two reasons. One is that not all implementing modules support removing the search keys, most notably the core Search module. Therefore we will need some way to handle this gracefully. The second reason is that you should not assume the facet data is stored in $_GET['f']. This can be modified, and modules such as Facet API Pretty Paths even put facet data in the path and not the query string. On a related note, the search keys themselves might be in the path or a query string, so we have to handle this use case as well.

Thanks,
Chris

This is just a reroll against latest code (so I can update Facet API in Kickstart v2), the points from #2 still need to be addressed.

Now without the syntax error.

Changing to "needs review" so the test bot can hack at it.

Let's try again. I was super-clumsy yesterday.

EDIT: I wonder why it doesn't apply, I'm rolling against latest git.

looks like you are also clumsy today ;-)

Changing to "needs review" to launch the test bot.

#7: 1616518-7-show-active-term.patch queued for re-testing.

Marking as needs work because we cannot assume that the facets are in $_GET['f']. We need to leverage the URL Processor to be able to generate the link if possible. I haven't loked deep enough to determine whether the API is flexible enough to support this.

Thanks for the contribution,
Chris

Keeping in "needs work" as we're still assuming that the facets are in $_GET['f'] but there was an issue with the previous patch because of the use of request_path() instead of current_path() that causes issues on multilingual websites.

Great. Thanks for the updated patch and contribution.

Nice patch, exactly what I was looking for.

I don't think there is a 100% reliable way to figure out where in the URL keywords exist. Using Search API + Views, for example, you can configure the keywords to be either a custom URL param (using exposed filters) or part of the path (using contextual filters). And Facet API cannot be aware of what Views is doing.

This patch makes the current search keywords configurable so they can be displayed as either plain text or a link. As a link, there is an option to specify the URL parameter used for keywords.

One case this does not handle is when keywords are buried in the path -- "/search/books/{keywords}/something/else". That seems like asking for trouble anyway.

#15 does'nt work for me.

Fixed patch, there was a problem in the settings form.

Now it shouw work, tested in 7.x-1.3.

BR

Sorry still doesn't work.

To reproduce the issue :

• Clean version of commerce kickstart with demo store.
• go to the search box and put into : go green

extra info : I have $conf['error_level'] = 2; in my settings.php

Yep I just saw that, but it's working go to current search block config (for standard: /admin/config/search/current_search/list/standard/edit) and under Active items check "display keywords as link to remove them from the facet". This error shouldn't appear but by default terms will not be removable, you need to set config by block.

BR

This one should be the good one. check if setting exist before checks.

This patch works for me. Note that it will also make this module: https://drupal.org/project/current_search_links obsolete.

Just sending another patch with the exact same code as #20, but which applies properly on facetapi root directory.

I should have been more careful: it does not seem to work when using facet api pretty paths...

New patch which makes it work with facetapi pretty paths. It would be nice if someone could test it with the standard url processor though...

I would be nice to have a "-" per keyword entered and not only one for the whole query.

Thanks for the contribution, and I like the idea.

I tested the patch with multiple backends and it works as advertised. Marking as "needs work" for two small reasons. The first is that in order to maintain backwards compatibility the setting should be opt-in and disabled by default. Second, for Apache Solr Search Integration I get a patch with a question mark at the end, e.g. "search/site?", when I disable the keywords. This doesn't break the functionality but it does make me a little concerned that it is an indicator it could break some edge cases.

If we can resolve these two things I think the patch will be RTBC,

Thanks again,
Chris

This is not working for me.
The problem starts here on line 44:
$item = $active_items[0];
In my $active_items array, the items are keyed like ['field_audience:2].

These changes make it work for me starting at line 43 in item_active.inc after applying patch from #24:

      if (count($active_items) > 0) {
        $item = array_shift($active_items);
        $item['adapter'] = $adapter;
        if (!isset($item['name'])) {
          $item['name'] = $item['field alias'];
        }

First use array_shift() to get an active item.
Second, make sure that $item['name'] is set. It seems to be the same as $item['field alias'].

I think I'm treating the symptoms rather than the cause, so I won't submit a patch, but it's working for me with these changes.

Also, this will get rid of a trailing empty query ?:

      // Remove empty params to prevent ? at end of path.
      if (empty($params['f'])) {
        unset($params['f']);
      }

Patch from #24 works great, but in our case only with awolfey's modification from #28. Thanks all!

Here's the new patch containing the modifications from #28.

No issues with #30 in my tests.

Applied cleanly for dev. Tested #31 working correctly.

Works well for me. Committed.