Glossary
Solr Search
A standalone search engine that indexes TYPO3 content and does considerably more than the built-in search.
What Solr does better
Apache Solr is a standalone search engine. The TYPO3 integration pushes content into its index, and search queries then run against that index rather than against the database.
The difference shows in what becomes possible: facets for narrowing down hits, autocomplete while typing, tolerance for typos, synonyms, weighting of individual fields, and search inside the contents of PDF files.
When it is worth it
Three signs speak for it. The collection is large enough that visitors cannot reach their goal without filters. There are documents whose contents should be findable. Or search is a central route through the site rather than an emergency exit.
If none of the three applies, Solr is effort without return. It is then more useful to look at whether the existing search is well configured and whether the site structure lets visitors search at all.
Think about running it
Solr is the part of a TYPO3 project most often underestimated, not in the implementation but in operation. The index has to be kept current, the service monitored, and it travels along in a server move.
So before the decision we clarify whether the hosting environment can carry it. A search service that stops indexing after six months is worse than none.
How content reaches the index
Solr does not crawl the website itself. TYPO3 maintains a queue of everything due for indexing, and a scheduler task works through it. When a record changes, it lands in that queue again.
That gives rise to the most common cause of odd search results: the index is not at the same state as the site. If the scheduler is not running, the search stays at the state of the last pass, without any error message appearing anywhere.
Access rights come along
A search that shows snippets of protected content in the results defeats the protection. So the integration carries the access restrictions into the index, and the query takes into account which groups the person asking belongs to.
That is one of the points where a home-made search regularly fails. It only becomes apparent when a document turns up that nobody should see.
Several languages
One core per language is the usual arrangement. The reason is not tidiness: text analysis is language-dependent. Stemming, stop words and the decomposition of compound words only work when Solr knows which language it is looking at.
Throw everything into one pot and you get a search that is usable in one language and noticeably worse in the others.
How it differs from the built-in search
TYPO3 ships with Indexed Search, which needs no additional service. For modest sites it is enough, and it has the advantage that nothing extra has to be run.
Its territory ends as soon as facets, error tolerance or search inside file contents are wanted. So the choice between the two is less a technical preference than a question of what role search plays on the site.
What running it actually means
Solr is a service of its own and needs memory, a Java runtime and attention at update time. It does not belong in the web directory and should not be reachable from outside.
At a TYPO3 version jump, the integration also has to fit. Before an update it is worth checking which Solr version the new release of the extension expects.