Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.There is a configuration for the default snippet count and fragsize used for the highlighter, but SearchApiSolrBackend::setHighlighting() doesn't use them. At the moment, it uses a hardcoded value of '1' for the snippets, and '0' for the fragsize.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 2881587.patch | 4.25 KB | mkalkbrenner |
Comments
Comment #2
les limPatch attached.
Comment #3
mkalkbrennerFrom a Search API perspective, snippets and fragsize are configurable for the excerpt, not the highlighting.
We try to keep the Solr backend compatible to the DB backend.
Which kind of error are you facing?
Comment #4
les limOh, I misunderstood the difference between the Highlight retrieved data checkbox and the Return an excerpt for all results checkbox in the Solr server Drupal interface. Now that look at it more closely I didn't really want the highlighting, I just wanted the excerpting.
Having highlighting turned on appeared to help a problem I was having with the excerpts and stemming, but I ended up resolving that in schema.xml.
There is still a bug here, but I'll open a new issue.
Comment #5
les limActually, no, it's this same issue.
When both highlighting and excerpting are enabled, the highlight preparation clobbers the excerpt field (f.spell) preparation, so the
f.spell.hl.*parameters are never set. I still get excerpts, but they are prepared withhl.snippets=1&hl.fragsize=0, as used for highlighting purposes. That ends up showing the whole document.The problem is
$hl->setFields('*');, which unsets the previously prepared excerpt field. The new patch uses theaddField()method instead against individual text fields.Comment #6
mkalkbrennerThat seems like a good approach to work around the missing support for wildcards.
But I think we have to consider more field prefixes and special fields, for example
I think we should introduce a function for this. Maby getFulltextFields is part of the solution.
Additional fields should be configurable.
And we need to deal with third party indexes which we'll break if we remove '*'. See #2881369: Make the backend more robust concerning unexpected schemas.
But again, I really like the idea to get rid of this @todo in the code :-)
BTW what did you solve my modifications to the schema.xml?
Comment #7
les limTo clarify, you want something like a `protected function getSolrFulltextFields()` that gets the Solr names of fulltext properties for an index, but uses `getFulltextFields()` instead of looking for a dynamic field prefix?
The schema.xml change was to add `SnowballPorterFilterFactory` to the textSpell field type. WIthout it, I was getting stemmed hits in my search results, but I'd only get excerpts for literal matches.
Comment #8
mkalkbrennerYou're right. This is the important detail.
I extended the patch to also solve the already existing todos in this area :-)
That will break the spell / autocomplete feature. But there's already another issue for this topic: #2735881: Solr field spell is not suitable for generating excerpts
Comment #9
mkalkbrennerSince the existing tests still pass I'll merge this patch.
https://travis-ci.org/mkalkbrenner/search_api_solr/builds/237105725
Comment #11
mkalkbrennerI'm looking forward to get your feedback on the commit.