Filtering Search Results


This feature works only with Elasticsearch.

With Custom Filters, you can contribute queries to the main search query, filtering search results to exert control over what’s returned in the Search Results widget. You can make the filter widgets visible or invisible and decide if they’re changeable or immutable.

Apply a custom filter to weed out certain search results.

There are many use cases satisfied by incorporating Custom Filters into your search page.

For now, consider these basic usages:

Use Case

Configuration (Value)

User Title Filter: End Users directly manipulate the filter key to refine results to the one they were looking for, using the Title

Filter Field (title_en_US)
Filter Value (podcast)
Filter Query Type (Match)
Occur Type (must_not)

Hard-Coded Filtering: An administrative User configures the Search Page with filters that are invisible and unchangeable for end Users

Add to the above configuration
Invisible (True–checked)
Immutable (True–checked)

Custom filters can do so many things, it’s impossible to list them all. What follows is a widget configuration tour. You can see some example configurations in Custom Filter Examples.

Adding a Custom Filter

To explore all the options you have with the Custom Filter widget, you need one on the page:

  1. Open the Add menu (Add) for the page and expand the Widgets section.

  2. From the Search section, drag a Custom Filter onto the page.

A custom filter has no impact until it's configured.

Custom Filter Configuration

To begin filtering search results, open the widget’s Options Menu (Options) and click Configuration.

Filter Field (text): Most often, filters operate on a specific field. Set the name of the indexed field to be filtered (for example, title). You won’t need this if the Filter Query Type is set to a type that doesn’t require a field, such as Regexp.

The Query String and Script queries do not require a Filter Field to be set. All other queries require at least one field.

To find the fields present in the Liferay DXP index, use the Field Mappings UI in the Control Panel.

Filter Value (text): For most filters, you must enter a text value here that specifies the text to apply the filter on in the specified field (for example, set a Match query to the text street on the title_en_US field). Some Filter Query Types require special notation, as in the case of the Regexp query.

Filter Query Type (select list): Select the query type to filter results by. Available types include Bool, Date Range, Exists, Fuzzy, Match, Match Phrase, Match Phrase Prefix, Multi Match, Prefix, Query String, Regexp, Script, Simple Query String, Term, Wildcard.

To learn more about these queries, visit the Elasticsearch documentation.

Occur (select list): Set the occurrence type for the query being contributed to the search. Options include Filter, must, must_not, and should.

To understand each type, see the Elasticsearch documentation.

Query Name (text): Set the name of the contributed query. This is unnecessary unless this filter acts as a parent query to another filter that contributes child clauses; in that case set this filter’s Query Name as the child filter’s Parent Query Name. This parent/child behavior is only available for filters of type Bool.

Parent Query Name (text): When contributing a child clause to a Bool query, set this to match the Query Name configured in the parent Custom Filter widget. Otherwise, leave it blank.

Boost (number): Boost the score of the results matching this query. Specify any whole or decimal number here that makes sense.

If you always want results matching this at the top, set the Boost value really high (e.g., 1000).

Custom Heading (text): Enter the heading to display for this filter. If not set, the Filter Field’s value is displayed.

Custom Parameter Name (text): Specify a URL parameter name for the filter. If not set, the Filter Field’s value is used.

Invisible (boolean): If checked, the widget is invisible to regular users. The Filter Value from the configuration is applied by default, but users can still filter for other values via URL Parameter. You can prevent URL parameter filtering with the Immutable setting (see below).

Immutable (boolean): Enable this to ensure that the Filter Value cannot be changed by regular users. The widget becomes invisible to them and filter values set via URL parameters are not accepted. The Filter Value set in the widget configuration is applied at all times (unless it’s disabled). Note that setting Immutable to true means that the Custom Parameter Name value is ignored.

Disabled (boolean): If checked, the query is ignored and doesn’t participate in searches. This gives you a quick way to stop the filter but keep the configuration so it can be re-enabled later.

Federated Search Key (text): Enter the key of an alternate Search this widget is participating on. If it’s set, be aware that the default index isn’t searched at all. If not set, this widget participates on the default search.

Values in this field typically match the name of an application-defined index.

Finding Fields

To find the fields you can filter by in the Custom Filter widget, Users with the proper permissions can navigate to Control PanelConfigurationSearch. From there, open the Field Mappings tab and browse the mappings for the liferay-[companyId] index. Scroll to the properties section of the mapping.

Browse the field mappings to find Liferay DXP's indexed fields.

Finding and Using Nested Fields

Availability: 7.2 FP10+, 7.3 FP1/SP1+

As described in Accessing Nested DDM Fields, DDM Fields became nested fields as of Liferay 7.2 SP3+/FP8+ (and on all Liferay 7.3 versions). On the latest Fix Pack and GA release of 7.2 and 7.3, the Elasticsearch Nested query is supported to account for these nested fields.

To find DDM fields in existing documents in the index,

GET liferay-20097/_search
  "query": {
    "nested": {
      "path": "ddmFieldArray",
      "query": {
        "wildcard":  { "ddmFieldArray.ddmFieldName": "ddm__*" }

Replace the Company Id—20097—in the index name parameter to match your instance’s value.

The document returned has a ddmFieldArray object with nested content:

 "ddmFieldArray" : [
      "ddmFieldName" : "ddm__keyword__40806__Textb5mx_en_US",
      "ddmValueFieldName" : "ddmFieldValueKeyword_en_US",
      "ddmFieldValueKeyword_en_US_String_sortable" : "some text has been entered",
      "ddmFieldValueKeyword_en_US" : "some text has been entered"
      "ddmFieldName" : "ddm__keyword__40806__Selectjdw0_en_US",
      "ddmValueFieldName" : "ddmFieldValueKeyword_en_US",
      "ddmFieldValueKeyword_en_US_String_sortable" : "option 3",
      "ddmFieldValueKeyword_en_US" : "value 3"
      "ddmFieldName" : "ddm__keyword__40806__Boolean15cg_en_US",
      "ddmValueFieldName" : "ddmFieldValueKeyword_en_US",
      "ddmFieldValueKeyword_en_US" : "true",
      "ddmFieldValueKeyword_en_US_String_sortable" : "true"

Using one of these fields in a Custom Filter configuration requires three custom filter widgets. A Nested query is added for wrapping the required child queries: one child query matches the field’s name, the other the value.

See Boosting Matches to Nested Fields for an example showing the use of a DDM Structure field with the Custom Filter widget.