Basic Search snippet and highlight plugin modification

Just for info I have a basic but robust search snippet available at http://www.timspencerweb.co.uk/modx-search .

There is also a (slightly) modified version of the search highlight plugin more usually associated with AjaxSearch.

I wrote the former and modified the latter as part of the same project, but each stand alone. The snippet doesn’t require the plugin (as long as you only want highlighting to occur in the results list) and the modified plugin should be able to be used with AjaxSearch or any other search snippet that sends the search terms and the highlight class(es) in the same way.

-- Tim.

Tim,
Thanks for making the effort and sharing.
Before I give it a try, what are the advantages of your search over AjaxSearch?

David

Main advantage: Less to go wrong.

Arguably its simpler to implement, but I’ll leave that to others to decide. I think its simpler and easier to use, but I would wouldn’t I?  You do have to write the (X)HTML form separately, though thats simple if you just copy mine from my website.

I hope this doesn’t come out as too critical of AjaxSearch - it has alot of features and represents alot of hard work - but after having used AjaxSearch in both Ajax and non-Ajax modes I decided that personally I wanted something simpler that was more reliable. To be fair to the developers some of the problems I had may be browser bugginess rather than script bugginess - and in the case of the Ajax mode were often too intermittent to work out the conditions giving rise to them - but the client doesn’t care about that. Problems with the non-Ajax search mode were often solved by simply upgrading from 1.7 to 1.8, but while I’m happy to upgrade for more features I didn’t want to be doing that just to make it work and did dent my confidence in it. Other minor points were that I didn’t like the way it glues together user-defined template variables to form extracts (if it doesn’t find anything in the default tvs), (X)HTML entities get output in extracts as their codes, it doesn’t find content that is stored as entities, and that if your search text matches an entity code you get a false positive.

So whilst AjaxSearch has loads of features, I wasn’t using most of them anyway, and was having problems. I wanted something basic (and also fancied a small project). I guess its down to whether you want a minimalist thing that has less to go wrong, and if it does is small enough to examine without incurring a huge time overhead - or do you want lots of features.

The plugin for highlighting does stand alone BTW - its more a fix of a few bugs from version 1.3. In addition if you search for characters that have corresponding entity codes it will search for both unencoded and encoded versions of the search terms. It will be of use to people using AjaxSearch. It shouldn’t highlight its false positives mentioned above.

And in the interests of balance, main disadvantage: my search snippet can do much less.

My offering won’t appeal to everyone. If you are happy with AjaxSearch and its features, I’ve no interest in converting anyone into using something that may not do what they want when AjaxSearch is in the default install anyway.

Its also only fair to mention that my script does have some issues. If say you search for ’artifical example nbsp’ and a document has the words ’artificial’, ’example’ and the entity &nbsp, it will report having found all three search terms (although it doesn’t highlight the &nbsp). Also, like AjaxSearch it doesn’t find words with tags embedded within them. Lastly, the specified length of the extract is actually taken to be the number of bytes rather than the number of characters - relevant for UTF-8 - but I doubt you’d notice.

It doesn’t find the contents of title attributes. Whether this is an issue generally I am unsure. Normally you don’t see the title’s - they are not ’normal’ content, so should I search for them? I am minded to think that for <abbr> and <acronym> I should, but am unsure as to other tags.

If you want to see it in action on an unfinished site (this one being a hobby thing rather than for a client) try www.vintage.nutclough.co.uk. The site is incomplete and may have some other glitches, but the search should work fine! Any bugs however minor - let me know. I’m hoping there are not any major ones now...

Thanks for the comprehensive and fair explanation/analysis!
I’ll give it a try on one of the sites I’m currently developing and report back.

I have posted an updated version (1.1 beta) to http://www.timspencerweb.co.uk/modx-search .

1. Inputing no search terms returns an error message to that effect. Probably not a big deal, but could avoid confusion of clumsy users.
2. Snippet now searches title attributes for all tags except <a> tags. Mainly relevant for <abbr> and <acronym>.
3. Extracts can now be formed from multibyte characters - 1.0 was embarassingly buggy here. Apols!

Its a beta, mainly because I haven’t rigourously tested it at the moment, but it will shortly be going on a live site with Kanji characters because AjaxSearch doesn’t seem to be finding all the documents it should.

-- Tim.

Hi there,

thank you for sharing!

cheers, j

@ Tim,

find some comments ...

Main advantage: Less to go wrong.

I agree with this short declaration. This is the reason why all the AjaxSearch parameters are optionals. And if you use the non-ajax mode, you don’t load the ajax code neither the js script. Same thing with the debugging and the logging classes. Each time I try to minimize the volume of the php code loaded.

but after having used AjaxSearch in both Ajax and non-Ajax modes I decided that personally I wanted something simpler that was more reliable

