WebHelp Plus Search not functioning

[LTinker68]

How is that different from what's in the Flare help (Features > WebHelp > More About WebHelp Plus > Enabling WebHelp Plus Output)?

[kashby]

I think the key is in making sure MCPreview is not enabled as an application and that you dump the AutoMerge cache. This should get the TOC working again. The rest of the steps are just "stock" to make sure you are still configured correctly and to ensure that the index will run.

[RamonS]

Having WebHelp Plus written as PHP scripts and running this whole thing on Apache would be so much easier. I know this isn't helping, but MadCap clearly chose the platform that is most difficult to administer. I work extensively with IIS and ASP.NET applications and they all are just a major pain in the rear.

[SusanL]

Kashby -- So are these instructions for users to get WebHelp Plus running on their local machines, or is this also for the Web Server? When I view the WebHelp Plus locally, the TOC and Index look fine. Only the Search doesn't work, but if I stop and then restart the Indexing Service it then works fine if I post the localhost URL into an already opened browser.

When I publish to the Web server is when the TOC is blank, the Index never loads, and the Search doesn't work, despite following all the instructions on Enabling WebHelp Plus in the MadCap Help.

[SusanL]

We noticed a warning at the bottom of the page after publishing WebHelp Plus to the server:



So I removed the Index from the skin, and no longer saw this error. However, the TOC was still blank and the Search was still not working.

Any clues?

[kashby]

The instructions I provided were targeted primarily for fixing problems with hosting the system on a local machine, but we did the same things on our server.

Have you tried clearing the AutoMerge cache? Did it do anything?

[SusanL]

I followed your instructions on my local machine, and still was not getting the Search capability. Only when I stopped and restarted the Indexing Service was I able to see WebHelp Plus correctly.

I then published the help to my Web Server and still have the same problems.

[kashby]

I wonder if you just need to re-run ConfigureISForWebHelpPlus.exe on the server?

Can you access content on the server using the Query the Catalog option?
(Start > Control Panel > Administrative Tools > Computer Management > Services and Applications > Indexing Service > Web > Query the Catalog)

[SusanL]

The only thing they haven't done is reboot the server (this server is used for other testing so it has to be done at night), so I'll rebuild the Webhelp Plus tomorrow and duly report.

Well, I thought they had rebooted the server last night -- but turns out they did it about an hour ago. I published WebHelp Plus to the Web server and now everything is working.

The simplest things really mess me up...

[HelpTrog]

Susan, please do me a favor and let me know if everything continues to work (locally and on server). Do you think rebooting the server was the only obstacle, or was it a combination of things? Does search for non-xhtml docs work locally?

Still confused.

[SusanL]

Looks like I spoke too soon. Republished the WebPlus Help to the Web server and am having the same problem -- blank TOC, non-loading index, no search functionality -- then we stopped and started IIS and the Indexing Service on the server, and then ran ConfigureISForWebHelpPlus.exe, and that didn't fix the issue.

Since I am in a building and testing phase, I am rebuilding and publishing repeatedly. I can't take the time to reboot the test server each time I want to publish WebHelp Plus. Again, looks like I'm back to using WebHelp.

Sorry I can't be of more help, HelpTrog.

[kashby]

Were you able to empty the AutoMergeCache folder on the server?

[KMac]

True, MadCap made that decision for us by mandating that we use a Microsoft only product.

Man, you're kidding, right? I have a 4 way Unix box to serve up my WebHelp. Why would a start-up lock in with a proprietary model?

[RamonS]

The only explanation is "funding". It is easier to get investors when starting off with a Microsoft partnership. Sometimes economic reasons topple technological reasons. And nobody got ever fired for using Microsoft....

[KevinDAmery]

The only explanation is "funding". It is easier to get investors when starting off with a Microsoft partnership. Sometimes economic reasons topple technological reasons. And nobody got ever fired for using Microsoft....

There was a time when people said that about IBM too...

[SusanL]

Were you able to empty the AutoMergeCache folder on the server?

I'm not using the AutoMerge feature for this testing. When I build, I can see the AutoMergeCache on my local drive in Inetpub, but when I publish the WebHelp Plus to the server that folder is not published. So there is no AutoMergeCache to empty on the server. I'm assuming it would be published to the same destination as the rest of the folders.

