4 Replies Latest reply on Feb 18, 2011 7:41 AM by lyddion

    RoboHelp keeps changing my web address when I Hyperlink...


      I am having a problem with RoboHelp changing my web address to an invalid page.  I am using the "Insert -> Hyperlink/Popup" option, and trying to "Link To" a Web Address.


      My website address links to an article posted on our customer database and has a format like this:




      My problem is that RoboHelp keeps changing it to this:





      It keeps omitting the " / " that is preceeding the ' # ' sign, making the link invalid.  I have tried everything to manually put the '/' back in, but RoboHelp keeps taking it out.


      According to an HTML coding site, a '#' (Pound Sign)  "is used in URLs to indicate where a fragment identifier (bookmarks/anchors in HTML) begins."


      How do I get RoboHelp to STOP taking out characters from my URL, and why is it doing this?

        • 1. Re: RoboHelp keeps changing my web address when I Hyperlink...

          I could get this to work by manually adding the "/ " that is preceeding the ' # ' sign in HTML mode. I could reproduce your issue in Design mode, however.




          1 person found this helpful
          • 2. Re: RoboHelp keeps changing my web address when I Hyperlink...
            lyddion Level 1

            Manually changing the address in "HTML" mode instead of "Design" mode works for me for now.  Thanks for the quick response! 

            • 3. Re: RoboHelp keeps changing my web address when I Hyperlink...

              I hope you will forgive me if I become overly pedantic.


              According to the official specifications, a URL is composed of 4 parts: <scheme>://<authority><path>?<query>. Perhaps oversimplifying, the <scheme> it the method of retrieving a resource (in this case http) the authority is the network location of the resource, the path is the location of the resource on the network server, and the query is any parameters that need to passed to the resource.


              In your case, "https" is the scheme, "SampleDataBaseName.com" is the authority,
              "/sfc/#version" is the path and "selectedDocumentId=06950000000Czga" is the query.


              The part of the URL that concerns us here is the <path>. This path has three important components, the path separator, the fragment identifier, and the path components. The slash ('/') is the path separator, but the fragment identifier is not just the hash mark but everything following it as well, i.e. "#version". The fragment identifier is used by the browser to find a spot in the returned document, and is not part of the request sent to the server.


              In English, your URL is telling a browser: "Find the server 'SampleDataBaseName.com'.  Using the 'https' protocol, ask that server for the document 'sfc/', and give it the data 'selectedDocumentId=06950000000Czga' when you do. When the server returns a document, find the spot indicated by 'id="version"' and begin displaying the document from that point on."


              The problem with your request, is that a web server couldn't give you the document "sfc/", because with the trailing slash it knows that you're referring to the location of a document on the server, and not one document in particular. What you might get when you request a path without a resource name varies depending on how your web server is set up. Most servers are set up so that when you request "sfc/" it will actually give you "sfc/index.html", and a "404 not Found" error if 'index.html' does not exist in that path. Sometimes the server is configured to give you a directory listing for a bare request. In your case it is probably configured to return the results of a server-side process using CGI, ASP, JSP, or something like that. But it is referencing some specific default resource and not just 'some unspecified document in the "sfc/" sub-directory.'


              In this light, RoboHelp is doing the right thing. "/#" really should not appear together because '/' means "what follows is a document or subdirectory" and #version means "find this spot in the document that was returned." What you're essentially saying is "find the 'version' tag in a document that doesn't exist." It might work in a specific instances (based on the default document setting of your web server) or on a specific web server due to its setting, but it's really not a good idea to rely on it.


              A better solution would be to find out the name of the resource or document that your web services is actually returning when a root document is requested, and include that in the URL. If the document is generate via a CGI script, that URL might look like




              If your using Java Servlets it might be




              If I were you I'd find out the name of the default document that is being returned when you ask for "sfc/" and add that to your URL. Not only would that be more consistent with web server standards, it would also make it so that RoboHelp wouldn't keep rewriting your URL in an attempt to make it "safer."

              1 person found this helpful
              • 4. Re: RoboHelp keeps changing my web address when I Hyperlink...
                lyddion Level 1

                @A25CharacterScreenName....(Nice screen name ) .  Thanks for the detailed answer.  That was EXACTLY the type of explaination I was looking for when I was searching the net for a breakdown of sections in a web address.


                My problem is 2-fold:


                1. RoboHelp is rewriting my URL

                2. My URL is generated by the 3rd party website that we use to handle our Knowledgebase and support calls.  I suppose it does this because access to the articles I am trying to link to are viewable to clients only, and only after they have logged into the site.  So what it does (when I change the URL manually in Robohelp in HTML mode) is re-direct to a login screen, and once entered, pops up the correct article I've linked to.


                For now, I can use the work-around and manually change the URL, but if RoboHelp is doing it's part and changing the URL correctly, then I guess the next step would be to take the issue up with our 3rd party site.


                Thanks again for the response!