If from your point of view AS is not enought reliable, could you post the last issues you have raised this last time. I am interested to continue to improve the AS snippet for everybody.

I had may be browser bugginess

Which kind of issues did you encontered ? With which browser and with which AS version ?

and in the case of the Ajax mode were often too intermittent to work out the conditions giving rise to them.

What do you mean by intermittent ?

Problems with the non-Ajax search mode were often solved by simply upgrading from 1.7 to 1.8, but while I’m happy to upgrade for more features I didn’t want to be doing that just to make it work and did dent my confidence in it.

Again, I could understand, but I am not sure that create a new snippet from scratch, could be a solution for everybody.

Other minor points were that I didn’t like the way it glues together user-defined template variables to form extracts.

The default value of the extract parameter is : ’1:content,description,introtext,tv_value’. To change this behaviour simply specify which content fields you would like use in the extract. for instance: ’1:content,description’

HTML entities get output in extracts as their codes, it doesn’t find content that is stored as entities.

You are right. Your content should be saved as raw text. The search of "&eacute;cole" in addition of the search of "école" will make more complex the sql request. But may be you have some suggestion to solve this complexity. (Search among entity encoded accentuated letters and non entity encoded letters).

Lastly, the specified length of the extract is actually taken to be the number of bytes rather than the number of characters.

Done also with AS.

but it will shortly be going on a live site with Kanji characters because AjaxSearch doesn’t seem to be finding all the documents it should.

Could you open a post about this issue and give me a content and search terms used in order to redo the tests. This will profit to anybody.

Thanks for the improvement of the search highlight plugin. I will do some tests with AS and I will propose some of your updates with the next release.


Otherwise, i think that a new search snippet is interesting for the community.
But keep this snippet simple otherwise, you will miss your objective

Hi mates!

I have made all as discribed here: http://www.web.nutclough.co.uk/modx_search.php

Have put in template:
<div id="nav-search">
<form action="[~41~]" method="get">
<div>
<label for="searchTerms">Search Terms</label>
<input id="searchTerms" name="searchTerms" type="text" />
<input class="button" id="search" name="search" value="Search" type="submit" />
</div>
</form>
</div>


And in the page 41:
[!Search? &searchRequestType=`GET` &searchTerms=`searchTerms`!]


Whe I press Search button, it drops me to the 1-st page of the site.

What is the error?

a_lex:

It looks like MODx isn’t finding document 41, and is falling back to doc 1 (the default) in its apparent absence.

Check that Doc 41 is published, clear the cache.

Check the source of the search form’s page and check that modx has parsed the [~41~] to the url of doc 41. If friendly URLs are off this should be index.php?id=41, otherwise it should be the alias of doc 41. (Apols if this is teaching you to suck eggs - I don’t know how much modx experience you have).

If none of this gets you anywhere, remove the [!Search ...!] call from doc 41’s template. Although I don’t see how the snippet could be dumping you on doc 1, at least it removes it from the equation while we work out where this problem lies.

Let me know what happens.

-- Tim.

coroico:

I will PM with more info on AjaxSearch as requested, though the apparent bugs we found were intermittent i.e. sometimes they occured, sometimes not. If they always occured I would have posted the conditions that caused the problem, but we never managed to pin them down. The issue with extracts and TV values is that AFAIK, it doesn’t isolate one user-defined template variable in the extract in the way you it isolates the default tvs e.g. AjaxSearch is happy to return just the ’content’, but not just the ’content_part2’ - you’ll get ’content_part2’ concatenated to ’content_part3’ even if ’content_part3’ doesn’t contain any search terms. I have posted re: the Kanji problem separately.

I am not sure that create a new snippet from scratch, could be a solution for everybody

Possibly not - as I hope I initially made clear, I am not interested in being in competition with anyone. I wrote this to solve a problem at work, which it is doing (although I may need to add pagination as briefly refered to in the comments in the code), and am just offering it for anyone else to use, should they wish.

Lastly, the specified length of the extract is actually taken to be the number of bytes rather than the number of characters.

I have changed this in v1.1 - or rather it now counts characters as a side effect of the changes needed to handle multibyte characters in result extracts correctly.

You are right. Your content should be saved as raw text. The search of "&eacute;cole" in addition of the search of "école" will make more complex the sql request. But may be you have some suggestion to solve this complexity. (Search among entity encoded accentuated letters and non entity encoded letters).

TinyMCE saves certain characters e.g. ’£’ as &pound; (as it should in the modern standards compliant world) - but this means AjaxSearch will not currently find them.

Have a look at the source code on my website - its all commented and is available for use. Basically you just construct multiple search terms for unencoded and encoded strings (bearing also in mind that there are three different types of consistent encoding), and then to avoid slowing down the MySQL unneccessarily (only relevant if the site is very large) I ensure I am not just duplicating the search terms pointlessly.

Thanks for the comments.
Tim.