Is is possible to get XSLTSearch to do a non-wildcard search? For example in a default install, if I search for "core", I get things like "Score" and "Scored". Is it possible to mod the XSLTSearch script to get it to do an exact word match?
Looking at how most people use search (one or two words with no advanced operators specified) the default way that XSLTsearch works is geared toward the 95% of users who just want something basic. So this is a feature rather than a bug.
You could certainly modify XSLTsearch to look for complete words but
it would be stricky to get a 100% accurate condition set. First word
followed by whitespace, Word with whitespace and/or punctuation on
either side, Word surrounded by markup, et al.
As a totally crude
and not-reliable hack, you could put your search term inside quotes with
a space on either side. The quotes would trigger a 'phrase' search and
the spaces would limit the results to most cases.
I'm of the opinion that the search is fine, but the client has a bee in their bonnet because a search for the word "core" doesn't have the product called core as the top result (its actually a page that talks about scores that comes out top). I've explained that the search is working how it's meant to, but they're still not happy. I'm actually trying to talk them out of having it non-wildcard, I may end up just writing an xslt extension that does something to parse out punctuation and line returns etc and replace them with spaces, and search for the word with a space either side. It'll slow the search down some I'd imagine, but it'll make them happy!
Thanks for getting back to me so quickly, its greatly appreciated.
Here's a sneaky alternative that wouldn't require any changes to XSLTsearch that might get the best of both worlds, Tim.
1. Create a new docType property for most (maybe all) of your docTypes. Give it settings such as: Name: Custom Search Terms Alias: searchTerms Description: (optional) A list of words the search engine should rank very highly. Case-INsensitive.
2. Add the searchTerms property to the list of fields that XSLTsearch will search. Put it first in the list to give it more priority in the rankings. Put a few commas between it and the next term to give it exponentially more weight in search results!
3. Enter the word core in the searchTerms field for any pages that especially need to show up at the top of the search.
The XSLTsearch macro would then have a searchFields="searchTerms,,,,pageTitle,bodyText,etc". Just list the appropriate docType properties to search as you always have, but with your mega-weighted-search-terms field dictating the order of results.
You'll still get wildcard searches so 'core' will still find 'score' but those will appear much lower in the results.
Spot on! Thanks Doug, the extra weighted search terms has done the trick, combined with adding a dropdown to allow them to filter to key areas of the site. IT was only a few key roduct pages that had that issue, and this solves it nicely, thanks for your the pointer.
Non-Wildcard Search?
Hi,
Is is possible to get XSLTSearch to do a non-wildcard search? For example in a default install, if I search for "core", I get things like "Score" and "Scored". Is it possible to mod the XSLTSearch script to get it to do an exact word match?
Cheers,
Tim.
Hi, Tim,
Looking at how most people use search (one or two words with no advanced operators specified) the default way that XSLTsearch works is geared toward the 95% of users who just want something basic. So this is a feature rather than a bug.
You could certainly modify XSLTsearch to look for complete words but it would be stricky to get a 100% accurate condition set. First word followed by whitespace, Word with whitespace and/or punctuation on either side, Word surrounded by markup, et al.
As a totally crude and not-reliable hack, you could put your search term inside quotes with a space on either side. The quotes would trigger a 'phrase' search and the spaces would limit the results to most cases.
cheers,
doug.
Ace, that's pretty much what I thought!
:)
I'm of the opinion that the search is fine, but the client has a bee in their bonnet because a search for the word "core" doesn't have the product called core as the top result (its actually a page that talks about scores that comes out top). I've explained that the search is working how it's meant to, but they're still not happy. I'm actually trying to talk them out of having it non-wildcard, I may end up just writing an xslt extension that does something to parse out punctuation and line returns etc and replace them with spaces, and search for the word with a space either side. It'll slow the search down some I'd imagine, but it'll make them happy!
Thanks for getting back to me so quickly, its greatly appreciated.
Here's a sneaky alternative that wouldn't require any changes to XSLTsearch that might get the best of both worlds, Tim.
1. Create a new docType property for most (maybe all) of your docTypes. Give it settings such as:
Name: Custom Search Terms
Alias: searchTerms
Description: (optional) A list of words the search engine should rank very highly. Case-INsensitive.
2. Add the searchTerms property to the list of fields that XSLTsearch will search. Put it first in the list to give it more priority in the rankings. Put a few commas between it and the next term to give it exponentially more weight in search results!
3. Enter the word core in the searchTerms field for any pages that especially need to show up at the top of the search.
The XSLTsearch macro would then have a searchFields="searchTerms,,,,pageTitle,bodyText,etc". Just list the appropriate docType properties to search as you always have, but with your mega-weighted-search-terms field dictating the order of results.
You'll still get wildcard searches so 'core' will still find 'score' but those will appear much lower in the results.
cheers,
doug.
Spot on! Thanks Doug, the extra weighted search terms has done the trick, combined with adding a dropdown to allow them to filter to key areas of the site. IT was only a few key roduct pages that had that issue, and this solves it nicely, thanks for your the pointer.
:)
is working on a reply...