Unwanted .htm files in new project

[Karen_Little]

Hi - I create new projects from old ones because that lets me keep various things, such as cross-references between the RoboHelp generated documentation and Word's styles. I do the following:

> Rename project > delete *all* files in the project listed under HTML > close RoboHelp, then check that there are *no* html files in the project directory > begin building the new project.

Unfortunately, when I publish the project, *all* former html documents appear in the new publication's directory. My supervisor, who is a RoboHelp Supreme Expert cannot figure this out.

We cannot figure out what is drafting these former html files into the new structure - and there are a lot of them! Anyone have a clue?

Karen

[RoboColum_n_]

Hi Karen.
Was the published directory empty before you published?

[Karen_Little]

Yes, I am publishing to a 100% empty directory.

The directory that supports my project contains only the HTML pages under construction.

[Captiv8r]

Hi Karen

The thing that comes to mind here is that when you copy a project and simply delete the content, you are also copying the settings in the layouts. The thought occurs that perhaps the properties for the WebHelp start page haven't been changed. So perhaps that's where the old files are coming from when you publish.

Perhaps ensure the output folder is truly different. Then perform a double-check to ensure it's empty before generating.

Cheers... Rick

[Karen_Little]

Hummmm - I do see all the old pages in !SSL!\WebHelp.

How did they get there - and better, why? Is there someway to get rid of them?

[Captiv8r]

Hi again

Well, I would think the "How did they get there" is pretty simply answered. You copied them when you copied the project. Odds are that you just wholesale copied the folder. And that's perfectly normal! I'd be doing the same thing. But what remains a mystery is why they still existed after you cleared the content and generated with new. It's a mystery because I thought that among the first steps RoboHelp took when generating was to first clear the output folder of content. It would appear this isn't happening for some reason.

You should be able to manually delete them. That's what I'd suggest. Then generate again and see if they are still gone. They likely will be. But if not, you have further sleuthing to do to determine where they are coming from.

Once you are certain you have the correct set of source files, your next job will be to delete the inappropriate files from the server location where you published. This is because the publishing process only copies content. It will never delete content on a server.

Cheers... Rick

[Karen_Little]

Ah huh! I've had the classic "seat 'o her pants" training, and, of course, no reference book. I dimmly remember that that !SSL! directory is the actual project or something like that.

Anyway, I copied one of the project directories that gave me a problem into a new directory, then deleted its !SSL! directory. Next, I published it to a brand new test location on our server - and sure enough, all of those old files were missing, which is what I wanted.

This is not an obvious solution. Like you, I thought that changing the details of a project was all handled through the interface. Who would have though that I had to get my delicately manicured fingers dirty by pressing the delete key down at the directory level.

Thanks for pointing me in the right direction, Rick!

Maybe there is some way to do this from the interface. If you come across it, let me know.

[MergeThis]

What seems to be missing here, is the realization that RH publishes to a server only those files contained in the directory where the output was generated. Therefore, old files in the generate folder continue to be replicated to the publish folder (thereby re-populating all the files you removed).

The solution is to strip both generate (local machine) and publish (server) folders; better yet, stay out of the default !SSL! folders for generating. For our multiple-version merged projects, we go with a structure like C:\V8xxx_merge and C:\V8xxx_generate, C:\V9xxx_merge and C:\V9xxx_generate, etc. Besides the immediate visual ID inherent in this folder structure, hyperlink paths are kept more manageable.


Good luck,
Leon