Deploying Webhelp with RoboHelp 8

[rinpa35]

Anyone have experience deploying Webhelp with RoboHelp 8?  I'm looking for details

for our developers for the steps involved....

[Peter Grainge]

Perhaps the Calling WebHelp topics on my site would help them.

---

See www.grainge.org for RoboHelp and Authoring tips

[rinpa35]

Thanks Peter - I'll take a look!!

[rinpa35]

We are testing deployment right now. What files exactly are necessary for deployment to web server?

As it stands now, when we view the url, the hyperlinks between topics are not working (although they

work fine when I generate the web output from RoboHelp)

Are the SSL, SkinSubFolder, and Language folder/files necessary for deployment?

Trying to figure out which file is the "index" file....

[Peter Grainge]

The SSL folder contains the output which is what your developers should be linking to. They do not want the source files and everything else mentioned or it will not work. They just need everything from the output folder you have generated to within SSL.

---

See www.grainge.org for RoboHelp and Authoring tips

[rinpa35]

Ahhh - this helps A LOT - thank you for the tip!

Rachel

[MergeThis]

the "index" file....

That, whether you name it index.htm or not, is the file name you assign at the very top of the first WebHelp generation page (the "Select Output Folder and Start Page" field)...not to be confused with the "home" page that first appears when the help is launched (the "Default Topic" field on that same first WebHelp page).

Also, our preference is to generate to an entirely separate folder not under the project folder (such as C:\MyProject for source files and C:\MyWebHelp for output). Other forum members equate this method with satanism or worse, but it works for us.

Good luck,

Leon

[rinpa35]

Thank you for the info Leon - this helps! Actually, that brings me to

another question - how do you define the home page (first page you see upon

launch)?

thanks,

Rachel

[Captiv8r]

Hi Rachel

Look at the properties for your Single Source Layout.

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 within the day - $24.95! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[rinpa35]

Found the Single Source pod - thank you! Screen shot helped too!

Rachel

[Captiv8r]

MergeThis wrote:

...Other forum members equate this method with satanism or worse, but it works for us.

LOL - I'm assuming that was directed my way. And no, I don't equate it with satanism. I only recommend that for most users it's just simpler to leave the folder structure as is. I would never recommend changing it for the sake of having it be different. Changing it without specific reasons (As Leon has) is perfectly valid and acceptable.

However, just yesterday I worked with yet another individual that was having issues that were caused by (drum roll here) changing the output folder location! We created a new layout where the folder was changed back to !SSL!\LayoutName and poof! Problem solved.

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 within the day - $24.95! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[MergeThis]

The elimination of poof!-ing is exactly why we generate outside the project!

[Captiv8r]

Hi Leon

Sorry, I don't follow what you mean. Are you saying that for some reason the default location never did work for you?

Personally, since eHelp began using that location I've never seen it fail.

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 within the day - $24.95! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[MergeThis]

No, Rick, it was never a case of the !SSL! structure not working for us. That was a riff on your previous "and poof! Problem solved." Geez, I hate when I have to explain my jokes!

The underlying reason was that I was tasked to drag a doc group, kicking and screaming, from Word/PDF output into the RH/context-sensitive WebHelp world, and the developers wanted to establish field-level context-sensitive help. Other writers have since been added, and yet some of them are still shaky when it comes to the RH project/folder/file structure. (We're up to 7 writers in a 42-project merged project environment - times 2, for two versions.)

Main pluses for us:

• Shorter generate paths, especially since it was going to take time to have all writers rename their topics to more manageable lengths (which we have finally accomplished).
• The product is extremely integrated, requiring better control of cross linking (2700 topics, 25,000 links).
• Since the only source control IT would support was Perforce, which is fine for code but not for HATs, we were copying source files to the server for backup. There was no good reason to be copying all the output folders as well. (We now are using the RH8/RSC combo for one version.)
• Paradigm engineering was able to map window/tab/control URLs to our topics more easily (and, again, with shorter destination paths).
• Release engineering could absorb the WebHelp output into the product build with no possible chance of a mixup between source and output files.
• We, unfortunately, run multiple branches of multiple versions of our products (don't ask!), and the source/output separation stands us in good stead. Especially where we're still using RH X5 for the older version and RH 8 for the newer version(s)!

Bottom line? This method works remarkably well for our environment, and I would never press anyone to adopt it. I will, however, continue to recommend it, for the reasons I've stated.

Good luck,

Leon