How to get page URL of a topic with tri-pane navigation

[Rona Kwestel]

As part of our effort to elicit per-page feedback from our users, we have added a feedback button to the master page, the script behind which gets and passes the page URL to the server-side script that pops up a feedback form and sends an email message back to us with the content of that form.

We initially tried using document.URL to get the current page URL, but found that instead of returning this: http://kb.mycompany.com/#KB/How_to_Use_the_KB.htm, which is the actual page URL and includes the skin, it returns this: http://kb.mycompany.com/Content/KB/How_ ... the_KB.htm, which brings up just the topic frame without the skin, so you lose all of the search and navigation features.

After some research on other options, I tried window.location.href and window.location, but both returned the same thing as document.URL. Any idea how to grab the URL that actually appears in the browser address bar?

[jjw]

How about using "window.top.location.href"? Works for me.

[Rona Kwestel]

Thanks, jjw, but while that seems to have picked up the correct URL, as shown below, it broke the MadCap dropdown feature on that page, where all items were expanded and not collapsible, and the display of the dropdown header was completely munged up.

Code: Select all

http://kb.mycompany.com/feedback/Feedback.aspx?referrerurl=http://kb.mycompany.com/#KB/How_to_Use_the_KB.htm&artnum=

DropdownText.png

Moreover, we use the following code to pick up the last part of the referrer URL to display the article name in the email message if there is no article number, which is the case in this example, but it now comes up blank in the email, whereas it worked before when we were using document.URL. I'm guessing that it may have something to do with the '#' character in the URL, but I'm not sure why.

Code: Select all

               var ReferrerURL = Request["referrerurl"];
                var PageURL = ReferrerURL.Split('/').Last();
                var ArtNum = "";
                try { ArtNum = Request["artnum"]; }
                catch { }
                var ArticleID = (ArtNum == "") ? PageURL : ArtNum;

[Rona Kwestel]

What I don't understand is why that script code should interact with the display of the page at all, as it should only be invoked if/when the user clicks on the feedback button.

I tested it in IE instead of Chrome, and the dropdown text issues didn't occur at all - very curious - but the parsing of the last part of the URL was still a problem and the article reference in the email comes up blank. I tested it with another article that does have an article number, i.e. artnum=391, and it still comes up blank in the email.

I think we may just have to live with the skinless link in the feedback emails, as they're only seen internally, and the few people that receive/review them will just have to know to replace "Content/" with "#" in the browser address bar if they want to get the article back in the context of the skin/TOC.

[Rona Kwestel]

According to the answer by meder on this topic: http://stackoverflow.com/questions/3332 ... ation-href, there is a difference between window.location.href and top.location.href.

When I try the latter, it picks up the correct URL and it has no deleterious effect on the dropdown text, but the problem of passing that URL with the '#' sign in it through to the email remains. If we can resolve that, we'll be in good shape. Otherwise, we'll have to go back to using document.URL and live with the frame-only URL.

[NorthEast]

In a output using a tripane skin, the pages are in frames. The top-level file is Default.htm which defines the frameset, and inside this the frames display content from separate files - the header, side navigation, and your topic.

So that means if you get the window.location from the topic, you get the topic file's URL.
But the URL displayed in your browser is for the top-level file Default.htm, so to get that URL you need to use the top.location.

The /#KB/ part of your URL looks odd to me, it's not how you normally construct a CSH URL.

[Rona Kwestel]

The /#KB/ part of your URL looks odd to me, it's not how you normally construct a CSH URL.

But as far as I know, I'm not telling Flare how to construct the URLs; it does it all by itself. The structure of our project is Content/KB/<various subsections>. We're publishing HTML5 output with a skin and a TOC. I'm not sure what "Prevent external URLs from frames" means on the Advanced tab of the Target Editor, but we have it unchecked.

[jjw]

Is there any other way to pick up parameters that appear after the hash? From location.hash maybe? Or does that strip out those parameters too?

[Rona Kwestel]

top.location.hash results in the following URL:

Code: Select all

#KB/How_to_Use_the_KB.htm

So we lose the server name and still have the problem of the email having no link at all.

Somehow I suspect that this is not an entirely solvable problem, or would require quite a bit of code wrangling, and I'm not sure it's worth the effort at this point. But if anyone does know of a solution, I'm still willing to fiddle with it. Thanks.

[Rona Kwestel]

I just discovered another aspect to this issue. If you do a Google search to find content in your Flare output, the link takes you to the topic content only, without the tri-pane view. So, instead of http://MyCompany.com/#/KB/MyTopic.htm, it links to http://MyCompany.com/Content/KB/MyTopic.htm. Users would have no way of knowing how to restore the tri-pane view by replacing the word "Content" with "#", and hence will have no way to discover the rest of the articles/topics in your KB/help from this page.

[MattyQ]

Users would have no way of knowing how to restore the tri-pane view by replacing the word "Content" with "#", and hence will have no way to discover the rest of the articles/topics in your KB/help from this page.

In your Target settings, you can specify for Flare to automatically add a link to the top of every page. This link allows the user to refresh the page, and redisplays the skin. To note, this link only appears if you view the page outside the skin. It is not otherwise visible.

[NorthEast]

Users would have no way of knowing how to restore the tri-pane view by replacing the word "Content" with "#", and hence will have no way to discover the rest of the articles/topics in your KB/help from this page.

In your Target settings, you can specify for Flare to automatically add a link to the top of every page. This link allows the user to refresh the page, and redisplays the skin. To note, this link only appears if you view the page outside the skin. It is not otherwise visible.

If you want to open your topic inside the skin automatically, I wrote a blog post which shows how to do this using a script:
https://ukauthor.wordpress.com/2014/08/13/automatically-open-topics-with-navigation-skin/

[Rona Kwestel]

Thanks so much, Dave; that did the trick.

Is there any reason not to put the script directly in the master page rather than link to a separate script file? I embedded the script as follows, and I don't see any issues, but wanted to be sure:

Code: Select all

	<!-- The following script detects if the navigation link is visible at the top fo teh topic; if so, it redisplays the page with the navigation page. -->
        <p>
           <script type="text/javascript">/*<![CDATA[*/$(document).ready(function () {
             if (($('.MCWebHelpFramesetLink:visible').length))
             {
               window.top.location = $('.MCWebHelpFramesetLink>a').attr('href');
             }
           });/*]]>*/</script>
        </p>

[NorthEast]

No, but it's just generally better practice to keep the scripts in a js file, rather than embedding a separate instance each time.
It's a bit like embedding your styles in every topic, as opposed to linking to a CSS file.

[Rona Kwestel]

Got it, Dave. Thanks again, as always.