Highlighting in the target page

[Norm Acunis]

I followed the steps in the advanced features section for highlighting searched content in the target page. That included a check box prior to indexing, the indexing with the check box on, the addition of the highlight.js in multiple locations on my web site including the directory in which the index resides, the modification of my template to add header and content after the /body tag, saved the template, uploaded it and the html files affected by that update, and then did a search.

What did appear different was the url that had some sort of highlight tag appended to it. What DID NOT occur was the actual highlighting of the search term in one of the results documents.

Wish there was a way to dependably implement this feature.

[Richard]

Assuming you followed all the instructions on the following FAQ on highlighting.

Please provide a URL for us to test and possibly spot where the problem might be occurring. If you do not wish to provide your URL on the public forums. You can send it to us via email, referencing this thread.

[Norm Acunis]

I'd love to get your help

Thanks for your offer to help.

I've set up a guest login:
url is

your guest login is

After doing the stuff in the manual, I didn't clearly understand the FAQ sp your help is most welcomed. Your search engine is at

http://acunishistory.net/go/indexer/search.php

[Norm Acunis]

Would love your help

The url for my web site is "http://acunishistory.net"

You'll need to login:
username =
password =



Any search will show what I mean.

Thanks so much

[Ray]

This is what you have on the page:

<script type="text/javascript">
<style type="text/css">.highlight { background: #FFFF40; }</style>
<script type="text/javascript" src="highlight.js"></script>
</script>

This is not correct.

You have wrapped the HTML from the FAQ in an unnecessary script tag causing the browser to ignore it (because it was trying to parse it as JS).

What you should have is just this (remove the script tag enclosing those two lines above):

<style type="text/css">.highlight { background: #FFFF40; }</style>
<script type="text/javascript" src="highlight.js"></script>

Try that, it should work.

I followed the steps in the advanced features section for highlighting searched content in the target page. That included [...] the addition of the highlight.js in multiple locations on my web site including the directory in which the index resides

The "highlight.js" file does not need to be in multiple places if you can reference it from your other pages relatively. For example, if you place the "highlight.js" file in the web root folder of your site, you can link to it with a preceding slash like:
<script type="text/javascript" src="/highlight.js">

If you are unfamiliar with linking via relative paths (which is essential web site building knowledge), it's worth looking up some tutorials online. There's also an Appendix chapter in the Users Guide.

[Norm Acunis]

Excellent!!!!!!!

Thank you so much! Worked like a charm.

Norm

[Norm Acunis]

Excellent!!!!!!!

Canceling this response. Thanks again.

[Norm Acunis]

Excellent!!!!!!!

Ray, you have been an excellent resource

Norm

[Norm Acunis]

Regarding the improper redirect to my login page from any search result, I am providing a temporary login and password so you can help.

web site is at http://acunishistory.net
username = "exception-login"
password = "wrensoft"

Once logged in, you can access the search engine via the left menu bar option titled "Search"

This really has me upset so I look forward to help to resolve why all results direct to the PHP login page. This was working fine until I accidentally deleted the "zoom.zcfg" file that was sitting on my desktop.

[Ray]

I just went to the website and had a look, but couldn't see the problem.

I did a search for "test" and clicked on a few of the result links. It successfully took me to the pages and did not redirect to the login page.

Have you since fixed the problem or is there a situation you can point me to demonstrate the problem?

I think you are referring to the problem described in your previous thread here:
http://www.wrensoft.com/forum/showthread.php?t=4156

(rather than this one that you posted in, which makes no mention of redirecting)

And the answer may well be the same as what addressed it back then.

[Norm Acunis]

Firefox not IE

I am having the problem only with the Firefox browser (on multiple PCs) so if you tried IE, it will work fine. The question has become specific to Firefox. Thanks Ray!

[Norm Acunis]

It's browser dependent

Hi Ray, just double checked and with IE, no problem. Firefox however, branches to an authentication page.

All of my html pages start with:

<?
session_start();
if(!session_is_registered(myusername)){
header("location:http://acunishistory.net/go/auth/main_login.php");
}
?>

This checks to see whether there is an active session and if there isn't to branch to the login page. I placed that code in the template for "search_template.html" based on previous work with your group. But for whatever reason, only IE works, and works flawlessly. Firefox does this wacky redirect to the login page for any search results.

Can you check my site with Firefox? Make sure the resulting page is one with my template on the left as this is one that has all the highlight and jump code. There are pages that belong to others from whom I got permission to use like the first 2 results you get entering the keyword "test". That page does not have my template and so, no highlighting or jumping to....

[Ray]

Just tested with Firefox 3.6.12 and no problems there either.

Given the behaviour you are describing, it might have something do with your personal Firefox settings not allowing cookies which is preventing sessions from working. Check "Tools"->"Privacy" in Firefox.

UPDATE: Okay, I think I've sussed the problem.

Your sessions are implemented with cookies. Cookies are set for each domain. Technically, "www.acunishistory.net" is a different domain from "acunishistory.net".

This means when you have logged in via "acunishistory.net" and issued a session cookie for that domain, you will be unable to access pages from the "www" domain name.

Because you have indexed your website with the "www.acunishistory.net" domain name, so all your search results are pointing to the "www" domain name, when your login only created a cookie for "acunishistory.net".

So you can either:

(a) Re-index your site making sure to use a base URL without the "www." domain name. Note that should there be any other links on your website which point to the "www." version of the URL, it will fail. So you'll want to make sure all your links are consistently named.

(b) Fix your login method so that it works for both domains.

[Norm Acunis]

Thank you!

Ray, you are THE man! Thank you. Once again, you solved it. With great respect for your talent. Thank you, Thank you.

With that said, it seems to me that zoom search code could know that www.domain.net is equal to domain.net. I think it should be a code request.

I've gotten my authentication changed and all is well now. Feel free to consider this closed!

[Ray]

With that said, it seems to me that zoom search code could know that www.domain.net is equal to domain.net. I think it should be a code request.

It's not really anything we can address.

Technically, it is possible to setup a site so that www.domain.net goes to a different website than domain.net.

But more importantly, Zoom's part of the process here is simply providing the URL to the page in the search results. This is configured by you with the base URL - it has to be one or the other. You can actually avoid this if you used relative links and a base URL of "./" but that won't work for everybody either.

The problem, in all honesty, is not a Zoom-related issue.

Like I said, you can have the same problem if you have an ordinary link anywhere else on your website which points to www.domain.net/page.html when the rest of your site is expecting it without "www", you will be logged out again. The problem is with the login authentication method not addressing both domains, and the browser not recognizing both are the same domains (which IE apparently does, but FF, being more strigent on standards, does not). This is why it works in IE and not FF -- it has nothing to do with Zoom.

Anyhow, good to hear it's sorted out now and glad to be of help.