Deploying upgraded Project to Server

[HTMLRobo12]

Hi,

Last year we upgraded our RoboHelp Projects to X5 from X3. I made the upgrade on all local PCs used to edit but I never deployed the new .xpj versions files to the Server in Production. We can still deploy pages but I did run into an issue recently and was wondering if that might be related to the fact that we upgraded the Project (xpj) but didn't deploy it to the server.

I was recently contacted by individuals we make updates for their OLH pages. I was asked to change the Title in the Task bar above the page like you see in any Browser's top horizontal frame/tab. So I proceeded to make the change through the Project Title options menu and saved and redployed the .hhp file where I believe this change occurs. However, I never saw the change in Production and was wondering could it be that certain changes, beside page edits, are related to the original settings of the project that were first created and the old settings are sitting on the server because either the new upgraded prj needs to get deployed or some new file that is created through X5 needs to be deployed? I don't know what is preventing me from making Project settings changes on the server after I have deployed them. By the way I can see the tile change in the Compiled primary preview within RoboHelp. The change can also be seen in the deployed .hhp file in notepad.

Please Advise.

[Peter Grainge]

Your talk of deploying xpj and hhp files on the server confuses me. They are source files that should remain on your hard disk. They are not part of the output that should be on the server.

Can you explain your process for generating and publishing the output to the server?

[HTMLRobo12]

Ok.

Well we use HTML Help. By output files I assume you mean the toc, index and the actual pages of the project like htmls, pdfs, images etc. What we do is we use a version control software called Visual Source Safe 6.0 through which we checkout the entire project then open the Prj up in RoboHelp where we edit the pages. Then we save. close RoboHelp and checkin the files and deploy the ones that were edited to the production servers. By the way our project is only viewable on our intranet site.

I can do all this editing of pages just fine. What I can not do is make changes in the intial or primary settings of the project like the Title change in the top browser tab, or the Default page change for the project through the primary Layout options in the Project tab. I can change them offline in RoboHelp and can see the changes in the generated Primary Layout but How do these changes get deployed over to the production severs since it is not a change in a typical page of the Project? What file or component of the Project carries this change? By the way the creation of these Projects occured prior to my employment and responsibilities to oversee all the projects. Can't the intial changes like the Project Title ever be changed later on or is it only created when the project is first developed?

I appreciate everyones' input and help tremendously.

thanks and I look forward to your reply

[johnmccallum]

I'm confused because you refer to an .hhp file and a server. The .hhp file is used to generate compiled help (a .chm file), which should not be deployed on a server.

If you are using WebHelp (which it sounds like, since you edit pages), you do not distribute the project file just the WebHelp files. RoboHelp generates these in a folder. And yes, you may need to distribute all of those again.

John

[Peter Grainge]

It sounds like you are editing and then just uploading the edited files. That misses out all of the internal files that RH creates and needs in the output. Not sure how you are uploading the files but it doesn't sound like you are using RH's publish option in the wizard. That is what you probably do need to do.

[MergeThis]

Peter's right, you don't seem to be using the Generate/Publish feature of RH at all. The normal process is:

1. Check out source files onto local machine.
2. Open RH project on local machine and make edits.
3. Generate output files to local machine AND Publish output files to server.
4. Check in updated source files.

There is no need to manually work on any files outside of RH; RH does it for you. There are multiple .JS and .HTM files, both in the source and in the output, that store and present things like project titles, skin appearance, and toc/index/search data.

You might want to check out the RH help (Help > Contents & Index > Single source layouts > Output types > Distributing outputs) and possibly work through a tutorial (Help > Tutorial).


Good luck,
Leon

[HTMLRobo12]

Hi again,

