Persistent Data

Our Docker image is based on official Apache Solr image.

This volume will be mounted to persist the index and other resources from Apache Solr server. Following paths inside the exported volume are relevant for backups.

Start container with anonymous volume

To run the container with anonymous volume, simply type the following in command line:

docker run --name=typo3s-solr-server -d -p 8983:8983 typo3solr/ext-solr

This will create a Docker anonymous volume and store the data inside of it. To find out the path of used anonymous volume, simply type the following in command line:

docker inspect -f '{{ .Mounts }}' typo3s-solr-server

Start container with volume on hosts path

There are few steps required to be able to run the container with volume on hosts path.

Following commands will create the named volume "typo3s-solr-server-data" on hosts path and start the container with this volume.

mkdir .solrdata
docker volume create --name typo3s-solr-server-data --opt type=none --opt device=$PWD/.solrdata --opt o=bind
docker run --name=typo3s-solr-server --mount source=typo3s-solr-server-data,target=/var/solr -d -p 8983:8983 typo3solr/ext-solr

services:
  solr:
    container_name: typo3s-solr-server
    image: typo3solr/ext-solr:<EXT:Solr_Version>
    ports:
      - 8983:8983
    volumes:
      - typo3s-solr-server-data:/var/solr

volumes:
  typo3s-solr-server-data:
    driver: local
    driver_opts:
      type: none
      device: $PWD/.solrdata
      o: bind

Check if Solr is up and running

To check whether Solr is up and running head over to:

http://<ip>:8983/solr/#/core_en/query.

You should see the web interface of Solr to run queries:

Important: The image ships a default cores for all languages. The data of the cores is stored on an exported volume. When you want to update the container, you can just start a new container using the data volume of the old container. But at the same time this has the limitation, that you should only use this image with the default cores! If you want to create custom cores with a different configuration please read the section "Advanced Docker Usage"

Please note: The steps above show how to build the image from the Dockerfile. You can also download and use our compiled images from Docker Hub:

https://hub.docker.com/r/typo3solr/ext-solr/

Known Installers

All of these installers can be used to setup a plain, reboot save Solr server:

• Use the installer shipped with Solr itself bin/install_solr_service.sh:

Allows to install Solr on many distributions including init scripts.

• Use chef / ansible / whatever dev ops tool:

Allows you to setup a Solr server with your DevOps tool.

e.g. https://galaxy.ansible.com/geerlingguy/solr/ (ansible) or https://supermarket.chef.io/cookbooks/solr (chef)

Deployment of EXT:solr configuration into Apache Solr

Since EXT:solr 6.0.0 the configuration and all JAR files can be found in EXT:solr/Resources/Private/Solr folder. The goal of this approach is to make the deployment much easier.

All you need to do is, you need to copy the configSet directory into your prepared Solr installation and replace the solr.xml file. In the installer we do it like this:

