Configuring Search

Configuring Search could mean lots of different things:

  • System scoped search configuration
  • Reindexing to make sure the search indexes are current with the database
  • Tweaking the search widgets added to pages
  • Creating new Search Pages
  • Configuring the connectors that let Liferay DXP and the search engine communicate

In fact, Configuring Search means all those things. This is a high level overview of what search behavior is configurable out of the box, and importantly, where to find search configuration options.

System Scoped Search Configuration

System scoped search configurations are primarily found in System Settings.

  1. Go to Control PanelConfigurationSystem Settings.

  2. Click the Search category under the Platform section.

    Alternatively, search for Search.

Figure 1: There are numerous system scoped entries for search in System Settings.

Figure 1: There are numerous system scoped entries for search in System Settings.

These system scoped configurations are available in System Settings:

Default Keyword Query

The Default Keyword Query entry contains one setting:

disabledEntryClassNames: The DefaultKeywordQueryContributor code automatically adds description, userName, and title fields to the keyword search query. Specify the entry class names DefaultKeywordQueryContributor should ignore.

Configuration file:

Default Search Result Permission Filter

The Default Search Result Permission Filter entry allows configuration of post-filtering permission checking (database permission checking that occurs after the results are returned from the search index). Read here for more information on these settings:

  • permissionFilteredSearchResultAccurateCountThreshold

  • searchQueryResultWindowLimit

Configuration file:

Index Status Manager

The Index Status Manager entry has one setting:

indexReadOnly: Suspends all indexing operations and writes to the search engine. Searches return only the documents already indexed. This is useful for speeding up large data imports, but it should be disabled and a full re-index executed once the import is finished.

Configuration file:

Indexer Writer Helper

The Index Writer Helper entry contains only one valid entry. The second, indexReadOnly, is deprecated and unused, so setting it has no effect. Use indexReadOnly from the Index Status Manager instead.

indexCommitImmediately: When true (the default), each write request forces the search engine to refresh the index reader, potentially flushing transactions to disk. This may negatively impact search engine performance. The default behavior is to commit immediately for index writing on individual assets (e.g. add blog, update blog) but delay commits for bulk index writing operations (e.g. index all users, index all form entries) until all entries have been sent to the search engine. Setting this to false changes the behavior for individual index operations, and may cause applications like Asset Publisher to exhibit a delayed response when showing newly added content. See the Elasticsearch documentation for more information.

Configuration file:

Index Registry

Configure the buffering of index requests:

buffered: Disable or configure the buffering of indexing requests. To stop the buffering of index requests, choose Disabled.

maximumBufferSize: If buffering is enabled, set the Maximum Buffer Size so that any additional indexing requests are executed immediately.

minimumBufferAvailabilityPercentage: When the capacity of the buffer has only the specified percent of space left, the existing requests in the buffer are executed in one batch and removed from the buffer.

Configuration file:

Index Query Preprocessor

This entry has one repeatable property (use array syntax if you’re defining via OSGi configuration file):

fieldNamePatterns: Fields with names matching the patterns set here are treated as non-analyzed keyword fields. Instead of scored full text queries, matching is performed by non-scored wildcard queries. This is a resource intensive operation that degrades search engine performance as indexes grow larger. For substring matching, relying on the ngram tokenizer usually performs better.

Configuration file:


This entry contains only one property:

indexingBatchSizes: Set the number of documents indexed per batch for model types that support batch indexing—defaults to com.liferay.journal.model.JournalArticle=10000. For models with large documents, decreasing this value may improve stability when executing a full re-index.

Configuration file:

Engine Helper

This entry has one repeatable property (use array syntax if you’re defining via OSGi configuration file):

excludedEntryClassNames: Exclude an asset type from being searched in the catchall query constructed for the Search application. For example, fields of the Organization asset must be indexed to be searchable from the Users and Organizations application, but should not be searched in the Search application. Thus, Organizations are added to excludedEntryClassNames.

Configuration file:

Permission Checker

Configure pre-filtering permission checking (permission checking on the search index) behavior. See here for more information on these properties:

  • includeInheritedPermission

  • permissionTermsLimit

