This content has been marked as final. Show 7 replies
See my answer to a similar posting. It does speak of a merged project, but the Generate/Publish path environment still applies to any project.
If you're still unsure on some point or other, come back.
Thanks for the help. I studied the procedure you described for multiple authors, and tried to understand how they might resolve my issue.
I am a single help author, and telecommute. The VPN connection to the LAN drive where I have published my WebHelp system is so slow, that I can only access it in the office, where I am connected directly to the network. My project has 24 child folders and about 425 topics.
Anyhow, here's my understanding of the procedure you suggest:
1. Publish the system to my local drive.
2. Publish the system to a folder on the network drive.
3. Copy my source files (the ones in the "HTML files (topics)" folder on the project tab) from my local drive to the same folder on the network drive.
I aleady do #1 and #2. As I mentioned, the search function functions correctly on my local drive. I am willing to copy the source files to the output folder and give this a try, but have two concerns:
1. How will this procedure impact the search function?
2. When I copy my source files and folders to the location on the LAN drive, they will overwrite my output files and folders. Right? This seems a risky strategy, though I'm willing to give it a try. If it doesn't work, I can republish the WebHelp system.
(I told my UAT team that I was going to remove the search function to resolve the issue, and they seemed distressed. No sense of humor there.)
Thanks again for your help,
After examining the generate/publish workflow, it seems that the only source of the issue we encountered could be the path to the output target on the network drive. The next time I update our test environment, I plan to use an absolute path (servername\\folder\folder), instead of the drive mapped on my local computer (S:\\folder\folder).
I will let you know the results of that.
PS: I also totally missed the purpose of copying the source files to the network location - back up. Duh.
No, no, no.
COPY project source files to your local machine (if backing up on a server).
WORK in the project source files on your local machine.
GENERATE the Webhelp output files to your local machine.
PUBLISH the Webhelp output files to a server.
COPY project source files to the server for backup ( but not to the same directory as the Webhelp output).
No, no, *sigh* no
I generated to my local drive....
I published the webhelp output to the shared drive
The search results still did not target the topics....
I tried lower case file names... no difference.
The target path at the bottom of the IE window are still truncated. to the network drive name and folder.
One thing I did notice is that the Help topic for the WebHelp Publish dialog indicated that the path slashes should be forward: f:/xyzcompany/internet.
But, when I enter the path, the slashes convert to back slashes: f:\xyzcompany\internet.
The path displays in IE (mouseover search results): file:///F:/xyzcompany/
No luck, thus far,
By any chance, is the published version missing the whdata, whgdata and/or whxdata directories? If they are present, do they contain all the same files as those on your hard drive?
Look first in the project's !SSL! directory WebHelp output folder. Compare with the "published" version on your hard drive and the network version.
This is so stupid, I should be embarrassed to state it. But, since I cannot delete this thread, I'll lay it out.
The path name to my department's folder on the company network drive is: S:\Holly's\... The apostrophe always frightened me, but it's been there for years. First created, back at the dawn of time, by a person named "Holly", of course.
This folder is the target for many FTP processes, application output, reports, extracts, etc. It's never been a problem, as far as I knew.
I noticed that the path name for the search results truncated at the apostrophe, so conjectured that the RoboHelp publishing routine was croaking on it.
I moved the published output to a path that did not include "Holly's", and that resolved the problem.
The good part is, it's fixed. The bad part was the apostrophe is still there..... ready to trip up another innocent, and clueless, developer.
Thanks for your help,