Search settings

OpenCms ships with a default configuration for the indexation of resources. The configuration is optimized w.r.t. the structure of OpenCms resources. So, for example, properties are indexed by default. But, some choices do not have an over-all good default. In particular concerning XML contents, the answers to the following questions are specific to the actual use case:

• Which schema elements of a structured content should not be indexed at all?
• Which schema elements of a structured content should be mapped to special index fields (of special type)?
• Should an XML content be findable as the content itself, or only the container-page the content is located on (or both notIf you do not want to find your content via the container page, there is a setting available in the formatter configuration.)?

The answers to these questions are mainly specific to your use-case. Thus you have to choose the settings by yourself. As guidelines you may regard:

• If you have a Boolean value or a date stored in your content, then you may not want to index them - at least not in the general content field.
• If you have detail pages for contents, it is usually intended to find the content as its own. Otherwise this may be not the case.
• If you want to have facets, you may map schema elements to special fields that you use for faceting.

By default

• The content of all schema elements of one language version will be stored in one language-specific text field called content_{locale}, e.g., content_en. (Here the dates or Boolean values should usually be omitted - learn later how)
• The content is indexed such, that it can be found stand-alone (and also the container-page it is located on is findable).

You can adjust search settings by adding a <searchsettings> node under xsd:annotation/xsd:appinfo in a content type's schema definition, and for each schema element where special indexing behavior has to be configured, a <searchsetting> sub-node. Examples follow, as we explain the settings in detail.

A trimmed-down version to ajust the search settings is via the field settings, introduced in OpenCms 11. With field settings you don't have the full flexibility, but most use cases are covered.

The settings can be grouped by

• setting how to find the content at all
• setting which information from the content are indexed in which way

How to find an XML content is configured via the attributes of the <searchsettings> node. If you do not add the node at all, it's similar to stating it with the default values.

By default, OpenCms creates for each resource the same index fields. These are of course not specific to the content's structure. You can look up these fields here. But, if you want to allow a sophisticated search queries for a specific content type, more index fields are needed. For each content element, you can specify the fields to create via a <searchsetting> node.

Since OpenCms 11, the field settings syntax provides for a simple notification for the most relevant search settings. The basic field settings syntax is explained here. In the <FieldSetting> sub-node <Search>, the following values are allowed:

The index fields content_{locale} are special fields they are intended to represent the language specific content of a resource. For XML contents, you can decide on schema element level if an element should be added to the content_{locale} fields or not. This is done by the optional attribute searchcontent, available for the tag <searchsetting>. The default value is true, indicating that the element's value is added to the content_{locale}. Setting the value to false will prevent the element from being added to the content_{locale} field.

Here's an example configuration, telling that a Date schema element should not be added to the content_{locale} field - while Title and Text should be added.

For each schema element, you can specify a Solr search field, that should hold the (possibly processed) value of that field. Here is a very simple example:

The result of the above configuration is: For each content of the type defined with the schema, an extra language specific index field atitle_{locale} is added, e.g., atitle_en. The fields have type text_{locale}, e.g., text_en.

If you specify only the attribute targetfield in the node <solrfield>, the target field will have type text_{locale}. But, you can also specify a different field type for the target field, using the attribute sourcefield.

The result of the example configuration is, that a locale specific fields date_{locale}_dt, e.g., date_en_dt, are added to the index, These have type date. Having search fields of different types is important for your search. For example, for a range search concerning dates, fields of type date are required.

Sometimes it is also useful, to have the same thing index more than once and with different types, e.g., as string and as text to allow for phrase search and for search of single words. To index schema elements multiple times, you can use the attribute copyfields.

In the example, the element Title will be indexed as field of type text_{locale} and as field of type string. The value is copied before processing involved in the index procedure takes place. Thus, in the example, the result are, for the English locale

• the field atitle_en, that contains the content of the element Title processed as text according to the english locale
• the field atitle_en_s, that contains a one-to-one copy of the value of the Title element.

In the attribute copyfields you can provide more than one field by separating the respective fields by comma.

There are more options to specify the indexing behavior for a content type. In particular, the attributes locale, default and boost can be given for the node <solrfield>. Moreover, since OpenCms 9.5.1, it is possible to add a Solr field not only to the content itself, but also to the containerpages the content is placed on.

OpenCms allows you to map more than single schema elements to a search field. The node <solrfield> takes a series of <mapping> sub nodes. In each such sub node, you can specify which value should be mapped to the Solr target field. Values can be the whole content or schema elements, properties and attributes. Moreover, you can specify your own mappings. All values (of all <mapping> nodes) are stored one after another in the (multi-valued) Solr target field.

Here is an example of such a mapping definition:

In the example, a dynamic mapping is specified. The class com.alkacon.opencms.documentation.search.CmsVersionNumberSearchFieldMapping  (that implements I_CmsSearchFieldMapping) specifies how to convert version numbers to long integers. It takes a parameter string that is specified in the body of the <mapping> node (or alternatively given as param attribute). In general, this parameter is an arbitrary string that has to fit the requirements of your class that implements the dynamic mapping. Concerning the example, the class takes the schema element that contains the version number as string.