Configuration file:

Elasticsearch 6

Configure the connection between Liferay DXP and Elasticsearch 6. See here for more information on these properties:

  • clusterName
  • operationMode
  • indexNamePrefix
  • numberOfIndexReplicas
  • numberOfIndexShards
  • bootstrapMlocakAll
  • logExceptionsOnly
  • retryOnConflict
  • zenDiscoveryUnicastHostsPort
  • networkHost
  • networkBindHost
  • networkPublishHost
  • transportTcpPort
  • transportAddresses
  • clientTransportSniff
  • clientTransprtIgnoreClusterName
  • clientTransportPingTimeout
  • clientTransportNodesSamplerInterval
  • HttpEnabled
  • HttpCrsEnabled
  • HttpCorsAllowOrigin
  • HttpCorsConfigurations
  • additionalConfigurations
  • additionalIndexConfigurations
  • overrideTypeMappings
  • synchronizedSearch

Configuration file:

Search Web

This entry contains one property: classicSearchPortletInFrontPage: Revert the default search experience from using the new Search Widgets to the classic Search Portlet that was standard in past releases. See here for more information.

Configuration file:

Reindexing from Search Administration

In addition to the System Settings for Search, the action of recreating the search indexes is a system scoped action.

  1. Go to Control PanelConfigurationSearch.

  2. Re-index one of these:

    • All indexable assets
    • An individual indexable asset
    • All spell check indexes

Portal properties are system scoped configurations as well. The Lucene Search portal properties configure low level search behavior. Review the properties and their descriptions and determine if they apply to your search requirements.

Site Scoped Search Configuration

Search isn’t configurable at the Site Scope by the strict definition of Site Scoped Configuration. However, Search Pages influence site-specific search behavior. Commonly, Search Pages contain search widgets configured to search for all content within a particular Site.

In addition, the Header Search (the Search Bar embedded in every Site page by default), whether populated by the new Search Bar widget or the legacy Search portlet, is Site scoped. Only one instance of the Header Search application exists per Site, and configuring it in one page context configures it for the entire Site.

Because of the modularity of Search, there are some important configuration nuances to be aware of when using the new Search widgets:

  • If the Header Search uses the Search Bar widget, its configuration always requires a destination page to be set, where Users are redirected to complete their search activity, interacting with the other Search widgets (Results, Facets, Suggestions etc.). Search destination pages are ordinary pages holding the Search widgets. You can have as many pages with Search widgets across the Site as you want.

  • Unlike the legacy Search portlet, the new Search Bar widget is instanceable, so one page can contain multiple Search Bar widgets configured differently. All Search Bar instances must point to a Search Page to be effective.

  • Important: if the destination Search Page has a Search Bar widget instance besides the embedded Header Search, the configurations of the Header Search take precedence over the page’s widget instance.

    Conversely, searching from a Search Bar widget instance on other pages honors their configurations, even if they differ from the Header Search configuration.

See the documentation on configuring of a Search Bar for more information.

Widget Scoped Search Configuration

Several search widgets are available, and each one has its own configuration options:

Search Results
Configure how search results are displayed. Read here for more information.
Search Bar
Configure the behavior of how search keywords are processed. See here for more information.
Search Facets
Configure each facet’s behavior and URL parameters. See here for more information.
Search Options
This is a special case, where configuring this widget defines page scoped behavior. Add the Search Option widget to a page and define two booleans for the Search Page:
  • Allow Empty Searches: By default, failure to enter a keyword returns no results. Enabling this ensure that all results are returned when no keyword is entered in the Search Bar.

  • Basic Facet Selection: By default, facet counts are recalculated after each facet selection. Enable this to turn off facet recounting.

Search Suggestions
Suggest better queries and spell check queries. See here for more information.
Search Insights
Add this to the Search Page to inspect the full query string that’s constructed by the back-end search code when the User enters a keyword. Only useful for testing and development.
« Search Results BehaviorIntroduction to Forms »
Was this article helpful?
1 out of 1 found this helpful