Modified com-search to offer spelling suggestion (Did you mean: xxxxx)

[limestone]

You know when Google suggests what it thinks you might have meant, if you misspell a search term? Well, this com_search hack does the same thing.

It looks up soundalike terms from the core search terms log table and suggests the most frequently-searched one, if any exists. This is a simplified version of how I understand Google does it too.

You will need to be logging search terms, or it just won't do anything, and a site with plenty of existing search history will work best. It adds one database query - and I'm not sure what the extra overhead will be on a huge search term log, but on one site I have tried it on that has nearly 3000 different search terms logged, it doesn't seem to hurt at all. It also uses some bits of code pinched from phlooid's excellent 'Search Cloud' module to allow submission of the search form through javascript.

To install, just unzip and replace the existing com_search. That's all - nothing to do to the database. However, even though I have it installed on a couple of sites, it should only be considered an alpha release, as there could be things I haven't spotted. (Shouldn't be, but you never know!)

In the future, I would really like to see the core com_search have an admin backend to allow its configuration to include optional extras like this (and to allow you to switch off the 'search in Google' bit!!).

See how you get on with it, and post your thoughts here.

Edit 29 Aug 2006 This hack was for J! 1.0.10 Do not use it with 1.0.11!

[eyezberg]

What's it supposed to be doing?
I see now change at all after overwritting the files..

[limestone]

Try entering a search term that is spelled slightly wrong, compared to one that is already in the log spelled correctly.

Real life example from my live log - if I enter 'trophey' it says 'Do you mean: trophy', because 'trophy' is already in the log, and has a higher search count than 'trophey'.

The correctly spelled word must already exist in the search log, that's why I said earlier that a site with plenty of existing search history works best. On a new installation it will do nothing outside of what it already does, but once a site has logged some user-input search terms, it will start to work. Assuming most site visitors spell their searches correctly, some of those that make the odd typo will be helped out.

[duvien]

sounds very useful and if it works really well i do hope it will be incorporated into the offical J!

Anyway, is this hack for J1.0.10?

thanks

[limestone]

It was for 1.0.10, yes.

Unfortunately, 1.0.11 replaces search.html.php, so function calls in the hacked search.php now cause an error.

So do not use this hack with 1.0.11!

[duvien]

Thanks for the info, I gather it was for 1.0.10 and now J! is updated to 1.0.11. However, are you planning to update your script to work with 1.0.11?

cheers,

[limestone]

I should expect so, yes.

However, I've been thinking about improving/replacing the whole search component, rather than just fiddling about with the existing one. I'd very much like to see fulltext searching available, although I realise this would need sweeping changes to table indexes and search mambots. Actually, I suspect an implementation of fulltext search would do away with the need for search mambots as they exist now.

Much more research is required on my part, but my current thinking is that mySQL temporary tables might be the answer, with a new type of search mambot (which might just be an xml file) reporting to the search component about which columns from a component's table need to be included in a temporary table, to be fulltext indexed and used for seaching. The problem is the different data that each component stores would all have to be amalgamated before a fulltext index could be created, as I understand things. (My current understanding is a bit sketchy.)

Has anyone any thoughts on this?

[delasoup]

This is a good hack for 1.5:
http://joomla-r-us.com/home/37-joomlatu ... mla-search