A few issues have popped up regarding matching strings with various advanced functionality. I believe a solution should be found that would work for all these cases. My expectation is to find some way to allow users to assign database functions to the matching process, and perhaps some sort of ranking system for results.
#850896: Diacritics not ingoren in Finder Views + Autocomplete
#723978: Ignore punctuation in node titles
#994412: Autocomplete transform special characters to simple letters
Comments
Comment #1
danielb commentedComment #2
Jberges commentedA possible solution for accents/diacritics/especial characters (it works for me but it needs work to be a real patch). I discovered that results where found by finder_find() but later eliminated by finder_find_choices() .
in finder.module add a funtion to replace especial chars with the normal ones:
It's easy to add as many chars as needed.
After this, go to this code in finder.module
And replace strtolower calls with normalize
With this code, autocomplete textfield finds nodes with CCK fields containing text as query with diferences of accents. For example it will find "Alta tensión" node with query "tension". For Spanish people (my case) this is a useful behaviour. Maybe it could be useful to add a configuration option on module.
Hope this helps.
Jordi
Comment #3
danielb commentedComment #4
danielb commentedSome of this stuff can be done through 'custom matching' which has been added since this issue was created. The exact specifics of that still need to be considered.
Comment #5
danielb commentedI think the custom matching needs to be changed to allow controlling the whole matching string, rather than parts. This would require changing how matching is used as well.
Comment #6
danielb commentedIt seems I never implemented custom matching at all. The settings are there, but it does nothing! Also it seems we have to stick to the field/operator/prefix/value/suffix scheme to allow our scripts to understand what's going on.
Comment #7
danielb commentedI think matching might not be done properly at all, each find operation can only have a single match method, however in the UI you can configure different match methods for different elements. oh boy
Comment #8
danielb commentedComment #9
danielb commentedI've fixed those up now.
So yeah long story short, can't implement text matching in PHP - this is a database driven module and when we've dabbled in PHP matching in the past it has just turned into a nightmare. You have to use the matching configuration as it is with "field [operator] [prefix]value[suffix]" I can't let it get any more general than that or all the query code will blow up.
Of course if anyone has suggestions for improvements, patches are welcome.