[kashby]

I don't merge anything into my project at compile time, but I do put compiled help systems into the AutoMerge folder afterward. However, the AutoMergeCache folder always publishes on my machine. The fact that you don't see this folder on your server concerns me because you can see it locally. Does purging it locally make everything work okay?

I assume you are using a publishing destination of some sort. Have you tried just copying the build from your local machine to the server? In my situation, I don't currently publish to the server. Instead, I build locally and then copy the structure to the server--I have had problems with content disappearing the other way.

Hang in there, this is a learning process for all of us.

[SusanL]

I copied the site from my local to the server, emptied the AutoMergeCache, and still had a blank TOC, index error, and no search function.

Interestingly, I can get this to work on my local drive, if I do not open the site from Flare after the build. If I allow Flare to open the site for me, the Search function doesn't work, and I have to stop and restart the Indexing Service to get it to work, and then I have to paste http://localhost/MCPreview/Default.htm into an open browser.

So I avoid using Flare to open the WebHelp Plus site for me -- it works fine if I open the browser and paste the MCPreview path in.

But WebHelp publishes to the server just fine, so I think I'll give up on WebHelp Plus for the time being.

[kashby]

I believe you have to open your project for the first time from Flare, then can close it and open it from a browser before all of those things will work.

Good luck, sorry I wasn't much help.

[SusanL]

I believe you have to open your project for the first time from Flare, then can close it and open it from a browser before all of those things will work.

Opening up the project in Flare and then copying the project and/or publishing to the Web Server still gave the same unsatisfactory results. But thanks for the help -- I was able to try a few more things. I'm thinking that there is some setting/program on the server that is causing a conflict with the Web site, and I need to get help from our IT team.

[SusanL]

WebHelp Plus not working properly has been an issue since the summer, as I found on this thread:
http://forums.madcapsoftware.com/viewto ... &sk=t&sd=a

Accessing our WebHelp Plus site through this file path:
\\nccpatest2\SOPHelpDocumentPlus\Default.htm
--displays everything correctly in WebHelp Plus.

Accessing the WebHelp Plus site using this URL doesn't work:
http://nccpatest2/SOPHelpDocumentPlus/Default.htm
--This is when we get the blank TOC, error on Index, and no search capability.

Other Web sites are able to open correctly from this Web server (Windows Server 2003) using URLs, (such as the WebHelp target of this same help). We have checked and rechecked all the server settings that were listed in (Features > WebHelp > More About WebHelp Plus > Enabling WebHelp Plus Output) and are clueless.

[HelpTrog]

Here is a modest success to report. I at least have the server side of the issue settled. I still can't test locally, and probably never will. After emailing a help request, a tech support rep set up a remote session with me. Everything pointed to a small (not necessarily easy) fix, and it was. We verified that all services, including indexing, were working except for search. In the Service.asmx file (on the server), is a portal-type page to all the WebHelp Plus services. Click the link for search functionality. Enter "null" in the second of two fields there (rather than leaving it blank). Advanced search worked fine after that.

A few things to note:

If you are trying to list and link non-XHTML docs as TOC items (like me), you have to consider the document and the file titles carefully.

You have to open the properties for those TOC items and make sure the URL points to the AutoSearch folder.

The advanced search function will not find the title listed in the TOC. It will do a full-text search, and it will find the file name. Kashby pointed out in a related thread that you can control this in Word docs by opening properties (in the open doc) and entering a title. This is true for .xls and .pdf as well.

If you are using Feedback, I don't believe there is a way to make these non-XHTML TOC items show up in the data.

Hope this sheds some more light.

[kashby]

HelpTrog,

I'm glad you got everything working.

For what it's worth, I submitted a request to MadCap to add the ability to include TOC names in searches. This would work hand-in-hand with setting the file property information to allow users to search for links (contained in the TOC) and some of those stubborn third-party documents that are otherwise unsearchable. It might also help if Flare could use keywords specified in file properties--then anyone could specify search keywords and every third-party document included in a project would be easy to find (especially useful when using WebHelpPlus and allowing users to publish their own content to the system).

If anyone else thinks these would be useful additions, start petitioning MadCap.