Searching difficulties with hyphens (-) and periods (.) in assets

[timkelty]

I've had clients have difficulties finding assets like the one shown above.

The following yield no results, which seems a bit broken: 138-501, "138-501", 138-501.jpg, "138-501.jpg".
…and I certainly can't ask them to search for *138*501*jpg :)

I noticed that entries with hyphens still seem to be searchable (e.g. I can search for e-mail and get a result for an entry with e-mail in the title), but the behavior is different with assets.

[angrybrad]

Currently all search keywords that get inserted into the searchindex table in the database go through a normalization process, which includes things like removing punctuation from a given string because those are typically considered noise in a search.

So "138-801.jpg" will end being saved as " 138 501 jpg " in the database, which is why your first four examples won't match.

I think ultimately this will be solved in the Control Panel by #833 and/or #2060

[timkelty]

Thanks @angrybrad, sounds good.

Any idea why I'm seeing a different behavior for Entries (seem to be able to search for entries with hyphenated titles)?

[angrybrad]

@timkelty actually, I was a bit off earlier. Looks like we run search input keywords through the same normalization process. I bet if you set both subLeft and subRight to true here it will match: https://docs.craftcms.com/api/v3/craft-config-generalconfig.html#property-defaultsearchtermoptions

[narration-sd]

Interessant.

I was about to ask if such terms should be entered without the hyphens, etc., like certain maddening telephone etc. number forms. Glad to see your intent is rather 'the Craft Way' ;)

Does at first seem subLeft ought to be default true, as subRight is, though. Something important I'm missing? (no doubt...)

[timkelty]

@angrybrad indeed, I changed defaultSearchTermOptions and I now get results:

        'defaultSearchTermOptions' => [
            'subLeft' => true,
            'subRight' => true,
        ],

However, I'm not sure I understand why…(why would subLeft: true affect it when I'm searching from the beginning of a string)?

E.g. I can now search for 138-801.jpg and get an exact result, which is good. But I can also search for 38-801.jpg and still get the same result, which is certainly better than nothing, but not really what I'd want ideally.

I also don't understand why it seems to work without the defaultSearchTermOptions, it seemed to work with entries (searching for a title with a hyphen), but not with assets/filename.

[angrybrad]

@timkelty because all of the keywords in the searchindex table in the database are padded on both sides with whitespace. i.e. " 138 501 jpg "

Since 138 is the beginning of the string, you'd need the subleft to include the initial space.

[timkelty]

I see…a bit weird, but good enough until hopefully #833 and/or #2060 happens.

Thanks, @angrybrad!

[angrybrad]

I agree it's a bit awkward. Turns out search is pretty difficult.

[narration-sd]

@angrybrad again, is there a reason not to default subLeft?

Much agreed, search itself is ever a potential bandit -- this just seems it would ease a bit for use?

(busy with other bandits here...)