Search configuration¶
Product groups¶
product_groups
defines the groups that are used for the product search.
1 |
|
Product listing¶
siso_search.default.groups.product_list
configures results in product listing:
1 2 3 4 5 6 7 8 |
|
Search result tabs¶
Search results page displays results divided into tabs.
groups.search
parameters define the tabs and the content of each tab for search section of the website.
The following example defines three tabs: Product, Content and Files:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
Inside each tab there are additional definitions:
types
- the Content Types that are searched forpath
- path to the contentsection
- possible Sections of the content. In this example products and standard content are in Section 1 and files are in Section 3. If multiple sections are defined, products or content must be assigned to either of them (OR operator).visibility
- enables searching for content that is or isn't visible
Tab label are defined in the translation file EshopBundle/Resources/translations/messages.en.php
using the key value as ID, for example:
1 |
|
Preferred search group¶
search.preferred
defines which group is preferred for search as a default choice.
1 |
|
Main Location¶
main_location_only
defines whether search returns main nodes only.
1 |
|
Pagination limit¶
Depending on chosen design layout, you can configure a pagination limit and default limit:
siso_search.default.limits
- define the list of all available limit options per designsiso_search.default.limits.preferred
- defines elements per page and populates page size drop down
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Preferred limit¶
siso_search.default.limits.preferred
defines the default limit per design position for the search.
1 2 3 |
|
Sorting options¶
sort
parameters define the sorting options for each particular group.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
|
Default sorting per group¶
sort.preferred
defines default sorting per group.
1 2 3 4 5 |
|
score
is a Solr field which is a numeric value that can affect the relevance of the elements.
For more information on Solr score, see Solr Relevancy FAQ.
Boosting¶
Boosting influences relevancy calculation. With boosting factors you can control which Fields are more important / more relevant for the search terms than others. A higher value boosts a hit. This means that if the search engine finds a search term, a boosted Field has a better relevancy. The existence of search terms is crucial for the calculation of relevancy. Field boosting has no influence on the order of results if a search was queried without terms (e.g. in a product list in the catalog).
By default the search engine uses a factor of 1. A boosting of values below 1 (e.g. 0.5) reduces the relevance of this Field.
The implementation of the Field boosting API differs for eContent and Content items.
Content items¶
The configured Field name values are Field identifiers of their respective Content Types (e.g. Field ses_name
of type ses_product
).
Fields added by an indexer plugin cannot be boosted.
1 2 3 4 5 6 7 8 |
|
eContent¶
The Field name values are raw Solr field names. All indexed Fields can be taken into consideration for boosting,
but must also be adapted in the configuration whenever they change in the index.
You should specify the default search field text
here, as it would not be queried otherwise.
Boosts in eContent activate the qf
parameter which overrides the default field (df
parameter).
If you specify boosting Fields in eContent, the shop only searches in these Fields.
1 2 3 4 5 6 7 8 9 10 |
|
Quick order limit¶
auto_suggest_limit
and auto_suggest_fields
configure autosuggestion for quick order.
User input in quick order searches these defined Solr fields.
1 2 3 4 5 6 7 8 |
|
Mapping specifications¶
search_mapping_specification
sets predefined rules for product specification matrix index.
1 2 3 4 5 6 7 8 9 10 11 |
|
alias
- is useful to specify additional words for a given specification matrix parameter. The indexer only indexes the first element of the alias array.type
- specifies a data type for the given specification matrix element. For example, if float is set, the indexer does a string to float conversion of the value.separator
- if set, the indexer creates a Solr field with multiple elements using the specified separator to explode the string into an array.
For example, if field value is 220 x 110 x 150
, you can specify x
as separator
The indexer then creates a Solr field with multiple elements that will look like this: {220, 110, 150}
.
Category cache¶
Because category names are not indexed, they are stored in a Stash cache.
1 2 3 4 5 6 |
|
rootNodeId
- main product Location.maxProductCategoryDepth
- number of levels of subcategories set in this cache.productCategoryLimit
- maximum number of category names stored in this cache.add_parent_category_name
- if set totrue
it also indexes the parent category name.parent_category_name_separator
- string separator to concatenate parent category and current category.
Solr special characters¶
If you use eContent as catalog data provider, you can configure how Solr special characters are evaluated.
1 |
|
Possible values:
escape
: escapes every Solr special character from the user search query.remove
: removes every Solr special character from the user search query.~
: keeps all Solr special characters.
Solr special characters are: + - && || ! ( ) { } [ ] ^ " ~ * ? : \
Image filtering¶
EcontentImageIndexerPlugin
can use the imageConverter
.
To enable it, set use_filtered_images
to true
:
1 |
|
image_filter_resolution
specifies in how the images are modified by the imageConverter
:
1 |
|
eContent section filter¶
1 2 3 4 5 |
|
If section_filter
is enabled, the product/catalog search result list is restricted to elements
which are assigned to catalog codes, provided by catalog_filter_default_catalogcode
.
eContent configure cores per SiteAccess¶
When using eContent, you can configure Solr cores per SiteAccess:
1 2 |
|
The example above uses the back core. This can be useful if an import uses temporary tables in eContent.
Data is then indexed in the econtent_back
core.
Note
The service searching for bestsellers does use this setting and uses the live core by default.
To use the default core (usually siso_econtent
, which is the eContent live core), use the following configuration:
1 2 |
|
Use default core (usually siso_econtent = econtent live core)