RH can randomly insert javascript into your project (can be in the <head> tag or <body> tag in all topics in the project) which evidences itself with red boxes in the editing pane, and duplicate breadcrumb links in the WebHelp output. Even if you clear the Add Breadcrumbs Links checkbox while setting your project's properties, you will still have some breadcrumbs in various topics (RH randomly assigns breadcrumbs to topics with no logic that I can see). After deleting all instances of the red boxes, RH inserted javascript again in the next compile.

When you click the HTML tab you will see something similar to the following (the javascript has been highlighted):

I was able to recover to a previous version (without RH's random destruction) b/c I used SVN, but I now have zero confidence in RH's stability. I definitely did not insert the above javascript into my project. I kept the default setting for the compiled help to go to the subfolder of the help system (i.e., !SSL!, WebHelp). Does anyone know why this happened?

I can understand your frustration. Let me see if I can sort this out. Somehow it looks like you have imported "Output" files from the !SSL! folder into your RoboHelp project's "Source" files.

Here's why.

When you generate the output to the SSL folder, RoboHelp adds legitimate and proper Javascript code to those files in order to do things like detect which browser the end user is using and many other good reasons. However, while fine for the SSL Output, the code doesn't make sense and becomes garbled if you mistakenly import these files back into a project.

Breadcrumbs code is in the output files and that appears to be why they are still showing up even if you turn breadcrumbs off. I can see where this would be frustrating. The answer is not to import or bring SSL output files into your project source.

I'm not sure how this happened. (Is this a project worked on by others on your team?) I don't know much about SVN, but I wonder if you opened something incorrectly from SVN? In the future make sure you do not open or check out anything in the SSL folder. In fact, veterans of source control tell me the best practice is never to add the SSL folder to source control in the first place. Normally, only source files should go in source control.

To get back on track, is there some way you could go to SVN and open a version of the project just before this corruption occured? Make certain you don't grab any output SSL files in the mix? This should help resolve the problem (unless there's something else going on?)

I initially had the SSL folder under version control when the files were first put into SVN. This happened by default when the source files were brought under version control, as the SSL folder is a subfolder of the main branch. However, the SSL folder and WebHelp subfolder were excluded from version control (added to an ignore list) prior to me encountering this error.

