123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145 |
- Search API Views integration
- ----------------------------
- This module integrates the Search API with the popular Views module [1],
- allowing users to create views with filters, arguments, sorts and fields based
- on any search index.
- [1] http://drupal.org/project/views
- "More like this" feature
- ------------------------
- This module defines the "More like this" feature (feature key: "search_api_mlt")
- that search service classes can implement. With a server supporting this, you
- can use the „More like this“ contextual filter to display a list of items
- related to a given item (usually, nodes similar to the node currently viewed).
- For developers:
- A service class that wants to support this feature has to check for a
- "search_api_mlt" option in the search() method. When present, it will be an
- array containing two keys:
- - id: The entity ID of the item to which related items should be searched.
- - fields: An array of indexed fields to use for testing the similarity of items.
- When these are present, the normal keywords should be ignored and the related
- items be returned as results instead. Sorting, filtering and range restriction
- should all work normally.
- "Random sort" feature
- ---------------------
- This module defines the "Random sort" feature (feature key:
- "search_api_random_sort") that allows to randomly sort the results returned by a
- search. With a server supporting this, you can use the "Global: Random" sort to
- sort the view's results randomly. Every time the query is run a different
- sorting will be provided.
- For developers:
- A service class that wants to support this feature has to check for a
- "search_api_random" field in the search query's sorts and insert a random sort
- in that position. If the query is sorted in this way, then the
- "search_api_random_sort" query option can contain additional options for the
- random sort, as an associative array with any of the following keys:
- - seed: A numeric seed value to use for the random sort.
- "BETWEEN operator" feature
- --------------------------
- This module defines the "BETWEEN operator" feature (feature key:
- "search_api_between") that adds the "BETWEEN" and "NOT BETWEEN" filter
- operators to search queries. If your search server supports this feature, you
- can use the "Is between" and "Is not between" operators when adding Views
- filters for numeric, string or date types.
- For developers:
- A service class that wants to support this feature has to accept "BETWEEN" and
- "NOT BETWEEN" as additional $operator values in query conditions. The value in
- both cases is an array with the keys 0 and 1, with the value under key 0 being
- the lower and the value under key 1 being the upper bound for the range in which
- the field's value should ("BETWEEN") or should not ("NOT BETWEEN") be.
- "Facets block" display
- ----------------------
- Most features should be clear to users of Views. However, the module also
- provides a new display type, "Facets block", that might need some explanation.
- This display type is only available, if the „Search facets“ module is also
- enabled.
- The basic use of the block is to provide a list of links to the most popular
- filter terms (i.e., the ones with the most results) for a certain category. For
- example, you could provide a block listing the most popular authors, or taxonomy
- terms, linking to searches for those, to provide some kind of landing page.
- Please note that, due to limitations in Views, this display mode is shown for
- views of all base tables, even though it only works for views based on Search
- API indexes. For views of other base tables, this will just print an error
- message.
- The display will also always ignore the view's "Style" setting, selected fields
- and sorts, etc.
- To use the display, specify the base path of the search you want to link to
- (this enables you to also link to searches that aren't based on Views) and the
- facet field to use (any indexed field can be used here, there needn't be a facet
- defined for it). You'll then have the block available in the blocks
- administration and can enable and move it at leisure.
- Note, however, that the facet in question has to be enabled for the search page
- linked to for the filter to have an effect.
- Since the block will trigger a search on pages where it is set to appear, you
- can also enable additional „normal“ facet blocks for that search, via the
- „Facets“ tab for the index. They will automatically also point to the same
- search that you specified for the display.
- If you want to use only the normal facets and not display anything at all in
- the Views block, just activate the display's „Hide block“ option.
- Note: If you want to display the block not only on a few pages, you should in
- any case take care that it isn't displayed on the search page, since that might
- confuse users.
- Access features
- ---------------
- Search views created with this module contain two query settings (located in
- the "Advanced" fieldset) which let you control the access checks executed for
- search results displayed in the view.
- - Bypass access checks
- This option allows you to deactivate access filters that would otherwise be
- added to the search, if the index supports this. This is, for instance, the case
- for indexes on the "Node" item type, when the "Node access" data alteration is
- activated.
- Use this either to slightly speed up searches where additional checks are
- unnecessary (e.g., because you already filter on "Node: Published") and there is
- no other node access mechanism on your site) or to show certain data that users
- normally wouldn't have access to (e.g., a list of all matching node titles,
- published or not).
- - Additional access checks on result entities
- When this option is activated, all result entities will be passed to an
- additional access check, even if search-time access checks are available for
- this index. The advantage is that access rules are guaranteed to be enforced –
- stale data in the index, which might make other access checks incorrect, won't
- influence this access check. You can also use it for item types for which no
- other access mechanisms are available.
- However, note that results filtered out this way will mess up paging, result
- counts and possibly other things too (like facet counts), as the result row is
- only hidden from display after the search has been executed. Where possible,
- you should therefore only use this in combination with appropriate filter
- settings ensuring that only when the index isn't up-to-date items will be
- filtered out this way.
- This option is only available for indexes on entity types.
- Other features
- --------------
- - Change parse mode
- You can determine how search keys entered by the user will be parsed by going to
- "Advanced" > "Query settings" within your View's settings. "Direct" can be
- useful, e.g., when you want to give users the full power of Solr. In other
- cases, "Multiple terms" is usually what you want / what users expect.
- Caution: For letting users use fulltext searches, always use the "Search:
- Fulltext search" filter or contextual filter – using a normal filter on a
- fulltext field won't parse the search keys, which means multiple words will only
- be found when they appear as that exact phrase.
- FAQ: Why „*Indexed* Node“?
- --------------------------
- The group name used for the search result itself (in fields, filters, etc.) is
- prefixed with „Indexed“ in order to be distinguishable from fields on referenced
- nodes (or other entities). The data displayed normally still comes from the
- entity, not from the search index.
|