ZoomAutoComplete_URL variable for CGI Version

[voidinutah]

I'm in the process of implementing CGI platform of Zoom V7 (Build 1021) on our server, we currently have Zoom V6 deployed. I'm trying to get the autocomplete feature to work but running into Bad Requests. I believe the issue is with the default setting in the generated javascript that is appended to the results. Here is what my variable is:

var ZoomAutoComplete_URL = "/files/zoom_7_0/search.cgi&zoom_ac=1";

As you can see, an ampersand is used instead of question mark.

I could not find any place were I could set this myself in the configuration. I have seen post about setting this yourself using javascript, but it is when you use the js and css files for own search form. And we actually do use our own search form on the results page. But if on the Search Page tab, you have it set to not generate the form, and on the Autocomplete tab have enable autocomplete check, you still get the autocomplete code embedded on the results page. To further test this issue, I changed the search form setting to basic and the same ZoomAutoComplete_URL value is generated, search.cgi&zoom_ac=1.

I did get it to work. I found that the autocomplete js file that can be used with own search form is what is embedded on the search results page by Zoom. So I added

var ZoomAutoComplete_URL = "/files/zoom_7_0/search.cgi?zoom_ac=1";

to the js file, thus this setting was right after the Zoom generated setting for this variable. And autocomplete worked fine. However, this file is overwritten on subsequent indexes, thus this is not a workaround.

Let me know if you need anymore information.

[Ray]

I can confirm that this is a bug.

The problem occurs when you have a Link back URL setting (under "Configure"->"Advanced") which already contains a question mark parameter, e.g. if your link back URL is "action.php?page=search" and it is embedding this CGI search within it.

The CGI then switches over to use "&" (i.e. "&") to join parameters, but in this particular case with the autocomplete URL, it is using the executable path, so it does not apply. It should really just use "?" every time.

We can fix this for the next build. Or email us if you want a patch in the interim.

(Check also if you really need that Link back URL setting -- if you remove the "?" character in your link back URL setting, then it should fix this too).

[voidinutah]

Thanks for the information Ray.

We do need the link back URL because we have embedded Zoom in a ColdFusion template. What is the possibility of replacing the search.cgi with the link back URL and append zoom_ac=1 or allow for a custom URL on the autocomplete tab that would allow us to embedded the autocomplete URL in a different template.

I think I'm going to work with the js file, make a copy or rename it, and make modifications to work with our search form. Knowing my client, once they see this feature they are going to want it implemented on the site wide search form too.

Thanks!

[Ray]

The URL to the autocomplete request (zoom_ac=1) has to be directly to the CGI because it is an AJAX call and it expects no other output besides the autocomplete XML returned.

If it points to your wrapping page (link back URL), then it will have your includes and other customizations before or after the XML, and this would break the parsing of the XML. I also don't see any benefit in doing this -- perhaps we're talking about different URLs.

Yes, you're free to customize the autocomplete JS, but we don't support the modified script. If you have any problems, make sure to have a backup of the original and revert to this to confirm if the problem is the original script.

[voidinutah]

I've gotten autocomplete implemented but the list of words coming back seems to be inaccurate.

I have configured autocomplete to extract words from the Page title and Meta description. I do not have any additional words or use the log file. The first thing I noticed is that it appears that the Meta keywords is being used instead of the description. Another item was that not all the words, the ones expected, are not displayed, such as words that are in both the title and keywords. In one instance, if I type "mu" I get only three words back. One is "Muscarinic". When I search on that word, and the page listed is on Multiple Sclerosis. I was actually trying to bring up the word "multiple" which appears numerous times on the site, but it didn't show up. I then checked that pages title and keywords, and "Muscarinic" was in the keywords, not the title or description. However, "multiple" was in the title and the keywords. So even if title wasn't working, I'd at least expect it because it was in the keywords.

And I also noticed that there are some words that are in neither title or keywords, but words from another page, our listing activity page. The reason I noticed them is because they are partial words since we limit the amount of information displayed for each activity. So I have words like "evid.." and "incorpor..". Now the interesting thing about this is that there is a class tag named "description" in the div tag surrounding the text. It's not meta description. For one of the truncated descriptions, the word multiple was included. Not sure why a partial word would be included and not a full word, if for some reason, this description text was indexed for autocomplete.

Can you help me understand why some words are not be included and why others are?

Thanks,
Marc

[Ray]

You're right, "Meta description" is a misnomer in the GUI. We are currently indexing a number of different meta information as part of that option, which includes meta keywords, zoomwords, filename, and the URL path (if this is enabled for indexing). So perhaps we should update this to "Meta keywords, description, etc."

It is also possible that if you have context descriptions disabled from your results ("Configure"->"Results Layout"->"Context description" is unchecked) and a page does not have a meta description tag, then Zoom will automatically extract a portion of the body content as the meta description. In which case, this could also lead to additional words extracted from the body content for autocomplete.

If you still think something unusual is happening, provide us with a URL to the page in question so that we can index it here. Better yet, email us your .zcfg configuration and the page in question in a scenario that we can reproduce, and we can examine it further.

[voidinutah]

Thanks Ray.

I do have the Context description unchecked, but I verified that all pages had meta data. But to test, I checked it and re-indexed. I then searched on one of the partial words and the context description ended up being a portion of the meta description. We do have page content selected to be indexed. So I suspect that a portion of the meta description was selected to be displayed for context description because that is where the match occurred. If I used another word then the page context was used without the partial word included but the full word.

This ultimately lead me to the issue I was having with partial words being displayed in the autocomplete list. Since the limit for Max. description length was still set to the V6 default length (150), the meta description was truncated to 150 characters. And when truncating Zoom removes three additional characters and appends "...". With the autocomplete, I believe Zoom is removing any trailing punctuation, thus removes one of the periods and leaves only the partial word and two periods, such as "th.." and "adher..".

I can get around this by increasing the Max. description length. It would be nice if the autocomplete feature would ignore the ".." words in case some one want less text displayed for the description in the search results. I'll have to see if my client is okay with the additional text, otherwise I'll need to come up with a work around.

I still do have the issue with certain words not displaying. I'll email you the site and config file.

Thanks,
Marc