[sraggio]

3 months, 2 weeks ago #59324

I’ve just activated Boosts to give more weight to the Title field, and found that there are a number of products, including some that have the search term in the title, that are not being displayed in search. For example, with Boosts deactivated, I see the same number of results both in the WP admin Products search and the public web page search. However, activating Boosts, the number displayed on the public page drops. I have not selected “copy to a text field” for any field in Boosts. Any idea what could cause certain products to be ignored or skipped with Boosts activated?

[wpsolr]

3 months, 2 weeks ago #59327

By default, the search indexes titles, content, custom fields, and taxonomies. To make a fair comparison, you should configure the same fields, boosts, and “Copy to Text Field” settings.

Also, keep in mind that the query parser may rewrite or expand the search query differently, which can affect both relevance and the number of results returned.

[sraggio]

3 months, 2 weeks ago #59335

I’ve assigned a boost factor to every field listed in 2.3 Boosts, and set “copy to text field” on all where it’s an option. However, I’m still seeing a disparity comparing public site searches to searches in the admin product listings. For one test search term, 107 vs 95; another 200 vs 179. When I track down the products missing from the public search, most contain the search term in the title, which I have assigned the highest boost factor to.

[wpsolr]

3 months, 2 weeks ago #59336

You can display the queries with our Query monitor add-on and play with them inside Kibana.

[sraggio]

3 months, 2 weeks ago #59339

After some AI troubleshooting, this is Claude’s conclusion:
Your title field is type text_lws — and that “_lws” is almost certainly a whitespace + lowercase analyzer with no punctuation handling. The catch-all your non-boosted search hits (_text_, type text_general, StandardTokenizer) strips punctuation; text_lws does not. That’s the entire bug. When boost is off you query the punctuation-stripped catch-all (everything matches); when boost is on WPSolr queries the individual text_lws fields by name, and every punctuation-glued occurrence drops out.

[sraggio]

3 months, 2 weeks ago #59342

Is this by design in WPSolr? Claude is recommending that I change schema.xml, to add the following filter to the text_lws type:
<charFilter class=”solr.PatternReplaceCharFilterFactory” pattern=”[,;:()\[\]{}]” replacement=” “/>
so that the search, with Boost activated, will properly return instances of the search term with punctuation attached.

[wpsolr]

3 months, 1 week ago #59343

The title field is currently defined as a simple field using only a lowercase filter. In the standard (non-boosted) search, its content is copied into the text field, which uses an English analyzer.

If you’d like the title field itself to benefit from the same analysis, you can edit your schema.xml and change its type from text_lws to text, then restart the core and reindex all your data:

<field name="title" type="text" indexed="true" stored="true"/>

This will make the title field use the English analyzer directly instead of only applying lowercase filtering.

[sraggio]

3 months, 1 week ago #59413

Thanks, that works. How does boost work with default sort? My catalog uses SKU for default sort order; when boost is implemented, will that be overridden to sort by boost-determined relevance?

[wpsolr]

3 months, 1 week ago #59423

This change will not affect your sorting, except for sorting on the title field itself if you use it. The title sort was correct with the text_lws field type, but it may no longer behave as expected once the field type is changed to text.