cp -r ${EXTENSION_ROOTPATH}/Resources/Private/Solr/* ${SOLR_INSTALL_DIR}/server/solr

After this, you can decide which cores you want to boot and delete not relevant cores from ${SOLR_INSTALL_DIR}/server/solr/cores/ directory.

If you want to create other cores, you can create them by adding a <core_name>/core.properties file like provided by EXT:solr. This is the recommended workflow, so you can deploy the Solr server in an Infrastructure as Code (IaC) manner.

Alternatively Create a core with the rest api (not recommended):

See: "V2 API" on https://solr.apache.org/guide/solr/latest/configuration-guide/coreadmin-api.html#coreadmin-create

curl -X POST http://localhost:8983/api/cores -H 'Content-Type: application/json' -d '
  {
    "create": {
      "name": "<core_name>",
      "configSet": "ext_solr_<XX_Y_Z>",
      "schema": "german/schema.xml",
      "instanceDir": "cores/<core_name>"
      "dataDir": "<absolute-path-to-SOLR-HOME-of_server(standard: /var/solr/data/)>/data/<core_name>"
    }
  }
'

After installing the Solr server and deploying all schemata, the TYPO3 reports module helps you to verify if your setup fits to the requirements of EXT:solr

You now have a fully working, pre configured Solr running to start with

No you can continue with installing the extension Install EXT:solr.

Site Handling

In TYPO3 9.5 the new backend module called "Sites" was introduced. This Module can be used to setup and configure the Apache Solr connections.

Configure Solr Connections

Important

The Site-Handling GUI provides the common setup scenario for most users only. There is no possibility in the GUI to setup different things for each language in site configuration except Corename(core path).

Tip

All in sites config.yaml global defined thing for EXT:solr can be configured for each language differently by editing this file manually.

As first step the authority part of URI to Apache Solr machine must be configured.

The Corename(aka path to core) for each available language must be assigned respectively.

Connections

It lists all the for the site configured connections and their status.

Statistics

The Search Statistics module allows you to see Top Search Phrases with and without results. In addition it possible to see a complete listing with hits etc. ranked by Top search keywords.

Index Fields

The Index Fields module allows you to see, how many documents you have in which Solr core and which fields those documents have.

Stop Words

With the stopwords module you can define a list of words that should be excluded from the search.

Common usecases are:

• Very often occurring words like "the", "and" ... are excluded are filtered out because they are more or less "noize words".
• You can add words that you want to avoid from indexing.

Synonyms

With the synonyms module you can allow to find documents by words that do not occur in the document but have the same meaning:

• E.g. smartphone, cellphone, mobile, mobilephone

Note: The word that you want replace with a synonym needs to appear on both sides when you want to find it with the term itself later

Example

smartphone => smartphone, cellphone, mobile, mobilephone will match "smartphone, cellphone, mobile, mobilephone", when smartphone is missing on the right side, you will not find the document for smartphone anymore!

Option

The simplest and most often used facet type is the options facet. It renders the items that could be filtered as a simple list.

To setup an simple options facet you can use the following TypoScript snipped:

plugin.tx_solr.search {
    faceting = 1
    faceting {
        facets {
            contentType {
                label = Content Type
                field = type
            }
        }
    }
}

By using this configuration you create an options facet on the Solr field "type" with the name "contentType". This field represents the record type, that was indexed into solr. Shown in the frontend it will look like this:

Summary:

Grouping by option prefix:

When you have an option facet with very much options you might want to group the options by an prefix of an option. This can be used e.g. to group the options alphabetically.

The following example shows how options can be grouped by prefix (from EXT:solr/Configuration/TypoScript/Examples/Facets/OptionsPrefixGrouped/setup.typoscript):

<s:facet.options.group.prefix.labelPrefixes options="{facet.options}" length="1" sortBy="alpha">
    <f:for each="{prefixes}" as="prefix">
        <li>
            {prefix}
            <ul>
                <s:facet.options.group.prefix.labelFilter options="{facet.options}" prefix="{prefix}">
                    <f:for each="{filteredOptions}" as="option">
                        <li class="facet-option" data-facet-item-value="{option.value}">
                            + <a class="facet solr-ajaxified" href="{s:uri.facet.addFacetItem(facet: facet, facetItem: option)}">{option.label}</a>
                            <span class="facet-result-count">({option.documentCount})</span>
                        </li>
                    </f:for>
                </s:facet.options.group.prefix.labelFilter>
            </ul>
        </li>
    </f:for>
</s:facet.options.group.prefix.labelPrefixes>

Query Group

The query group facet renders an option list, compareable to the options facet, but the single options are not created from plain Solr field values. They are created from dynamic queries.

A typical usecase could be, when you want to offer the possiblity to filter on the creation date and want to offer options like "yesterday", "last year" or "more then five years".

With the following example you can configure a query facet:

plugin.tx_solr.search {
    faceting = 1
    faceting {
        facets {
             age {
                label = Age
                field = created
                type = queryGroup
                queryGroup {
                    week.query = [NOW/DAY-7DAYS TO *]
                    old.query = [* TO NOW/DAY-7DAYS]
                }
            }
        }
    }
}

The example above will generate an options facet with the output "week" (for items from the last week) and "old" (for items older then one week).

The output in the frontend will look like this:

An more complex example is shipped with this extension and can be enabled by including the template "Search - (Example) Fluid queryGroup facet on the field created", this example makes also use of renderingInstructions to render nice labels for the facet.

Summary:

Hierarchical

With the hierarchical facets you can render a tree view in the frontend. A common usecase is to render a category tree where a document belongs to.

With the following example you render a very simple rootline tree in TYPO3:

plugin.tx_solr.search {
    faceting = 1
    faceting {
        facets {
            pageHierarchy {
                field = rootline
                label = Rootline
                type = hierarchy
            }
         }
    }
}

The example above just shows a simple example tree that is just rendering the uid's of the rootline as a tree:

A more complex example, that is rendering the pagetree with titles is shipped in the extension. You can use it by including the example TypoScript "Search - (Example) Fluid hierarchy facet on the rootline field":

Summary:

Technical Solr background:

Technically the hierarchical facet for Solr is the same as a flat options facet. The support of hierarchies is implemented, by writing and reading the facet options by a convention:

[depth]-Level1Label/Level2Label/

When you follow this convention by writing date into a Solr field you can render it as hierarchical facet. As example you can check indexing configuration in EXT:solr (EXT:solr/Configuration/TypoScript/Solr/setup.typoscript)

plugin.tx_solr {
    index {
        fieldProcessingInstructions {
            rootline = pageUidToHierarchy
        }
    }
}

In this case the "fieldProcessingInstruction" "pageUidToHierarchy" is used to create the rootline for Solr in the conventional way.

Custom field processors can be registered with

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['solr']['fieldProcessor']['yourFieldProcessor'] = ACustomFieldProcessor::class;

Date Range

When you want to provide a range filter on a date field in EXT:solr, you can use the type "dateRange".

The default partial generates a markup with all needed values in data attributes. Together with the provided jQuery UI implementation you can create an out-of-the-box date range facet.

With the following TypoScript you create a date range facet:

plugin.tx_solr.search {
    faceting = 1
    faceting.facets {
        creationDateRange {
            label = Created Between
            field = created
            type = dateRange
        }
    }
}

In the extension we ship the TypoScript example "Search - (Example) dateRange facet with jQuery UI datepicker on created field" that shows how to configure a dateRange facet and load all required javascript files.

When you include this template a date range facet will be shown in the frontend that we look like this:

As described before for the date range facet markup and javascript code is required, looking at the example template "Search - (Example) dateRange facet with jQuery UI datepicker on created field" in "Configuration/TypoScript/Examples/DateRange" you see that for the jQueryUi implementation the following files are included:

page.includeJSFooterlibs {
    solr-jquery = EXT:solr/Resources/Public/JavaScript/JQuery/jquery.min.js
    solr-ui = EXT:solr/Resources/Public/JavaScript/JQuery/jquery-ui.min.js
    solr-daterange = EXT:solr/Resources/Public/JavaScript/facet_daterange.js
}

page.includeCSS {
    solr-ui = EXT:solr/Resources/Public/Css/JQueryUi/jquery-ui.custom.css
}

Numeric Range

Beside dates ranges are also usefull for numeric values. A typical usecase could be a price slider for a products page. With the user interface you should be able to filter the documents for a certain price range.

In the default partial, we also ship a partial with data attributes here to support any custom implementation. By default we will use the current implementation from EXT:solr based on jQueryUi.

The following example configures a numericRange facet for the field "pid":

plugin.tx_solr.search {
    faceting = 1
    faceting.facets {
        pidRangeRange {
            field = pid
            label = Pid Range
            type = numericRange
            numericRange {
                start = 0
                end = 100
                gap = 1
            }
        }
    }
}

The numeric range facet requires beside the template also a javascript library to render the slider. The example TypoScript template "Search - (Example) Fluid numericRange facet with jQuery UI slider on pid field" can be used to see the range slider with jQuery UI for the Solr field pid by example.

When you configure a facet on the pid field like this, the frontend will output the following facet:

Beside the implementation with jQueryUi you are free to implement a range slider with any other javascript framework.

Facet Grouping (Areas)

The first important part if the facet.area.group ViewHelper. By default all facets in the group main will be rendered. This value is the default value.

When you now want to render the facet at another place you can change the group with the following TypoScript configuration:

plugin.tx_solr.search {
    faceting = 1
    faceting.facets {
        contentType {
            field = type
            label = Content Type
            groupName = bottom
        }
    }
}

Now the facet belongs to another group and will not be rendered in the "main" area anymore.

Default Partials

Another important fact is that Facet->getPartialName() is used to render the detail partial. The default implementation of a facet will return the default partial, that is able to render this facet.

If you need another rendering for one facet you can overwrite the used partial within the configuration:

plugin.tx_solr.search {
    faceting = 1
    faceting.facets {
        contentType {
            field = type
            label = Content Type
            partialName = mySpecialFacet
        }
    }
}

Combining all of these concepts together with the flexibility of fluid you are able to render facets in a very flexible way.

SOLR_CONTENT

Since

2.0

Cleans a database field in a way so that it can be used to fill a Solr document's content field. It removes HTML markup, Javascript and invalid utf-8 chracters.

The helper supports stdWrap on its configuration root.

Example:

content = SOLR_CONTENT
content {
    field = bodytext
}

Parameters:

value

Type

String

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].value

Since

2.0

Defines the content to clean up. In this case the value would be hard-coded.

SOLR_MULTIVALUE

Since

2.0

Turns comma separated strings into an array to be used in a multi value field of an Solr document.

The helper supports stdWrap on its configuration root.

Example:

keywords = SOLR_MULTIVALUE
keywords {
    field = tags
    separator = ,
    removeEmptyValues = 1
}

Parameters:

value

Type

String

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].value

Since

2.0

Defines the content to clean up. In this case the value would be hard-coded.

separator

Type

String

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].separator

Since

2.0

Default

,

The separator by which to split the content.

removeEmptyValues

Type

Boolean

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].removeEmptyValues

Since

2.0

Options

0,1

Default

1

The helper will clean the resulting array from empty values by default. If, for some reason, you want to keep empty values just set this to 0.

removeDuplicateValues

Type

Boolean

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].removeDuplicateValues

Since

2.9

Options

0,1

Default

Cleans the result from duplicate values.

SOLR_RELATION

Since

2.0

Resolves relations between tables.

Example:

category_stringM = SOLR_RELATION
category_stringM {
    localField = category
    multiValue = 1
}

Parameters:

localField

Type

String

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].localField

Since

2.0

Required

yes

The current record's field name to use to resolve the relation to the foreign table.

foreignLabelField

Type

String

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].foreignLabelField

Since

2.0

Usually the label field to retrieve from the related records is determined automatically using TCA, using this option the desired field can be specified explicitly. To specify the label field for recursive relations, the field names can be separated by a dot, e.g. for a category hierarchy to get the name of the parent category one could use "parent.name" (since version:2.9).

foreignLabel

Type

String

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].foreignLabel

Since

12.1

Defines how to build the label for indexing, stdWrap is applied. Can be used to overrule foreignLabelField. Referencing to "field" e.g. inside dataWrap will resolve to resolved record.

Example:

authorsNames_stringM = SOLR_RELATION
authorsNames_stringM {
    localField = author
    foreignLabel.dataWrap = {field : first_name} {field : last_name}
    multiValue = 1
}

multiValue

Type

Boolean

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].multiValue

Since

2.0

Options

0,1

Default

Whether to return related records suitable for a multi value field. If this is disabled the related values will be concatenated using the following singleValueGlue.

singleValueGlue

Type

String

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].singleValueGlue

Since

2.0

Default

", "

When not using multiValue, the related records need to be concatenated using a glue string, by default this is ", " (comma followed by space). Using this option a custom glue can be specified. The custom value must be wrapped by pipe (|) characters to be able to have leading or trailing spaces.

relationTableSortingField

Type

String

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].relationTableSortingField

Since

2.2

Field in an mm relation table to sort by, usually "sorting".

enableRecursiveValueResolution

Type

Boolean

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].enableRecursiveValueResolution

Since

2.9

Options

0,1

Default

1

If the specified remote table's label field is a relation to another table, the value will be resolve by following the relation recursively.

removeEmptyValues

Type

Boolean

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].removeEmptyValues

Since

2.9

Options

0,1

Default

1

Removes empty values when resolving relations.

removeDuplicateValues

Type

Boolean

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].removeDuplicateValues

Since

2.9

Options

0,1

Default

Removes duplicate values

additionalWhereClause

Type

String

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].additionalWhereClause

Since

5.0

Where clause that could be used to limit the related items to a subset that matches this where clause

Example:

category_stringM = SOLR_RELATION
category_stringM {
    localField = tags
    multiValue = 1
    additionalWhereClause = pid=2
}

SOLR_CLASSIFICATION

Since

8.0

Allows to classify documents based on a configured pattern

Example:

topic_stringM = SOLR_CLASSIFICATION
topic_stringM {
    field = __solr_content
    classes {
        programming {
            matchPatterns = php, java, javascript, go
            class = programming
        }
        cms {
            matchPatterns = TYPO3, joomla
            class = cms
        }
        database {
            matchPatterns = mysql, MariaDB, postgreSQL
            class = database
        }
    }
}

The `matchPatterns` can be used to configure pattern that can occure in the content to add that class. In addition `unmatchPatterns` can be configured to define patterns that should not occure in the content.

Patterns are regular expressions. You configure everything that is possible with regular expressions.

Example:s

The pattern `\ssmart[a-z]*\s` will match everything, that starts with a space followed by smart ending with any lowercase letter and ending by space. This would match e.g. smartphone, smarthome and every other word that starts with `smart`.

Note:

• The configuration `patterns` is deprecated with 10.0.0 and will be removed in EXT:solr 11. Please use `matchPatterns` and `unmatchPatterns now.

field

Type

String

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].field

Since

8.0

Name of the database field, that should be used to as content to classify. The special field __solr_content can be used during indexing to classify the content of the page or file or any other record that fills the content field before.

classes

Type

Array

TS Path

plugin.tx_solr.index.queue.[indexConfig].fields.[fieldName].field

Since

8.0

Array of classification configurations. Each configuration needs to have the property "patterns", that is a list of patters that need to match and "class", that is the mapped class that will be indexed then.

Note:

The output field needs to be a multivalue field since an indexed item can have multiple classes.

query.allowEmptyQuery

Type

Boolean

TS Path

plugin.tx_solr.search.query.allowEmptyQuery

Default

Options

0,1

Since

1.4

If enabled, empty queries are allowed.

query.allowedSites

Type

String

TS Path

plugin.tx_solr.search.query.allowedSites

Since

2.2

Default

__solr_current_site

When indexing documents (pages, records, files, ...) into the Solr index, the Solr extension adds a "siteHash". The siteHash is used to allow indexing multiple sites into one index and still have each site only find its own documents. This is achieved by adding a filter on the siteHash.

Sometimes though, you want to search across multiple domains, then the siteHash is a blocker. Using the allowedSites setting you can set a comma-separated list of domains who's documents are allowed to be included in the current domain's search results. The default value is __solr_current_site which is a magic string/variable that is replaced with the current site's domain when querying the Solr server.

Since

3.0

Version 3.0 introduced a couple more magic keywords that get replaced:

• __current_site same as __solr_current_site
• __all Adds all domains as allowed sites
• * (asterisk character) Everything is allowed as siteHash (same as no siteHash check). This option should only be used when you need a search across multiple system and you know the impact of turning of the siteHash check.

query.getParameter

Type

String

TS Path

plugin.tx_solr.search.query.getParameter

Since

2.2

Default

tx_solr|q

The GET query parameter name used in URLs. Useful for cases f.e. when a website tracking tool does not support the default array GET parameters.

The option expects a string, you can also define an array in the form of arrayName|arrayKey.

Example:

plugin.tx_solr.search.query.getParameter = q

query.queryFields (query.fields)

Type

String

TS Path

plugin.tx_solr.search.query.queryFields

Since

1.0

Default

content^40.0, title^5.0, keywords^2.0, tagsH1^5.0, tagsH2H3^3.0, tagsH4H5H6^2.0, tagsInline^1.0, description^4.0, abstract^1.0, subtitle^1.0, navtitle^1.0, author^1.0

Note

query.fields has been renamed to query.queryFields in version 3.0

Defines what fields to search in the index. Fields are defined as a comma separated list. Each field can be given a boost by appending the boost value separated by the ^ character, that's Lucene query language. The boost value itself is a float value, pay attention to using a dot as the separator for the fractions. Use this option to add more fields to search.

The boost take influence on what score a document gets when searching and thus how documents are ranked and listed in the search results. A higher score will move documents up in the result listing. The boost is a multiplier for the original score value of a document for a search term.

By default if a search term is found in the content field the documents gets scored / ranked higher as if a term was found in the title or keywords field. Although the default should provide a good setting, you can play around with the boost values to find the best ranking for your content.

query.returnFields

Type

String

TS Path

plugin.tx_solr.search.query.returnFields

Since

3.0

Default

*, score

Limits the fields returned in the result documents, by default returns all field plus the virtual score field.

query.minimumMatch

Type

String

TS Path

plugin.tx_solr.search.query.minimumMatch

Since

1.2, 2.0

Default

(empty)

See

Apache Solr Wiki mm / Minimum Should Match

Sets the minimum match mm query parameter. By default the mm query parameter is set in solrconfig.xml as 2<-35%. This means that for queries with less than three words they all must match the searched fields of a document. For queries with three or more words at least 65% of them must match rounded up.

Please consult the link to the Solr wiki for a more detailed description of the mm syntax.

query.boostFunction

Type

String

TS Path

plugin.tx_solr.search.query.boostFunction

Since

1.2, 2.0

Default

(empty)

See

Apache Solr Wiki / TheDisMaxQueryParser BoostFunction

See

Apache Solr Wiki / Function Queries

Example

recip(ms(NOW,created),3.16e-11,1,1)

A boost function can be useful to influence the relevance calculation and boost some documents to appear more at the beginning of the result list. Technically the parameter will be mapped to the "bf" parameter in the Solr query.

Use cases for example could be:

"Give newer documents a higher priority":

This could be done with a recip function:

recip(ms(NOW,created),3.16e-11,1,1)

"Give documents with a certain field value a higher priority":

This could be done with:

termfreq(type,'tx_solr_file')

query.boostQuery

Type

Array

TS Path

plugin.tx_solr.search.query.boostQuery

Since

2.0

Default

(empty)

See

Apache Solr Wiki / TheDisMaxQueryParser BoostQuery

Sets the boost function bq query parameter.

Allows to further manipulate the score of a document by using Lucene syntax queries. A common use case for boost queries is to rank documents of a specific type higher than others.

Please consult the link to the Solr wiki for a more detailed description of boost functions.

Example (boosts tt_news documents by factor 10):

plugin.tx_solr.search.query.boostQuery.boostNews = type:tt_news^10

query.tieParameter

Type

String

TS Path

plugin.tx_solr.search.query.tieParameter

Since

8.0

See

Lucene Documentation / TheDisMaxQueryParser TieParameter <http://lucene.apache.org/solr/guide/7_0/the-dismax-query-parser.html#the-tie-tie-breaker-parameter>

This parameter ties the scores together. Setting is to "0" (default) uses the maximum score of all computed scores. A value of "1.0" adds all scores. The value is a number between "0.0" and "1.0".

query.filter

Type

Array

TS Path

plugin.tx_solr.search.query.filter

Since

1.0

See

Lucene Documentation / Query Parser Syntax

Allows to predefine filters to apply to a search query. You can add multiple filters through a name to Lucene filter mapping. The filters support stdWrap.

Example:

plugin.tx_solr.search.query.filter {
    pagesOnly = type:pages
    johnsPages = author:John
    badKeywords = {foo}
    badKeywords.wrap = -keywords:|
    badKeywords.data = GP:q
}

Note: When you want to filter for something with whitespaces you might need to quote the filter term.

plugin.tx_solr.search.query.filter {
    johnsDoesPages = author:"John Doe"
}

query.filter.__pageSections

Type

comma-separated list of page IDs

TS Path

plugin.tx_solr.search.query.filter.__pageSections

Since

3.0

This is a magic/reserved filter (thus the double underscore). It limits the query and the results to certain branches/sections of the page tree. Multiple starting points can be provided as a comma-separated list of page IDs.

Since version 11.5.6 it's possible to apply a stdWrap to it.

Example:

plugin.tx_solr.search.query.filter {
    __pageSections = TEXT
    __pageSections.data = leveluid:0
}

query.sortBy

Type

String

TS Path

plugin.tx_solr.search.query.sortBy

Since

1.0

Allows to set a custom sorting for the query. By default Solr will sort by relevance, using this setting you can sort by any sortable field.

Needs a Solr field name followed by asc for ascending order or desc for descending.

Example:

plugin.tx_solr.search.query.sortBy = title asc

query.phrase

Type

Boolean

TS Path

plugin.tx_solr.search.query.phrase

Since

8.0

Default

See

"pf", "ps", "qs" https://lucene.apache.org/solr/guide/6_6/the-dismax-query-parser.html#TheDisMaxQueryParser-Thepf_PhraseFields_Parameter

This parameter enables the phrase search feature from Apache Solr. Setting is to "0" (default) does not change behaviour from Apache Solr if user searches for two and more words. Enabling phrase search feature influences the document set and/or the scores of documents.

query.phrase.fields

Type

String

TS Path

plugin.tx_solr.search.query.phrase.fields

Since

8.0

Default

content^10.0, title^10.0, tagsH1^10.0, tagsH2H3^10.0, tagsH4H5H6^10.0, tagsInline^10.0, description^10.0, abstract^10.0, subtitle^10.0, navtitle^10.0

See

"pf" parameter https://lucene.apache.org/solr/guide/6_6/the-dismax-query-parser.html#TheDisMaxQueryParser-Thepf_PhraseFields_Parameter

This parameter defines what fields should be used to search in the given phrase. Matched documents will be boosted according to fields boost value. Fields are defined as a comma separated list and same way as queryFields.

Note: The value of this setting has NO influence on explicit phrase search.

query.phrase.slop

Type

Integer

TS Path

plugin.tx_solr.search.query.phrase.slop

Since

8.0

Default

See

"ps" parameter https://lucene.apache.org/solr/guide/6_6/the-dismax-query-parser.html#TheDisMaxQueryParser-Theps_PhraseSlop_Parameter

This parameter defines the "phrase slop" value, which represents the number of positions one word needs to be moved in relation to another word in order to match a phrase specified in a query.

Note: The value of this setting has NO influence on explicit phrase search.

query.phrase.querySlop

Type

Integer

TS Path

plugin.tx_solr.search.query.phrase.querySlop

Since

8.0

Default

See

"qs" parameter https://lucene.apache.org/solr/guide/6_6/the-dismax-query-parser.html#TheDisMaxQueryParser-Theqs_QueryPhraseSlop_Parameter

This parameter defines the "phrase slop" value, which represents the number of positions one word needs to be moved in relation to another word in order to match a phrase specified in a explicit phrase search query. Note: On explicit("double quoted" phrase) phrase search Apache Solr searches in "qf" queryFields

Note: The value of this setting has no influence on implicit phrase search.

On explicit phrase search the Solr searches in qf (plugin.tx_solr.search.query.queryFields) defined fields.

query.bigramPhrase

Type

Boolean

TS Path

plugin.tx_solr.search.query.bigramPhrase

Since

8.0

Default

See

"pf2", "ps2" https://lucene.apache.org/solr/guide/6_6/the-extended-dismax-query-parser.html#TheExtendedDisMaxQueryParser-Thepf2Parameter

This parameter enables the bigram phrase search feature from Apache Solr. Setting is to "0" (default) does not change behaviour from Apache Solr if user searches for three and more words. Enabling bigram phrase search feature influences the scores of documents with phrase occurrences.

query.bigramPhrase.fields

Type

String

TS Path

plugin.tx_solr.search.query.bigramPhrase.fields

Since

8.0

Default

content^10.0, title^10.0, tagsH1^10.0, tagsH2H3^10.0, tagsH4H5H6^10.0, tagsInline^10.0, description^10.0, abstract^10.0, subtitle^10.0, navtitle^10.0

See

"pf2" parameter https://lucene.apache.org/solr/guide/6_6/the-extended-dismax-query-parser.html#TheExtendedDisMaxQueryParser-Thepf2Parameter

This parameter defines what fields should be used to search in the given sentence(three+ words). Matched documents will be boosted according to fields boost value. Fields are defined as a comma separated list and same way as queryFields.

Note: The value of this setting has NO influence on explicit phrase search.

query.bigramPhrase.slop

Type

Integer

TS Path

plugin.tx_solr.search.query.bigramPhrase.slop

Since

8.0

Default

See

"ps2" parameter https://lucene.apache.org/solr/guide/6_6/the-extended-dismax-query-parser.html#TheExtendedDisMaxQueryParser-Theps2Parameter

This parameter defines the "bigram phrase slop" value, which represents the number of positions one word needs to be moved in relation to another word in order to match a phrase specified in a query.

Note: The value of this setting has NO influence on explicit phrase search.

query.trigramPhrase

Type

Boolean

TS Path

plugin.tx_solr.search.query.trigramPhrase

Since

8.0

Default

See

"pf3", "ps3" https://lucene.apache.org/solr/guide/6_6/the-extended-dismax-query-parser.html#TheExtendedDisMaxQueryParser-Thepf3Parameter

This parameter enables the phrase search feature from Apache Solr. Setting is to "0" (default) does not change behaviour from Apache Solr if user searches for two and more words. Enabling phrase search feature influences the scores of documents with phrase occurrences.

query.trigramPhrase.fields

Type

String

TS Path

plugin.tx_solr.search.query.trigramPhrase.fields

Since

8.0

Default

content^10.0, title^10.0, tagsH1^10.0, tagsH2H3^10.0, tagsH4H5H6^10.0, tagsInline^10.0, description^10.0, abstract^10.0, subtitle^10.0, navtitle^10.0

See

"pf3" parameter https://lucene.apache.org/solr/guide/6_6/the-extended-dismax-query-parser.html#TheExtendedDisMaxQueryParser-Thepf3Parameter

This parameter defines what fields should be used to search in the given phrase. Matched documents will be boosted according to fields boost value. Fields are defined as a comma separated list and same way as queryFields.

Note: The value of this setting has NO influence on explicit phrase search.

query.trigramPhrase.slop

Type

Integer

TS Path

plugin.tx_solr.search.query.trigramPhrase.slop

Since

8.0

Default

See

"ps3" parameter https://lucene.apache.org/solr/guide/6_6/the-extended-dismax-query-parser.html#TheExtendedDisMaxQueryParser-Theps3Parameter

This parameter defines the "trigram phrase slop" value, which represents the number of positions one word needs to be moved in relation to another word in order to match a phrase specified in a query.

Note: The value of this setting has NO influence on explicit phrase search.

results.resultsHighlighting

Type

Boolean

TS Path

plugin.tx_solr.search.results.resultsHighlighting

Since

1.0

Default

See

Apache Solr Wiki / FastVectorHighlighter

En-/disables search term highlighting on the results page.

Note: The FastVectorHighlighter is used by default (Since 4.0) if fragmentSize is set to at least 18 (this is required by the FastVectorHighlighter to work).

results.resultsHighlighting.highlightFields

Type

String

TS Path

plugin.tx_solr.search.results.resultsHighlighting.highlightFields

Since

1.0

Default

content

A comma-separated list of fields to highlight.

Note: The highlighting in Solr (based on FastVectorHighlighter requires a field datatype with termVectors=on, termPositions=on and termOffsets=on which is the case for the content field). If you add other fields here, make sure that you are using a datatype where this is configured.

results.resultsHighlighting.fragmentSize

Type

Integer

TS Path

plugin.tx_solr.search.results.resultsHighlighting.fragmentSize

Since

1.0

Default

200

The size, in characters, of fragments to consider for highlighting. "0" indicates that the whole field value should be used (no fragmenting).

results.resultsHighlighting.fragmentSeparator

Type

String

TS Path

plugin.tx_solr.search.results.resultsHighlighting.fragmentSeparator

Since

3.0

Default

[...]

When highlighting is activated Solr highlights the fields configured in highlightFields and can return multiple fragments of fragmentSize around the highlighted search word. These fragments are used as teasers in the results list. fragmentSeparator allows to configure the glue string between those fragments.

results.resultsHighlighting.wrap

Type

String

TS Path

plugin.tx_solr.search.results.resultsHighlighting.wrap

Since

1.0

Default

<span class="results-highlight">|</span>

The wrap for search terms to highlight.

results.siteHighlighting

Type

Boolean

TS Path

plugin.tx_solr.search.results.siteHighlighting

Since

2.0

Default

Activates TYPO3's highlighting of search words on the actual pages. The words a user searched for will be wrapped with a span and CSS class csc-sword Highlighting can be styled using the CSS class csc-sword, you need to add the style definition yourself for the complete site.

results.resultsPerPage

Type

Integer

TS Path

plugin.tx_solr.search.results.resultsPerPage

Since

1.0

Default

{$plugin.tx_solr.search.results.resultsPerPage}

Sets the number of shown results per page.

results.resultsPerPageSwitchOptions

Type

String

TS Path

plugin.tx_solr.search.results.resultsPerPageSwitchOptions

Since

1.0

Default

10, 25, 50

Defines the shown options of possible results per page.

results.maxPaginatorLinks

Type

Integer

TS Path

plugin.tx_solr.search.results.maxPaginatorLinks

Since

11.5

Default

Sets the number of shown page links in the paginator.

results.showDocumentScoreAnalysis

Type

Boolean

TS Path

plugin.tx_solr.search.results.showDocumentScoreAnalysis

Since

2.5-dkd

Default

Options

0,1

If enabled, the analysis and display of the score analysis for logged in backend users will be initialized.

spellchecking

Type

Boolean

TS Path

plugin.tx_solr.search.spellchecking

Since

1.0

Default

Set plugin.tx_solr.search.spellchecking = 1 to enable spellchecking / did you mean.

spellchecking.searchUsingSpellCheckerSuggestion

Type

Boolean

TS Path

plugin.tx_solr.search.spellchecking.searchUsingSpellCheckerSuggestion

Since

4.0

Default

This setting can be used to trigger a new search automatically when the previous search had no results but suggestions from the spellchecking. In this case the user can directly see the results of the best correction option.

lastSearches

Type

Boolean

TS Path

plugin.tx_solr.search.lastSearches

Since

1.3-dkd

Default

Set plugin.tx_solr.search.lastSearches = 1 to display a list of the last searches.

lastSearches.limit

Type

Integer

TS Path

plugin.tx_solr.search.lastSearches.limit

Since

1.3-dkd

Default

10

Defines the number of last searches, that should get minded.

lastSearches.mode

Type

String

TS Path

plugin.tx_solr.search.lastSearches.mode

Since

1.3-dkd

Default

disabled

Options

user, global, disabled

If mode is user, keywords will get stored into the session. If mode is global keywords will get stored into the database. If mode is disabled, then keywords are not stored in the database.

frequentSearches

Type

Boolean

TS Path

plugin.tx_solr.search.frequentSearches

Since

1.3-dkd, 2.8

Default

Set plugin.tx_solr.search.frequentSearches = 1 to display a list of the frequent / common searches.

frequentSearches.useLowercaseKeywords

Type

Boolean

TS Path

plugin.tx_solr.search.frequentSearches.useLowercaseKeywords

Since

2.9

Default

When enabled, keywords are written to the statistics table in lower case.

frequentSearches.minSize

Type

Integer

TS Path

plugin.tx_solr.search.frequentSearches.minSize

Since

1.3-dkd, 2.8

Default

14

The difference between frequentSearches.maxSize and frequentSearches.minSize is used for calculating the current step.

frequentSearches.maxSize

Type

Integer

TS Path

plugin.tx_solr.search.frequentSearches.maxSize

Since

1.3-dkd, 2.8

Default

32

The difference between frequentSearches.maxSize and frequentSearches.minSize is used for calculating the current step.

frequentSearches.limit

Type

Integer

TS Path

plugin.tx_solr.search.frequentSearches.limit

Since

1.3-dkd, 2.8

Default

20

Defines the maximum size of the list by frequentSearches.select.

frequentSearches.select

Type

cObject

TS Path

plugin.tx_solr.search.frequentSearches.select

Since

1.3-dkd, 2.8

Defines a database connection for retrieving statistics.

sorting

Type

Boolean

TS Path

plugin.tx_solr.search.sorting

Since

1.0

Default

Set plugin.tx_solr.search.sorting = 1 to allow sorting of results.

sorting.defaultOrder

Type

String

TS Path

plugin.tx_solr.search.sorting.defaultOrder

Since

1.0

Default

asc

Options

asc, desc

Sets the default sort order for all sort options.

sorting.options

This is a list of sorting options. Each option has a field and label to be used. By default the options title, type, author, and created are configured, plus the virtual relevancy field which is used for sorting by default.

Example:

plugin.tx_solr.search {
    sorting {
        options {
            relevance {
                field = relevance
                label = Relevance
            }

            title {
                field = sortTitle
                label = Title
            }
        }
    }
}

Note: As mentioned before relevance is a virtual field that is used to reset the sorting. Sorting by relevance means to have the order provided by the scoring from solr. That the reason why sorting descending on relevance is not possible.

sorting.options.[optionName].label

Type

String / stdWrap

TS Path

plugin.tx_solr.search.sorting.options.[optionName].label

Since

1.0

Defines the name of the option's label. Supports stdWrap.

sorting.options.[optionName].field

Type

String / stdWrap

TS Path

plugin.tx_solr.search.sorting.options.[optionName].field

Since

1.0

Defines the option's field. Supports stdWrap.

sorting.options.[optionName].defaultOrder

Type

String

TS Path

plugin.tx_solr.search.sorting.options.[optionName].defaultOrder

Since

2.2

Default

asc

Options

asc, desc

Sets the default sort order for a particular sort option.

faceting

Type

Boolean

TS Path

plugin.tx_solr.search.faceting

Since

1.0

Default

Set plugin.tx_solr.search.faceting = 1 to enable faceting.

faceting.minimumCount

Type

Integer

TS Path

plugin.tx_solr.search.faceting.minimumCount

Since

1.0

Default

1

See

Apache Solr Wiki / Faceting mincount Parameter

This indicates the minimum counts for facet fields should be included in the response.

faceting.sortBy

Type

String

TS Path

plugin.tx_solr.search.faceting.sortBy

Since

1.0

Default

count

Options

count, index, 1, 0, true, false, alpha (1.2, 2.0), lex (1.2, 2.0)

See

Apache Solr Wiki / Faceting sortParameter Parameter

Defines how facet options are sorted, by default they are sorted by count of results, highest on top. count, 1, true are aliases for each other.

Facet options can also be sorted alphabetically (lexicographic by indexed term) by setting the option to index. index, 0, false, alpha (from version 1.2 and 2.0), and lex (from version 1.2 and 2.0) are aliases for index.

faceting.limit

Type

Integer

TS Path

plugin.tx_solr.search.faceting.limit

Since

1.0

Default

10

Number of options to display per facet. If more options are returned by Solr, they are hidden and can be expanded by clicking a "show more" link. This feature uses a small javascript function to collapse/expand the additional options.

faceting.facetLimit

Type

Integer

TS Path

plugin.tx_solr.search.faceting.facetLimit

Since

6.0

Default

100

Number of options of a facet returned from solr.

faceting.keepAllFacetsOnSelection

Type

Boolean

TS Path

plugin.tx_solr.search.faceting.keepAllFacetsOnSelection

Since

2.2

Default

Options

0, 1

When enabled selecting an option from a facet will not reduce the number of options available in other facets.

faceting.countAllFacetsForSelection

Type

Boolean

TS Path

plugin.tx_solr.search.faceting.countAllFacetsForSelection

Since

8.0

Default

Options

0, 1

When `keepAllFacetsOnSelection` is active the count of a facet do not get reduced. You can use `countAllFacetsForSelection` to achieve that.

The following example shows how to keep all options of all facets by keeping the real document count, even when it has zero options:

plugin.tx_solr.search.faceting.keepAllFacetsOnSelection = 1
plugin.tx_solr.search.faceting.countAllFacetsForSelection = 1
plugin.tx_solr.search.faceting.minimumCount = 0

faceting.showAllLink.wrap

Type

String

TS Path

plugin.tx_solr.search.faceting.showAllLink.wrap

Since

1.0

Default

<li>|</li>

Defines the output of the "Show more" link, that is rendered if there are more facets given than set by faceting.limit.

faceting.showEmptyFacets

Type

Boolean

TS Path

plugin.tx_solr.search.faceting.showEmptyFacets

Since

1.3

Default

Options

0, 1

By setting this option to 1, you will allow rendering of empty facets. Usually, if a facet does not offer any options to filter a result-set of documents, the facet header will not be shown. Using this option allows the header still to be rendered when no filter options are provided.

faceting.urlParameterStyle

Type

Option/String (index or assoc)

TS Path

plugin.tx_solr.search.faceting.urlParameterStyle

Since

11.1

Default

index

Allows to change the URL style of facets.

Possible values:

index: Index style (default)

tx_solr[filter][0]=type:pages, the legacy style URL

assoc: Associative style

tx_solr[filter][type:pages]=1, the more modern associative style URL.

Note: The setting faceting.urlParameterSort will be enabled and can not be disabled.

Example:

plugin.tx_solr.search.faceting {
  urlParameterStyle = assoc
}

faceting.urlParameterSort

Type

Boolean

TS Path

plugin.tx_solr.search.faceting.urlParameterSort

Since

11.1

Default

Note

On faceting.urlParameterStyle = assoc, this setting can not be disabled.

Allows to enable sorting of url parameters, so the single state of facets is associated with same url, no matter in which order the facets were selected

faceting.facetLinkUrlParameters

Type

String

TS Path

plugin.tx_solr.search.faceting.facetLinkUrlParameters

Since

2.8

Allows to add URL GET parameters to the links build in facets.

faceting.facetLinkUrlParameters.useForFacetResetLinkUrl

Type

Boolean

TS Path

plugin.tx_solr.search.faceting.facetLinkUrlParameters.useForFacetResetLinkUrl

Since

2.8

Allows to prevent adding the URL parameters to the facets reset link by setting the option to 0.

faceting.facets

Type

Array

TS Path

plugin.tx_solr.search.faceting.facets

Since

1.0

Default

type

See

Apache Solr Wiki / Faceting Overview

Defines which fields you want to use for faceting. It's a list of facet configurations.

plugin.tx_solr.search.faceting.facets {
  type {
    field = type
    label = Content Type
  }

  category {
    field = category_stringM
    label = Category
  }
}

faceting.facets.[facetName] - single facet configuration

You can add new facets by simply adding a new facet configuration in TypoScript. [facetName] represents the facet's name and acts as a configuration "container" for a single facet. All configuration options for a facet are defined within that "container".

A facet will use the values of a configured index field to offer these values as filter options to your site's visitors. You need to make sure that the facet field's type allows to sort the field's value; like string, int, and other primitive types.

To configure a facet you only need to provide the label and field configuration options, all other configuration options are optional.

faceting.facets.[facetName].additionalExcludeTags

Type

String

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].additionalExcludeTags

Since

9.0

Required

no

The settings `keepAllOptionsOnSelection` and `keepAllFacetsOnSelection` are used internally to build exclude tags for facets in order to exclude the filters from the facet counts. This helps to keep the counts of a facet as expected by the user, in some use-cases (Read also: http://yonik.com/multi-select-faceting/).

With the setting `additionalExcludeTags` you can add tags of facets that should be excluded from the counts as well.

Note: This setting is only available for option facets by now.

faceting.facets.[facetName].addFieldAsTag

Type

Boolean

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].addFieldAsTag

Since

9.0

Required

no

Default

false

When you want to add fields as `additionalExcludeTags` for a facet a tag for this facet needs to exist. You can use this setting to force the creation of a tag for this facet in the Solr query.

faceting.facets.[facetName].field

Type

String

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].field

Since

1.0

Required

yes

Which field to use to create the facet.

faceting.facets.[facetName].label

Type

String

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].label

Since

1.0

Required

yes

Used as a headline or title to describe the options of a facet. Used in flex forms of plugin for filter labels. Can be translated with LLL: and consumed and translated in Partial/Facets/* with f:translate ViewHelper.

faceting.facets.[facetName].excludeValues

Type

String

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].excludeValues

Since

7.0

Required

no

Defines a comma separated list of options that are excluded (The value needs to match the value in solr)

Important: This setting only makes sense for option based facets (option, query, hierarchy)

faceting.facets.[facetName].facetLimit

Type

Integer

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].facetLimit

Since

8.0

Default

-1

Hard limit of options returned by solr.

Note: This is only available for options facets.

faceting.facets.[facetName].metrics

Type

Array

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].metrics

Since

8.0

Default

empty

Metrics can be use to collect and enhance facet options with statistical data of the faceted documents. They can be used to render useful information in the context of an facet option.

Example:

plugin.tx_solr.search.faceting.facets {
  category {
    field = field
    label = Category
    metrics {
        downloads = sum(downloads_intS)
    }
  }
}

The example above will make the metric "downloads" available for all category options. In this case it will be the sum of all downloads of this category item. In the frontend you can render this metric with "<facetoptions.>.metrics.downloads" and use it for example to show it instead of the normal option count.

faceting.facets.[facetName].partialName

Type

String

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].partialName

Since

7.0

Required

no

By convention a facet is rendered by it's default partial that is located in "Resources/Private/Partials/Facets/<Type>.html".

If you want to render a single facet with another, none conventional partial, your can configure it with "partialName = MyFacetPartial".

faceting.facets.[facetName].keepAllOptionsOnSelection

Type

Boolean

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].keepAllOptionsOnSelection

Since

1.2, 2.0

Default

Options

0, 1

Normally, when clicking any option link of a facet this would result in only that one option being displayed afterwards. By setting this option to one, you can prevent this. All options will still be displayed.

This is useful if you want to allow the user to select more than one option from a single facet.

faceting.facets.[facetName].operator

Type

String

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].operator

Since

1.2, 2.0

Default

AND

Options

OR, AND

When configuring a facet to allow selection of multiple options, you can use this option to decide whether multiple selected options should be combined using AND or OR.

faceting.facets.[facetName].sortBy

Type

String

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].sortBy

Since

1.2

Default

by count of results

Options

alpha (aliases: index, lex)

Sets how a single facet's options are sorted, by default they are sorted by count of results, highest on top. Facet options can also be sorted alphabetically by setting the option to alpha.

Note: Since 9.0.0 it is possible to sort a facet by a function. This can be done by defining a metric and use that metric in the sortBy configuration. As sorting name you then need to use by convention "metrics_<metricName>"

Example:

pid {
    label = Content Type
    field = pid
    metrics {
       newest = max(created)
    }
    sortBy = metrics_newest desc
}

faceting.facets.[facetName].manualSortOrder

Type

String

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].manualSortOrder

Since

2.2

By default facet options are sorted by the amount of results they will return when applied. This option allows to manually adjust the order of the facet's options. The sorting is defined as a comma-separated list of options to re-order. Options listed will be moved to the top in the order defined, all other options will remain in their original order.

Example - We have a category facet like this:

News Category
+ Politics (256)
+ Sports (212)
+ Economy (185)
+ Culture (179)
+ Health (132)
+ Automobile (99)
+ Travel (51)

Using faceting.facets.[facetName].manualSortOrder = Travel, Health will result in the following order of options:

News Category
+ Travel (51)
+ Health (132)
+ Politics (256)
+ Sports (212)
+ Economy (185)
+ Culture (179)
+ Automobile (99)

faceting.facets.[facetName].manualSortOrderDelimiter

Type

String

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].manualSortOrderDelimiter

Since

11.5

Default

,

Define an alternative delimiter instead of the default comma (,) for the manualSortOrder option. This is especially useful if the , is part of a facet option value.

faceting.facets.[facetName].minimumCount

Type

Integer

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].minimumCount

Since

8.0

Default

1

Set's the minimumCount for a single facet. This can be useful e.g. to set the minimumCount of a single facet to 0, to have the options available even when there is result available.

Note: This setting is only available for facets that are using the json faceting API of solr. By now this is only available for the options facets.

faceting.facets.[facetName].reverseOrder

Type

Boolean

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].reverseOrder

Since

3.0

Default

Options

0, 1

Reverses the order of facet options.

faceting.facets.[facetName].showEvenWhenEmpty

Type

Boolean

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].showEvenWhenEmpty

Since

2.0

Default

Options

0, 1

Allows you to display a facet even if it does not offer any options (is empty) and although you have set plugin.tx_solr.search.faceting.showEmptyFacets = 0.

faceting.facets.[facetName].includeInAvailableFacets

Type

Boolean

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].includeInAvailableFacets

Since

1.3

Default

1

Options

0, 1

By setting this option to 0, you can prevent rendering of a given facet within the list of available facets.

This is useful if you render the facet somewhere else on the page using the facet view helper and don't want the facet to be rendered twice.

faceting.facets.[facetName].includeInUsedFacets

Type

Boolean

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].includeInUsedFacets

Since

2.0

Default

1

Options

0, 1

By setting this option to 0, you can prevent rendering of a given facet within the list of used facets.

faceting.facets.[facetName].type

Type

String

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].type

Since

2.0

Defines the type of the facet. By default all facets will render their facet options as a list. PHP Classes can be registered to add new types. Using this setting will allow you to use such a type and then have the facet's options rendered and processed by the registered PHP class.

faceting.facets.[facetName].[type]

Type

Array

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].[type]

Since

2.0

When setting a special type for a facet you can set further options for this type using this array.

Example (numericRange facet displayed as a slider):

plugin.tx_solr.search.faceting.facets.size {
     field = size_intS
     label = Size

     type = numericRange
     numericRange {
         start = 0
         end = 100
         gap = 1
    }
}

faceting.facets.[facetName].requirements.[requirementName]

Type

Array

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].requirements.[requirementName]

Since

2.2

Allows to define requirements for a facet to be rendered. These requirements are dependencies on values of other facets being selected by the user. You can define multiple requirements for each facet. If multiple requirements are defined, all must be met before the facet is rendered.

Each requirement has a name so you can easily recognize what the requirement is about. The requirement is then defined by the name of another facet and a list of comma-separated values. At least one of the defined values must be selected by the user to meet the requirement.

There are two magic values for the requirement's values definition:

• __any: will mark the requirement as met if the user selects any of the required facet's options
• __none: marks the requirement as met if none of the required facet's options is selected. As soon as any of the required facet's options is selected the requirement will not be met and thus the facet will not be rendered

Example of a category facet showing only when the user selects the news type facet option:

plugin.tx_solr {
    search {
        faceting {
            facets {
                type {
                    label = Content Type
                    field = type
                }

                category {
                    label = Category
                    field = category_stringS
                    requirements {
                        typeIsNews {
                          # typeIsNews is the name of the requirement, c
                          # choose any so you can easily  recognize what it does
                          facet = type
                          # The name of the facet as defined above
                          values = news
                          # The value of the type facet option as
                          # it is stored in the Solr index
                        }
                    }
                }
            }
        }
    }
}

faceting.facets.[facetName].renderingInstruction

Type

cObject

TS Path

plugin.tx_solr.search.faceting.facets.[facetName].renderingInstruction

Since

1.0

Overwrites how single facet options are rendered using TypoScript cObjects.

Example: (taken from issue #5920)

plugin.tx_solr {
    search {
        faceting {
            facets {
                type {
                    renderingInstruction = CASE
                    renderingInstruction {
                        key.field = optionValue

                        pages = TEXT
                        pages.value = Pages
                        pages.lang.de = Seiten

                        tx_solr_file = TEXT
                        tx_solr_file.value = Files
                        tx_solr_file.lang.de = Dateien

                        tt_news = TEXT
                        tt_news.value = News
                        tt_news.lang.de = Nachrichten
                    }
                }

                language {
                    renderingInstruction = CASE
                    renderingInstruction {
                        key.field = optionValue

                        0 = TEXT
                        0.value = English
                        0.lang.de = Englisch

                        1 = TEXT
                        1.value = German
                        1.lang.de = Deutsch
                    }
                }
            }
        }
    }
}

EXT:solr provides the following renderingInstructions that you can use in your project:

FormatDate:

This rendering instruction can be used in combination with a date field or an integer field that hold a timestamp. You can use this rendering instruction to format the facet value on rendering. A common use-case for this is, when the datatype in Solr needs to be sortable (date or int) but you need to render the date as readable date option in the frontend:

plugin.tx_solr.search.faceting.facets {
    created {
        field = created
        label = Created
        sortBy = alpha
        reverseOrder = 1
        renderingInstruction = TEXT
        renderingInstruction {
           field = optionValue
           postUserFunc = ApacheSolrForTypo3\Solr\Domain\Search\ResultSet\Facets\RenderingInstructions\FormatDate->format
        }
    }
}

elevation

Type

Boolean

TS Path

plugin.tx_solr.search.elevation

Since

3.0

Default

Set plugin.tx_solr.search.elevation = 1 to enable content elevation in search results.

elevation.forceElevation

Type

Boolean

TS Path

plugin.tx_solr.search.elevation.forceElevation

Since

3.0

Default

1

Forces content elevation to be active.

elevation.markElevatedResults

Type

Boolean

TS Path

plugin.tx_solr.search.elevation.markElevatedResults

Since

3.0

Default

1

If enabled, elevated results are marked with CSS class "results-elevated".

variants.expand

Used to expand the document variants to the document.variants property.

Type

Boolean

TS Path

plugin.tx_solr.search.variants.expand

Since

6.0

Default

1

variants.variantField

Used to expand the document variants to the document.variants property.

Note:: The field must be a numeric field or a string field! Not a text field!

Type

String

TS Path

plugin.tx_solr.search.variants.variantField

Since

6.0

Default

variantId

variants.limit

Limit of expanded documents.

Though this setting limits the returned variants, you still can get the number of existing variants, it's set in "document.variantsNumFound" (since EXT:solr 10)

Type

Integer

TS Path

plugin.tx_solr.search.variants.limit

Since

6.0

Default

10

grouping.numberOfGroups

Type

Integer

TS Path

plugin.tx_solr.search.grouping.numberOfGroups

Default

5

Since

12.0

grouping.numberOfResultsPerGroup

Type

Integer

TS Path

plugin.tx_solr.search.grouping.numberOfResultsPerGroup

Default

5

Since

12.0

grouping.allowGetParameterSwitch

Type

Boolean

TS Path

plugin.tx_solr.search.grouping.allowGetParameterSwitch

Default

Since

12.0

If set, grouping can be disabled via "tx_solr[grouping]=off"

grouping.groups.[groupName].field

Type

String

TS Path

plugin.tx_solr.search.grouping.groups.[groupName].field

Default

empty

Since

12.0

Defines the Solr field where a group should be build on.

Note: Use either field or queries no mix. Groups with field are field groups, groups with queries are query groups.

grouping.groups.[groupName].queries

Type

Array

TS Path

plugin.tx_solr.search.grouping.groups.[groupName].queries

Default

empty

Since

12.0

Defines an array of queries to group the results in.

Note: Use either field or queries no mix. Groups with field are field groups, groups with queries are query groups.

grouping.groups.[groupName].sortBy

Type

String

TS Path

plugin.tx_solr.search.grouping.groups.[groupName].sortBy

Since

12.0

Allows to set a custom sorting for the group. Useful especially if you have already set plugin.tx_solr.search.query.sortBy. By default Solr will sort within a group by relevance, using this setting you can sort by any sortable field.

Needs a Solr field name followed by asc for ascending order or desc for descending.

pluginNamespaces

Type

String

Since

11.1

Default

tx_solr

A list of white listed plugin namespaces (Required by cacheHash/excludedParameters and plugin flex form).

includeGlobalQParameterInCacheHash

Type

Boolean

Since

11.1

Default

Include/Exclude global q parameter in/from cacheHash.

useConfigurationFromClosestTemplate

Type

Boolean

Since

6.1

Default

When this setting is active the closest page with a TypoScript template will be used to fetch the configuration. This improves the performance but limits also the possibilities. E.g. conditions can not be used that are related to a certain page.

useConfigurationTrackRecordsOutsideSiteroot

Type

Boolean

Since

6.1

Default

1

A common scenario is to have a site and a storage folder for records parallel to it on the same level (f.e.) If you don't want this behaviour - it should be set to false.

monitoringType

Type

Int

Since

11.2

Default

Defines how data updates should be monitored

By default (=0) recognized updates will be processed directly and the Solr index queue will be directly updated, also the Solr index where appropriate. As in huge instances the monitoring can slow down the TYPO3 backend, two more monitoring options are available:

• 1: Delayed: Record update events will be queue and processed later, the scheduler task "Event Queue Worker" is required for processing.
• 2: No monitoring: Monitoring is completely disabled, please note that you have to take care of Solr index updates yourself.

enableRouteEnhancer

Type

Boolean

Since

12.0

Default

To use the EXT:solr possibility to create speaking URLs for Solr facets, activate this option.

As this feature requires additional configuration and costly processing, it's disabled by default.

allowSelfSignedCertificates

Type

Boolean

Since

6.1

Default

Can be used to allow self signed certificates - when using the SSL protocol.

BeforePageDocumentIsProcessedForIndexingEvent

Registered Event Listeners can be used to add additional documents to Solr when a page gets indexed.

Registration of an event listener in your extension's Services.yaml:

MyVendor\MyPackage\EventListeners\MyEventListener:
  tags:
    - name: event.listener
      identifier: 'my-package/modify-documents'

The corresponding event listener class:

use ApacheSolrForTypo3\Solr\Event\Indexing\BeforePageDocumentIsProcessedForIndexingEvent;
use ApacheSolrForTypo3\Solr\System\Solr\Document\Document;

class MyEventListener {

    public function __invoke(BeforePageDocumentIsProcessedForIndexingEvent $event): void
    {
        $additionalDocument = new Document();
        $event->addDocuments([$additionalDocument]);
    }
}

For other records than pages, the PSR-14 Event \ApacheSolrForTypo3\Solr\Event\Indexing\BeforeDocumentIsProcessedForIndexingEvent can be used.

AfterPageDocumentIsCreatedForIndexingEvent

Registered event listeners can be used to replace/substitute a Solr document of a page.

Registration of an event listener in your extension's Services.yaml:

MyVendor\MyPackage\EventListeners\MyEventListener:
  tags:
    - name: event.listener
      identifier: 'my-package/modify-page'

The corresponding event listener class:

use ApacheSolrForTypo3\Solr\Event\Indexing\AfterPageDocumentIsCreatedForIndexingEvent;

class MyEventListener {

    public function __invoke(AfterPageDocumentIsCreatedForIndexingEvent $event): void
    {
        $event->setDocument($myCustomDocument);
    }
}

BeforeDocumentsAreIndexedEvent

Registered Event Listeners can be used to process Solr documents (pages and records) before they are added to index.

Registration of an event listener in your extension's Services.yaml:

MyVendor\MyPackage\EventListeners\MyEventListener:
  tags:
    - name: event.listener
      identifier: 'my-package/modify-documents'

The corresponding event listener class:

use ApacheSolrForTypo3\Solr\Event\Indexing\BeforeDocumentsAreIndexedEvent;

class MyEventListener {

    public function __invoke(BeforeDocumentsAreIndexedEvent $event): void
    {
        foreach ($event->getDocuments() as $document) {
           $document->addField('my_custom_field', 'my_custom_value');
        }
    }
}