Set the sort mode
Funnelback offers a variety of different sorting options for ordering results. This can be done by setting a query processor option or CGI parameter.
The query processor option is:
-sort=<sort_type>
while the equivalent CGI parameter is sort
e.g. sort=date
.
To sort by relevance either remove the sort parameter or set the value of sort to an empty value.
Sort type | Sort results by |
---|---|
(default) |
Relevance / score |
date |
Document dates (newest first) |
adate |
Document dates (oldest first) |
title |
Document title (0,9 - A-Z) |
dtitle |
Descending document title (Z-A, 9-0) |
metaX |
Metadata class X (0..9, A-Z), then score |
dmetaX |
Descending metadata class X (Z-A, 9-0), then score |
prox |
Geospatial proximity (nearest first) |
dprox |
Descending geospatial proximity (furthest first) |
size |
File size (largest first) |
dsize |
Descending file size (smallest first) |
url |
URL (0-9, A-Z) |
durl |
Descending URL (Z-A, 9-0) |
coll |
Collection name (0-9, A-Z), then score |
dcoll |
Descending collection name (Z-A, 9-0), then score |
shuffle |
Random (see note below) |
collapse_count |
Number of collapsed documents, largest collapsed set first |
acollapse_count |
Number of collapsed documents, smallest collapsed set first |
score_ignoring_tiers |
Descending score value, ignoring any tiers. Only useful with sortall. |
Date sort (date, adate)
By default, future dates are ignored during sorting. Allowing future dates will require a modification to the collection’s indexer options.
Geospatial proximity sort (prox, dprox)
A user’s location will be inferred from their IP address unless overridden with an explicit origin=lat,long
CGI value. Results that do not have a geospatial component will be regarded as being an 'unknown' distance away, and will always appear after the results that do have a geospatial component.
Random sort (shuffle)
This feature is not available in the Squiz DXP. |
When -sort=shuffle
is set, an additional parameter also needs to be set to ensure that the random sort that is chosen is maintained across search result pages.
This is done by setting the -rseed
query processor option, which sets a random seed to use for the search. This parameter must be passed between search pages.
For truly randomised search, the rseed
value should be set dynamically for each search (so not as a query processor option) otherwise you’ll always get the same random sort for all queries.
The rseed
value isn’t set automatically - if you set sort=shuffle
you’ll need a hook script to set this value, and you’ll need to ensure your forms and all search UI links pass through the rseed value.
Modern UI - pre process hook script
The following code can be set up as a hook_pre_process.groovy
script and sets a random seed for a search if an rseed
value is not set.
def q = transaction.question
// Set random seed (only if in shuffle mode, and if not already set)
if (q.inputParameters.get("sort").stream().findFirst().orElse("") == "shuffle") {
// if rseed is missing or is &rseed=& in the URL
if (q.inputParameters.get("rseed").stream().findFirst().orElse("") == "") {
q.inputParameters.replaceValues("rseed", [Math.abs(new Random().nextInt() % 9999 + 1).toString()]);
}
}
Score ignoring tiers (score_ignoring_tiers)
Normal score sorting ensures that results that match the most query constraints are displayed above those that match fewer constraints. This applies even if the lower result might have a higher score because, for example, it has a very large number of matches for the terms it does match, and because those matches are in a field with a high weighting.
-sort=score_ignoring_tiers
overrides this behavior to cause all results
regardless of their tier (how many constraints they match) to be sorted by score.
Please note that
-
-sortall=true
is required for results in tiers below the first to be sorted, hence is required for-sort=score_ignoring_tiers
to have any impact. -
Result set diversification is no longer applied when
-sort=score_ignoring_tiers
is used.
Sorting partial matches
The sort modes, by default will sort results within result tiers - so all fully matching results will be sorted, then all results matching 1 out of 2 words.
The result tiers can be ignored by setting two additional options:
-tierbars=false
- turn off result tierbars.
-sortall=true
- include partial matches when resorting results.
Case-sensitive sort
Sorting is normally case-insensitive.
This behaviour can be altered to perform case-sensitive sorting by setting the following option:
-sort_sensitive=true
- Use case-sensitive sorting when sorting results by title or metadata strings.
Sorting by multiple keys
Funnelback only allows a sorting based on a single attribute (such as title or metadata field value)
It is sometimes desirable to sort the search results by more than one key. For example you may wish to sort by type then alphabetically by title.
Because Funnelback only allows sorting on a single key the only way to achieve sorting by more than one key is to pre-generate a sort field within the metadata. This field needs to concatenate the values of the two keys that need to be sorted on with the primary sort field being concatenated to the secondary sort field.
This can be achieved in a number of different ways. Ideally the field should be generated and added to the source content downloaded by Funnelback. If indexing data from a database or CMS it’s usually quite straightforward to configure the source system to generate an additional metadata or database field that is a concatenation of the two fields.
If you don’t have control over the data source then it is possible to write a plugin that implements a filter that extracts the two fields from the source data and generates a third field.
If you wish to sort on more than one key then you’ll need to generate a sort field that concatenates the fields you wish to sort on together (in a way that will sort alphabetically) in your metadata and sort on that. If exporting from a DB it’s usually quite straightforward to generate an extra sort field in the DB view that you are indexing.
Once the sort field is generated ensure that this field is included in the metadata mapping (any text type metadata class is sufficient) and configure the search to sort on this new field.
A similar philosophy or generating a sort field can be applied if you wish to apply some special rules to you alphabetical search such as ensuring numbers within a string a sorted correctly, or the sort ignores a leading The.
Example: sort by type and title
Consider the following data
<table>
<tr><th>Type</th><th>Title</th></tr>
<tr><td>Book</td><td>Great Expectations</td></tr>
<tr><td>Book</td><td>Harry Potter and the Goblet of Fire</td></tr>
<tr><td>Book</td><td>The BFG</td></tr>
<tr><td>DVD</td><td>Harry Potter and the Goblet of Fire</td></tr>
<tr><td>DVD</td><td>Star Wars</td></tr>
</table>
To sort by type then title would require a third field, sortKey to be generated:
<table>
<tr><th>Type</th><th>Title</th><th>Sort_Key</th></tr>
<tr><td>Book</td><td>Great Expectations</td><td>BookGreat Expectations</td></tr>
<tr><td>Book</td><td>Harry Potter and the Goblet of Fire</td><td>BookHarry Potter and the Goblet of Fire</td></tr>
<tr><td>Book</td><td>The BFG</td><td>BookThe BFG</td></tr>
<tr><td>DVD</td><td>Harry Potter and the Goblet of Fire</td><td>DVDHarry Potter and the Goblet of Fire</td></tr>
<tr><td>DVD</td><td>Star Wars</td><td>DVDStar Wars</td></tr>
</table>
The following would then be added to the metadata mappings (e.g. as a field called sortKey
).
And sorting would then be achieved by adding -sort=metasortKey
or &sort=metasortKey
.
See also
Search result ranking
Search result ranking is used to determine the default sort order for Funnelback search results.
Grouping search results
The grouping search results plugin provides the ability to group your search results by data source, or a metadata field value.