AjaxSearch 'oneword' and non-plugin 'highlight' Issues

Good afternoon,

I’ve run into a couple of problems with the AjaxSearch snippet that I’ve been unable to find solutions for either on the forum or on the internet in general, so I’m hoping somebody may be able to assist me with the problems I’m having. I am working with the v1.8.1 release of AjaxSearch.

---

The first problem is regarding the results of a search with the "&advSearch=`oneword`" option (the default). I find that regardless of my "&minChars" setting, after the first search term has been validated as being the proper length, I am then able to specify search terms shorter than that length which are individually searched. For example, if my &minChars is set to `4`, the terms "a" "be" "cee" will all be rejected, but "deee" is valid. However, other valid terms include anything containing 4 or more characters, such as "a te" or "dog " (note the spaces). In the former example, the system will do searches for "a" and "te" terms, which in "oneword" shows many results since many words contain the letter "a". This isn’t the behaviour I’m going for and I just want space-separated terms that contain at least "minChars" characters to be validated (i.e: "horse rats" would search for "horse" and "rats" or any words containing such a sequence of characters, while "horse rat" would have the "rat" term (or entire request) rejected from search because it doesn’t reach minchars length. The PHP code for the snippet states that minChars (default value 3) is already supposed to drop any search term that isn’t "minChars" in length, but as I’ve explained this isn’t happening in my case. I have tried using default "minChars"/"advSearch" and manually specifying them (specifically ’oneword’ for the latter since that’s what I’m after) but the results are always the same, the only variation is the number of characters before the entire string is validated based on the value of "minChars".

On the AjaxSearch demo site I get identical results where short terms are validated despite the "minChars" setting of ’3’ as long as the field contains at least 3 characters. For example, if you search for "a z", you get back results with every instance of the letter "a" highlighted, and both "a" and "z" are shown as different validated search terms. On both the demo site and in my own testing configuration, it’s acting like the code is checking the entire submitted string for "minChars" instead of each of the space-separated terms. Am I doing something wrong and if so how may I correct it through some parameter I may have missed, or does the code validate the whole string and not its individual terms?

---

The second problem I’ve encountered is somewhat more crippling and is regarding the highlighting of search results. This does not relate to the search result plugins, but rather the highlighted terms on the ’results’ page. This is another problem I’ve been able to reproduce on the AjaxSearch demo site.

In both my tests and on the Ajax site there is a number of ".AS_ajax_highlightX, .ajaxSearch_highlightX" entries in the CSS code to allow the different search terms to appear highlighted in different colours. The actual HTML code for ajaxSearch_highlight is itself being highlighted if the next search term contains text that is within the HTML code for the highlight.

For example, if you do a search for "demo" on the demo site, this is the first entry:

First year of school: crucial for the rest of a child’s life First year of school: crucial for the rest of a child’s life

...ar. He has even asked for the program to become institutional, given that Alvaro Colom, a Social-Democrat elected for four years, officially begins his term on 14 January 2008. Ovando explain...

This is the generated HTML code:




All good so far. However, change the search to "demo ajax" and here’s the same entry:

First year of school: crucial for the rest of a child’s life First year of school: crucial for the rest of a child’s life

...ar. He has even asked for the program to become institutional, given that Alvaro Colom, a Social-ajaxSearch_highlight ajaxSearch_highlight1">Democrat elected for four years, officially begins his term on 14 January 2008. Ovando explain...

This is the generated HTML code:



The highlighting acts recursively on the extract. The extract is obtained, the first search term is highlighted, then the second term is highlighted. SInce ’ajax’ appears in the HTML code which highlights the word "demo", "<span class="ajaxSearch_highlight ajaxSearch_highlight1">Demo</span>crat" gets replaced by "<span class="<span class="ajaxSearch_highlight ajaxSearch_highlight2">ajax</span>Search_highlight <span class="ajaxSearch_highlight ajaxSearch_highlight2">ajax</span>Search_highlight1">Demo</span>crat". Clearly this is a mess.

This continue. I can change the search to "demo ajax search". Now the second term also gets interrupted:

First year of school: crucial for the rest of a child’s life First year of school: crucial for the rest of a child’s life

...ar. He has even asked for the program to become institutional, given that Alvaro Colom, a Social-Search_highlight ajaxSearch_highlight2">ajaxSearch_highlight Search_highlight ajaxSearch_highlight2">ajaxSearch_highlight1">Democrat elected for four years, officially begins his term on 14 January 2008. Ovando explain...

And the matching code:



The problem can even be further exasperated by layering on the first problem I reported with small search terms. A search for "a a" is enough to fill up a page with a staggering amount of text. Make that even longer and AjaxSearch can’t even keep up anymore, which for the stability of the affected system is probably a good thing.

Other than disabling highlighting on the search results page by omitting any CSS entries "ajaxSearch_highlight" (which of course results in no highlighting at all), I suspect AjaxSearch may need to strip HTML from its subsequent searches of additional terms for its own "ajaxSearch_highlight" entries, otherwise this continuous recursive highlighting of previous highlighting is infinite. Again, if I’ve completely missed the boat and there’s a way to do this through program parameters, please let me know, I’d love to be incorrect about this.

---

Any input on these two problems I’ve encountered would be greatly appreciated. Thanks very much for your assistance.


L

Hi Lacrossia

I agree with you that It will be better to take into account of the &advSearch parameter when the &minChars is checked. This is not the case.
So may be in the next release, I could apply the following algorithm:
- advSearch=`oneword` or `allwords` or `nowords`, check that all space separated words have a length greater than minChars
- advSearch=`exactphrase`, check that the input text (with or without space) have a length greater than minChars

I have registered this improvement as AJAXSEARCH-12 in JIRIA


For your second remark. This is clearly a bug. Now registered as AJAXSEARCH-13 in JIRIA

Thanks for these two interesting feedbacks. If it is possible, I try to come back to you with a hack solution to help you.

Super, thanks very much for taking the time to review these issues. I saw the notes in JIRA. If you can come up with a quick/hack solution before an official one I’d be happy to give it a try; if not, I’ll be looking forward to the next release.


L

Thanks to look at this post for a fix for the AJAXSEARCH-13 issue with the version 1.8.1 of AjaxSearch.