Bachir Soussi Chiadmi
2e69e3fd4c
updated search_api, search_api_solr_override, imce
|
%!s(int64=5) %!d(string=hai) anos | |
|---|---|---|
| .. | ||
| includes | %!s(int64=5) %!d(string=hai) anos | |
| README.txt | %!s(int64=5) %!d(string=hai) anos | |
| search_api_views.api.php | %!s(int64=9) %!d(string=hai) anos | |
| search_api_views.info | %!s(int64=5) %!d(string=hai) anos | |
| search_api_views.install | %!s(int64=9) %!d(string=hai) anos | |
| search_api_views.module | %!s(int64=5) %!d(string=hai) anos | |
| search_api_views.views.inc | %!s(int64=5) %!d(string=hai) anos | |
README.txt
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.
----------------------------
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.