I haven’t looked at the code, but it seems to me as if the trim is only fixing the issue with spaces at the beginning or end of the entered search term. However the script still throws a parse error (below) if the user enters two or more spaces between words in the query (e.g., "ecuador peru"). Looks to me that the search query is being exploded using spaces but zero-character fragments aren’t being discarded before passing them to strpos().
Error: strpos() [function.strpos]: Empty delimiter
Error type/ Nr.: Warning - 2
File: /path/to/my/install/assets/snippets/ajaxSearch/classes/search.class.inc.php
Line: 1096
Line 1096 source: $wordLeft = $mbStrpos($mbStrtolower($text), $mbStrtolower($searchTerm))
Also: I thought that I would fix the issue on my site by using the exactphrase method, but it’s not working for me at all (even when I hard-code it in the snippet itself). It’s not just that the highlighting plugin doesn’t respect this setting (as mentioned
here). It’s still searching using the oneword method (and in fact it ignores allwords as well, so the config is just not being respected as far as I can tell).
I’m also getting the PHx placeholder code from results.tpl.html outputted to the screen periodically, and I think that I figured out that it happens if the search query includes "is a" (e.g., "that is a bug"). That would make me believe that there are probably other similar terms that would also cause this sort of thing, and that it could occur with any of the templates. So you should probably review how you’re parsing through the results (could you replace the PHx code before the other placeholders so that you don’t replace PHx code by accident?).
And lastly (sorry for all this!), I stumbled upon another weird glitch in the highlighting plugin. If I search for something like "ecuador span" or even "ecuador pan" the highlighting code gets broken up and spit out in the results in a really weird way (as strikethrough text).
I’m using AjaxSearch 1.8.1 on MODx 0.9.6.3 in non-Ajax mode.