Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Site Search Limitations


Reply


637 Views

Avatar
Terry Apodaca

Community Member, 109 Posts

12 March 2011 at 9:25am

I have seen several issues with this, and yes I have searched for my particular issue but I have not found one with a good answer, only speculation. Let me give you a quick overview:

I have a where i have a client that has products with say....Product Number: 800-80, and they want to be able to search for these products on the website based on not only the content and title, they want to search the product number too.

Well, as we all know, the default Site Search only indexes the Content field, Title fields, and the Meta fields. Any custom field you add is not going to be searched. So I built a little workaround based Aram's workaround so that these custom fields will be saved to the MetaKeywords and the MetaDescription so they can be searched. This also helps the clients a little in external search engines so they were ok with it. Not only that, but they didn't want to go in and add their own custom meta data for each product so this kind of did the trick.

Anyway, I can't change the ft_min_word_len=3 because they are on a shared host. so...the above is all i can think of.

Here's the kicker, if they have a product number that's like this: "MT-58SL" or even "1600-10" the search finds it.

If they have a product number that's like this: "400-10" or "800-00" the search DOES NOT find it.

I don't know if the shortness and then the dash is disregarded so it skips the indexing because it thinks its actually "800" and "00"?

I need to know if this is the issue or what the indexing thinks of this or is it MySQL? or is it simply because it's a number? it can't be because it's a number because "1600-00" returns a (valid) result.