• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Why does RoboHelp 8.0.2 randomly insert javascript into all WebHelp topics?

Guest
Mar 02, 2011 Mar 02, 2011

Copy link to clipboard

Copied

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):
js_error.PNG
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?

Views

2.7K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Mar 02, 2011 Mar 02, 2011

Copy link to clipboard

Copied

Hi and welcome to the forums.

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?)

Let us know and we'll try to help.

John Daigle
Adobe Certified RoboHelp and Captivate Instructor
Evergreen, Colorado
www.showmethedemo.com

John Daigle
Adobe Certified RoboHelp and Captivate Instructor
Newport, Oregon

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Mar 02, 2011 Mar 02, 2011

Copy link to clipboard

Copied

Hi John

Thanks for the quick response.

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)?

(I am the only writer working on this project.)

-chris

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Mar 02, 2011 Mar 02, 2011

Copy link to clipboard

Copied

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.

Thanks

John Daigle
Adobe Certified RoboHelp and Captivate Instructor
Evergreen, Colorado
www.showmethedemo.com

John Daigle
Adobe Certified RoboHelp and Captivate Instructor
Newport, Oregon

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Mar 02, 2011 Mar 02, 2011

Copy link to clipboard

Copied

Hi Chris

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.

Cheers... Rick

Helpful and Handy Links

RoboHelp Wish Form/Bug Reporting Form

Begin learning RoboHelp HTML 7, 8 or 9 within the day!

Adobe Certified RoboHelp HTML Training

SorcerStone Blog

RoboHelp eBooks

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Mar 02, 2011 Mar 02, 2011

Copy link to clipboard

Copied

Excellent point, Rick and absolutely worth checking.

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.

Thanks for pointing this out!
john

John Daigle
Adobe Certified RoboHelp and Captivate Instructor
Newport, Oregon

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Mar 03, 2011 Mar 03, 2011

Copy link to clipboard

Copied

Hi John & Rick

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.

Thank you
-chris

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Mar 03, 2011 Mar 03, 2011

Copy link to clipboard

Copied

Chris, there is no serious bug...seriously.

Source files:

  • Can be assigned to source control.
  • Contain only enough code to let RH know what to do when generating output (such as rh-cbt for conditional tags, <?rh-placeholder type="breadcrumbs" for breadcrumbs, etc.).
  • Cannot deal wtith output files that have already been generated.

Output files:

  • Should not be assigned to source control (there's no point, because they can always be reproduced from source).
  • Will contain enough JavaScript and additional HTML code to allow all browsers to display your content as intended.
  • Will also contain three wh*data folders with assorted HTM and XML files to provide the data for the navigation pane (TOC, Index, etc.).

Generating output:

  • Must be generated to your local machine.
  • The start page is prepared by RH as a "launch pad" to create the frames necessary to display your help.
  • Can be targeted to any folder (we don't follow the default !SSL path, either).

Publishing output:

Simply transfers the generated output on your machine to any number of server locations (unless you select Republish All, it will only update the changed files).

If you find JavaScript offensive, you might want to avoid the web.

Good luck,

Leon

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Mar 03, 2011 Mar 03, 2011

Copy link to clipboard

Copied

MergeThis wrote:

...Output files:
  • 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.

Like any tool, actual usage actually depends on the task at hand.

Cheers... Rick

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Mar 03, 2011 Mar 03, 2011

Copy link to clipboard

Copied

Regularly scheduled, date-time stamped, synchronization of output files to a server with regularly scheduled backups is, to me, the more logical choice.

Besides which, if both source and output files are being source controlled, there's too much likelihood of mixing them up (as seems to have happened to the initial poster).

Most of these decisions are organization-driven, anyway, so the writer is usually is the one player with the least input!

Good luck,

Leon

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Mar 06, 2011 Mar 06, 2011

Copy link to clipboard

Copied

but when I recompiled, RH placed the javascript back in

My 2c.

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.)

Amebr

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Mar 03, 2011 Mar 03, 2011

Copy link to clipboard

Copied

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)?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Mar 03, 2011 Mar 03, 2011

Copy link to clipboard

Copied

"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!

Boy, do I need a drink...

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Mar 04, 2011 Mar 04, 2011

Copy link to clipboard

Copied

In the case of the project in question, the help files were on the local hard drive.

The output files were never copied or imported into the source files.

What I've written about is a bug... what Adobe does with this is another question.

(no need to comment Merge This)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Mar 04, 2011 Mar 04, 2011

Copy link to clipboard

Copied

Sorry, just can't help myself!

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.

BTW, we're not Adobe employees; we're RH users.

Good luck,

Leon

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Mar 04, 2011 Mar 04, 2011

Copy link to clipboard

Copied

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.

So does that mean that your project is working OK now?

john

John Daigle
Adobe Certified RoboHelp and Captivate Instructor
Newport, Oregon

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Mar 04, 2011 Mar 04, 2011

Copy link to clipboard

Copied

Hi John

Thanks for asking and the respectful response.

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.

Before:

d:\source files

d:\source files\SSL\WebHelp

Now:

d:\source files

d:\Test

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Advisor ,
Mar 04, 2011 Mar 04, 2011

Copy link to clipboard

Copied

{self-censoring}

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
May 01, 2012 May 01, 2012

Copy link to clipboard

Copied

LATEST

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!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
RoboHelp Documentation
Download Adobe RoboHelp