View Full Version : Highlight.js relocation fails, doesn't work
02-10-2009, 02:40 AM
Extensively searched the Forum - found good advice already, to earlier issues. Need advise on this one...
Zoom: Professional, Version: 6.0, Build: 1009
Server: Linux, Method: CGI
Downloaded 02/07/2009: /Installed/Configured Zoom to index my 15,000 page website this Saturday. Impressive so far!
Setup all the config options correctly. Documents include the required html/scripts.
Works fine!... if I include the highlight.js file in the SAME DIRECTORY as the document to be indexed, and leave the searched document's script (include) example set per the manual's example.
But when I move the highlight.js file to another director, of course, changing the "src" script include--- Highlighting is no longer provided.
Certainly a neophytes problem - but I need help.
02-10-2009, 08:54 AM
It should not really matter what folder the JS file is in, as long as you have the correct path set in each HTML file.
My first guess would be simply that the path to the JS file is wrong.
02-10-2009, 01:11 PM
That's been my assumption, as well, and I assume I am doing something stupid, but have been unable to figure it out.
I know the highlight.js file is in the cgi directory and I am using the following in my search results PAGE. NOTE: As stated in my first post, if I change the Script below to "src=highlight.js" (since I have another copy of the script in the same directory as my searched PAGE), highlighting works as advertised.
<LINK href="../../../../inc/ubsource.css" type=text/css rel=stylesheet>
<body background="../../../../images/wall01a.gif" bgcolor="#bae9f8" text="#003399" onLoad="highlight();">
The search form can be invoked at:
Appreciate your response...
02-10-2009, 04:55 PM
Found the problem. Poor choice of directory for highlight.js.
I put it in the 'cgi' folder and the server was blocking the access request. Moved it to newly created folder and all is well.
Appreciate your response!
SUPER PRODUCT BTW...
02-10-2009, 04:59 PM
Regarding the new highlight.js file.
Improved highlighting in context descriptions: The highlighting in context descriptions has been improved such that words matching due to stemming, synonyms, or accent insensitivity options enabled can be highlighted.
This does not work for me.
02-10-2009, 05:34 PM
Rather that just saying "does not work", can you give some details of what doesn't work. Maybe even an example. Are you sure you are even using the new JS file?
cardiogr - the feature you are quoting is for highlighting in the context descriptions. This is the text that appears on the search results page.
02-11-2009, 06:43 AM
Thank you for your answer,
If however a webpage has only a synonym matched (and not the original word searched), then you could change the generated link and instead of ?zoom_highlight=original_keyword it could be ?zoom_highlight=synonym.
Could something like that be implementable?
02-11-2009, 08:57 AM
There can be dozens of matching words on a single page once stemming, synonyms, and accent insensitivity are taken into account. Even just with synonyms there can be multiple matches. While not technically impossible to deal with all of these the costs would seem to out weight the benefit.
05-18-2009, 08:39 PM
How about passing only what is shown in the "hit list" summary for a given file? That way you're only dealing with a finite set (which you already have to enumerate to create the summary), and you avoid having no highlighting at all in files that do not contain the original search term. As it is, the highlighting appears to be "broken" on many pages.
That could work, while not perfect (there will still be many matched words that won't be highlighted), it would ensure that there is at least one word highlighted. We would still need to switch behaviour when there is no context descriptions enabled, so it would be confusing for most end users (that is, when context description is enabled, it will pass the matched word to the highlight script, when it is disabled, it will pass the matched word).
Nonetheless we will keep it in mind for a future version - especially if we hear from more people who would find this to be a worthwhile change on their site.
Powered by vBulletin® Version 4.1.12 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.