After looking into your suggestions, I learned that yes we are not using the Publishing option at all in RoboHelp. We are forced to use the Company standard deployment/version Control Application called Visual Source Safe 6.0. I don't know how the intial project pages first ended up on the servers without the Publish option. Since I have been employed at my place of work, I was trained to check out the project files in Visual Source Safe , edit in RoboHelp, Save, checkin, then Deploy edited pages to our Intranet servers using Visual Source Safe Web Deployment option. Basically the Visual Source Safe App is publishing for us but I can't publish or change the components that make up the projects that are part of its settings like Title etc. Is this something I need to check with RoboHelp, Vss, or my Company's standards? I heard the individuals that first setup the projects are long gone prior to my arrival. Please Advise what I should do. Btw, my company is looking to upgrade our HTML Help X5 to something more up to date , perhaps with FlashHelp, WebHelp etc. I want to help redesign all the projects from the begining without all these issues. (As a side question, is it a big jump tp go from HTML help to WebHelp?)

I appreciate all help.

[Peter Grainge]

Can you first clarify what is on the servers? What sort of help are you generating, a single CHM file or webhelp? Everything points to webhelp but you asking about switching from HTML help to WebHelp. Are you clear on the difference, sorry but I need to be sure.

[HTMLRobo12]

Hi Peter,

I see a chm file on the servers. As far as I know isn't the difference between HTML Help and Webhelp is that HTML help runs on 32-bit platforms and requires IE on the Computer. I think its really for Windoes Desktop Apps but we are using it for our Intranet. Correct me if I am wrong but is this a misuse of HTML? I think we should have had WebHElp Projects because our Help projects are published on our Intranet used by the employees. WebHelp has more options when it comes to browsers and platforms. Our Help files are standalone sites that open up through a link on our intranet. What do think would be best for our help files? I asked about this HTML to WebHelp quest because in the Prj Mgr tab you can select what type of single source primary layout we want and all our Projects are setup to HTML. So if I changed that to WebHelp as primary, will it cause any problem or is it a tedious process? I am also going to call up Adobe HelpLine but I doubt I will get the answer with regard to the Publishing option. If you can answer that question then I would be very grateful. Sorry for all the newbie, dumb question. I am trying to develop a more clear understanding about the process of publishing Help files.

thanks for support.

[Peter Grainge]

Yes it is nowadays a misuse of CHM help. See the topic on my site about CHMs not working. It is almost amusing that you have all these strict procedures in your company covering how things must be done if the death sentence is not to be passed, and then you run CHMs on a network which requires registry hacks.

The issue with switching to webhelp is that your developers will have to change all their calls to the help topics as that is done in a different way.

Why the updated CHM is not getting to the network, I really don't know. Are you sure it is the updated CHM?

[HTMLRobo12]

Thanks for the link Peter,

Well the problem seems to be that the CHM file opened from our network drive points to unavailable pages even though the project is available on the intranet.. I think the whole problem stems from how we update the project which is not the conventional way. HTML Help doesn't have the Publish option as far as I know. Now as for security risks, I don't think we can compromise any amount of security so the registry hack is out of the question. As for the WebHelp Option I guess the developers will need to be involved as you explained on your site . So its not a small change if I took it upon myself to change the layout for all the projects to webhelp. So do you think with my mgt asking for a new design or interface for our Help files will definitely require me to have the ability to change the settings files and publish them because I can't do that right now? I can only edit the html pages, toc and index. We also have projects that have various deployment paths depending on the folder the page to be updated resides. These paths are defined in our VSS app. Will this cause problems with the RH Publish option if we were to change to WebHelp, because the Publish option is linked to one deployment path (server). I really don't know much about publishing. Please explain or advice on what i should do.

thanks again for all your wonderful support!

[Peter Grainge]

I think you need to print the topic and put it before your developers and management.

Also note it is not that the pages are unavailable. Please take a second look at the topic. The page unavailable is the message that users get even though the page is in the CHM. If you downloaded that file from the intranet to your PC it would work fine.

Given the file is on your own intranet and one of the solutions will only allow a named CHM file to work, I suspect your developers and management might decide to implement the registry change. Against the work they will otherwise have to do, it is a tempting option.

What they will not get though is the appearance they want. Skinned webhelp is the answer to that.

A CHM file is generated locally by you and then the developers are doing the rest, albeit they are obviously not aware of the patch issue which is causing things not to work with the CHM. If you change to webhelp, you will generate an output that will consist of many files and you will generate that to your hard disk. Then it has to be published to the server. Either you can do that if your IT people set things up that way or your developers can do that. However, first they will need to change all the help calls.

