I say "don't work" because "I have no idea why it's doing what it's doing" is needlessly emotional and also too long š
Describe the bug
Our schema has "headline" for the title field. Currently the new search doesn't play well with this setup. Even if I set a silly number of 100 for the weight inside options.search for our headline field. I inspected the search results in browser tools and the list of hits returned from the server seems to have the highest matchScore for the result that I expect to be the first in the list of results. But the UI doesn't reflect this.
I tried enabling the legacy search using enableLegacySearch but it only improved the omnisearch behaviour. All the reference fields are still not finding our documents. The document filters above the document list are also yielding no results. I'm not even sure what version to rollback to. Our editors can't use the reference fields without jumping through a bunch of hoops now.
Update: after some digging I found that the "legacy search" ignores the fields of type text which is what our headlines are (our headlines are quite long and at the point when the system was created setting it to text was the best way to have a text area as an input). If I change the field type to text it shows up in search as it is now included in the legacy search request. So "legacy search" behaves differently to the actual old search as it excludes the text fields.
To Reproduce
Our schema is too complicated to show here. But the root of the problem is:
not having a title field (let's say having a "headline" field instead)
setting the type of the "headline" field to text
having the slug field use "headline" for the title field
making the headline field value different to the current slug (if they are the same then you can get an impression that the search actually works)
searching for the full headline
We can't go back to v2 now as we have migrated quite a while ago but we're also stuck with the search that barely works (yes, omnisearch is marginally better for some reason, but we use reference fields more often than we use omnisearch)
I say "don't work" because "I have no idea why it's doing what it's doing" is needlessly emotional and also too long š
Describe the bug
Our schema has "headline" for the title field. Currently the new search doesn't play well with this setup. Even if I set a silly number of 100 for the weight inside
options.searchfor our headline field. I inspected the search results in browser tools and the list of hits returned from the server seems to have the highestmatchScorefor the result that I expect to be the first in the list of results. But the UI doesn't reflect this.I tried enabling the legacy search using
enableLegacySearchbut it only improved the omnisearch behaviour. All the reference fields are still not finding our documents. The document filters above the document list are also yielding no results. I'm not even sure what version to rollback to. Our editors can't use the reference fields without jumping through a bunch of hoops now.Update: after some digging I found that the "legacy search" ignores the fields of type
textwhich is what our headlines are (our headlines are quite long and at the point when the system was created setting it totextwas the best way to have a text area as an input). If I change the field type to text it shows up in search as it is now included in the legacy search request. So "legacy search" behaves differently to the actual old search as it excludes thetextfields.To Reproduce
Our schema is too complicated to show here. But the root of the problem is:
We can't go back to v2 now as we have migrated quite a while ago but we're also stuck with the search that barely works (yes, omnisearch is marginally better for some reason, but we use reference fields more often than we use omnisearch)