I have been able to recover from the corrupted files by going back a few versions. SVN has an excellent "compare" feature, so you can see differences clearly. For now, I've created a Test folder at the same hierarchical level as the source files for the compiled help. This folder has never been under version control, so hopefully the compiled help won't be corrupted. Do you think this is the safest policy (i.e., don't use the default SSL subfolder as it is a child folder)?

Glad you're making progress! I am only an occasional user of source control but that sounds like a great strategy to me. There is no magic in generating to the !SSL! folder. It could be anywhere on your hard drive. In fact, because it is output, some people even publish to a share drive where the web admin picks it up and places it on the web server. You can adjust the path on the first screen of the SSL wizard. Since we seemed to have narrowed this down to a source control issue, you might take a look over on the Source Control sub-forum. There might be some best practices over there by the power users.

Not meaning to tread on my fellow Community Expert's toes here but hopefully he won't mind my adding a couple of tidbits.

First: (and this is my own observation) Being the lone writer, isn't source control just a wee bit of overkill?

Second: As for randomly inserted JavaScript, things are seldom random.

I see that you and John are discussing source control as a possible issue. Personally, I think that's a red herring. Here's why. What I *DON'T* see mentioned here (unless I missed it - and I could have) is that most usually the culprit for WebHelp output files with JavaScript replacing your source files is caused by incorrectly specifying the Publish destination. I can't tell you the number of times I've witnessed folks doing exactly this.

The bottom line is that you need to click the Next > button until you reach the final dialog of the WebHelp Single Source Layout settings and scrutinize what you have configured as the Publishing destination. If you have nothing configured there your problem will be elsewhere. But if it's configured where you finish the generation process and you click a "Publish" button, chances are very good that this is where the issue will be found.

Again, apologies if you already talked about this and I missed reading it.

I guess I made a grand leap that Chris wasn't publishing to his source (a recipe for disaster!) because he said he was publishing to the default !SSL! WebHelp folder. But, you're right, something may have hiccuped at some other time in the past that munged things up in the way you describe.

I checked my Single Source Layout settings all the way through (by clicking the Next button till I reached the final screen). The only place that I saw that specified a publish destination was on the first screen in the Select Output Folder and Start Page field. This has always been separate from the source files folder. At first the publish destination was a child folder (i.e., source files\!SSL!\WebHelp) and now it is Test (at the same level as the source files, and not a child folder). This new Test folder has never been under version control, and never will be. I just want to confirm that compiling help to the default \!SSL\WebHelp folder structure is the cause of my problems.

While it may seem that using source control is overkill for a lone writer, in fact, SVN saved my bacon. After the javascript had been inserted into all the topics, I had no idea (and still don't) how to remove the javascript using RH. I tried manually removing the red boxes topic-by-topic, but when I recompiled, RH placed the javascript back in (but in a random collection of topics with no rhyme or reason as far as I could see). I also unchecked the Breadcrumbs option in the WebHelp Single Source settings, but that didn't solve the problem either. The only way I could proceed was to revert to a previous version via SVN, which hadn't been defiled with the javascript insertion.

In my opinon, this is a serious bug. However, if there is a workaround that you know of, please let me know.

Should not be assigned to source control (there's no point, because they can always be reproduced from source).

Hey Leon, Overall I generally agree with your points.

However, I've seen a few folks report back saying that this is actually desired. In these odd cases they were managing a policies and procedures system. Source control provided them the ability to look at a snapshot of what the policy or procedure was at a given moment in time. In these cases all you would get from the source was the latest version.

I just want to make it clear that the default output folder of \SSL\WebHelp was under version control for all of about 10 minutes when all the files were brought into SVN. The output folder was excluded from version control once all source files were taken care of. This procedure was accomplished months ago, and the javascript error reared its ugly head twice about a week ago. If this isn't a bug, then what is?

(and I made no comments about trying to avoid javascript.)

Does Adobe recommend that the compiled help files be output to a local hard drive (instead of a networked drive)?

Perhaps the default build folder of SSL\WebHelp should be changed to another path (i.e., on the same hierarchical level as the source files)?

"Does Adobe recommend that the compiled (Note: Actually, WebHelp is generated, not compiled) help files be output to a local hard drive (instead of a networked drive)?"

YES, IT'S WHAT WE'VE SAID HERE, AND WHAT RH SAYS IN ITS HELP

"Perhaps the default build folder of SSL\WebHelp should be changed to another path (i.e., on the same hierarchical level as the source files)?"

NOT NECESSARY, BUT IT'S YOUR CALL

Look, we're only trying to get you to understand that if you open an output file in RoboHelp that you've copied/imported into the source project, you'll see little red boxes. This is pilot error (yours), not a bug. Output files belong in the output folder ONLY, period, end of discussion!

I just took another look at the screenshot in your initial post and...wait for it...IT'S AN OUTPUT FILE! You can insist all you want about a RoboHelp bug that randomly inserts this JavaScript, but you're dead wrong. RH only inserts this stuff into the output versions of the files when you choose to generate output.

So, the only explanation is this: there are gremlins in your organization who delight in moving files where they don't belong.

I hesitate to get back into this fray but I have to satisfy my curiosity.

My first paragraph of my first post observed that the screenshot was of Output. Because Chris mentioned that he was observing this from the "HTML tab" that suggested to me that somehow an output file had been imported into a project. Or, a symptom of Rick's suspicion that the project was generated to the source folder. Or, that something got out of sorts in the source control workflow (as Leon has often warned over in the source control forums).

Meanwhile, not to be argumentative (dont' hit!) I agree with Leon that this is not a bug, but more a glitch that occured in the workflow which resulted in the commingling of output and source files.

Chris, for a moment never mind if it is a bug or not. I'm unclear about what your status is now?

In post #6 of this thread you mention that you reverted to a clean version from SVN.

While I observed the javascript problem on the HTML tab while in RH, the screenshot was actually from SVN's compare functionality. Sorry if there was any confusion.

I've reverted to a clean version of the help system, and am now using a different folder to compile the help to. Yes, it seems that there was some commingling between the source files and compiled files, so I'm now using the following dir structure. (Test represents the compiled files.) I am hopeful that this solves the problem. I plan to use a similar dir structure for my other help projects so that this problem doesn't resurface.

Because the red boxes reappeared after compiling, it really does sound like the Output folder somehow got changed. Reverting to an older project version from SVN would have restored the ssl definition with the correct path. How and why it changed is a question for the ages - sunspots maybe.

In any case, if it happens again, checking the Output folder would be my first step - I find copy/paste to notepad really good for this sort of thing as it's easy to take the path for granted rather than actually reading the entire thing (if I had a dollar for every time I did that myself...).

Also, having the output path different from the source path makes in easy to spot if it's been changed to the source incorrectly. (Yes, I've done this myself, thank goodness it was a chm, not webhelp.)

I'm not sure if this is the same issue, but it sounds close enough that I'd like to post it here...

Issue

I was either getting topic breadcrumbs in all of my topics (when they shouldn't have been), or getting "double" breadcrumbs (one stacked on top of the other) when I only should have had one breadcrumb. However, I didn't want any!

Background

By the time I had inherited this RH project (WebHelp), it had been worked on by at least three people over five years, using older (pre-9.0) versions of RH. I had just loaded RH ver. 9 when I took it over.

Solution

I noticed that there was a "breadcrumb" placeholder in the master page (xxxxx.htt) of the project. In the Single Source tab, when I right-clicked on WebHelp (Primary Output), and did not check the "Add breadcrumbs links" under the Navigation pane, I only saw one breadcrumb link in my generated output. When I checked the "Add breadcrumbs links", I saw two breadcrumb links in my generated output. When I deleted the "breadcrumb" placeholder in the master page (xxxxx.htt) of the project and did not check the "Add breadcrumbs links" under the Navigation pane in the WebHelp (Primary Output), then I finally saw no breadcrumbs in my generated output. Likewise, when the "Add breadcrumbs links" was checked, one breadcrumb was generated in the topic.

Lessons Learned

I suspect that either an earlier version of RH did not have this "Add breadcrumbs links" under the Navigation pane when you generated output (which mean that an earlier RH author had to use the breadcrumbs via the "placeholder" feature on the master page), or someone just didn't know how to implement the "breadcrumbs" feature correctly. In either case, I'm a little wiser from all of this!