I'm not sure if this is really edge-casey or if it warrants the patch I'm about to submit but here's my use case:
I have a couple of search-based views pages where a filter has been added in the view but it's not an exposed filter. It filters the results by content type. So, rather than '[all items]' being returned as the keys and placed in both the breadcrumb trail and the current search block, I'd like to be able to check in my custom module and see if a content type filter is being applied and if so change the keys so that it displays "Articles" or whatever content type it's filtering by. All that's required on the Search API side for this to be possible is a drupal_alter call.
Patch forthcoming...
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 1295144.drupal_alter_search_keys.3.patch | 1.97 KB | katbailey |
| #1 | 1295144.drupal_alter_search_keys.patch | 888 bytes | katbailey |
Comments
Comment #1
katbailey commentedHere's the patch. I'm not sure if this alter hook should be added to search_api.api.php - it wouldn't seem to quite warrant the creation of search_api_facetapi.api.php.
Comment #2
drunken monkeyFirst off, I'm not too happy about the „[all items]“ text, either, that's just there to work around a current shortcoming of the „Current search“ blocks. However, that's not really what you're concerned about – your patch would just provide a way for people to suppress that workaround, as a side effect.
However, the hook has definitely got to have the proper search_api_facetapi namespace and be documented in search_api_facetapi.api.php. It hasn't got anything to do with the main module, after all.
Other than that, I'd have nothing against adding this.
Comment #3
katbailey commentedOk, here's a new version. It adds the .api.php file, though without a real example implementation inside the hook as my own use case seemed too convoluted (20 lines) to give as an example implementation. So inside the hook there's just a comment about what you could do.
I made another change as well: rather than pass the $search array as the second parameter, which contains a query object as its first element and a results array as its second, I thought it better to just pass in the query object.
Comment #4
drunken monkeyCommitted, thanks!