[HTMLRobo12]

Hi Peter,

I will use your explanation when I present the issues with CHM file not working properly over networks and the solutions. I figured out that a file called "WHStart.htm" is what carries the intial webpage your users see and this is where I was able to manually change the title. I know this still doesn't help with our issue of changing the look and feel of our OLH pages unless we change the layout to WebHelp. I just thought this might be helpful for new editors like myself.

thanks again,

[Peter Grainge]

But whstart.htm is part of a webhelp output which means at least one of us is still confused. Also again you are talking about webpages which is webhelp. Yet you have also spoken about an issue which is a CHM issue.

Please send me a screenshot of what your users see when they open the help so that I can see what type of help it is or this thread could go on forever.

If it is a CHM and it displays correctly on your hard disk, the same file cannot display anything differently when it gets onto a server. If it does, then it actually is not the same file and someone is monkeying around.

Can you also please speak to whoever maintains your intranet to find out whether your users are accessing a CHM file or a whole bunch of files with many folders starting with WH?

[HTMLRobo12]

Hi Peter,

OK. Here are the facts. Apparently all our projects end with "WHStart.htm" in the address bar therefore they must be WebHelp right? However, all our projects are set to HTML Primary Layout in RoboHelp and there is no option for Publishing, server setting etc when you click on properties since HTML Help doesn't have that. They must have initially pushed out these proj onto the servers as WebHelp then changed to HTML Help (do you think it's because of the security issue?) And the date stamp on all the WHStart.htm files in the folders has not changed for over 2 years unless I manually changed something by opeing it in NotePad. Yes we do have individual folders for each topic on our local and network drive but users see the finished page as ...projectname/WHStart.htm on our intranet. We do have problems with the topic pages updating to the wrong folder but thats another issue.. Another thing I noticed was that the CHM file does update everytime we compile and update the proj, but we also have a WHStart.htm file sitting inside the WH folder. Whats your conclusion based on all this confusing information?

-

[MergeThis]

Wow! Where to start?

1. Open the destination.xpj project in Program Files\RoboHelp Office\RoboHTML\Tutorial\Destination.
2. Generate WebHelp output (already set as Primary Layout) to the default folder (\!SSL!\WebHelp\destination.htm.
(IMPORTANT! RoboHelp will actually newly create the destination.htm as its "start page," which is: a) the page that contains frameset and browser information, but none of your content; b) named by you (most applications use the browser standard "index.htm" instead of using the project's name as the default).
3. In addition to viewing the resulting output, take a look at the folder and file structure under \!SSL!\WebHelp\. The only file here with a "whstart" name is a JavaScript file created and used by RoboHelp for its output presentation. ALL of the files under this folder umbrella must be provided into the area where users will access them. IMPORTANT: The output files should never be involved with VSS at all! VSS, after all, is a Source Control product; therefore, only source files should be checked in/checked out (except for the CPD, HHP, LDB, and PSS files).
4. Now right click on "Single Source Layouts > Microsoft HTML Help" and select "Set as Primary Layout".
5. Generate HTML Help output to the default folder (\!SSL!\Microsoft_HTML_Help\destination.chm).
6. In addition to viewing the resulting output, take a look at the folder and file structure under \!SSL!\Microsoft_HTML_Help\.

Hopefully, this will give you and your people a better view of just how you're repeatedly shooting yourselves in the foot. I mean, really, you're killing yourselves with this totally unorthodox use of the product.


Good luck,
Leon

[mgud]

I hope I'm not stepping on anyone's toes by weighing in here, but I did recently change the title text of my CHM file.

If you want to change the text in the title bar of a CHM file, you need to change the window definition for that CHM file. The title of the project doesn't affect this text.

1. In the Project Manager, open up the Windows folder, and open the default window for your project.

2. In the Windows Properties dialog box, edit the Window Caption text.

This information is stored in the HHP file, and I think that is the only file that you need to distribute.

Sorry, but I don't know about your other issues.

- Maura