Flare 9 HTML5 and TocPath in page links

[gus1980_99]

I've noticed that HTML5 output in Flare 9 has longer page links due to the inclusion of "TocPath" and a number. For an example, this is a link copied from the TOC of the MadCap forums, which appear to have been built with v9:

http://kb.madcapsoftware.com/#Flare/TOC ... editor.htm%3FTocPath%3DFlare%7CTOC%20%7C_____1

Any items below such an item at the same level would end with 2, 3, and so on.

I think this addition detracts from the clean look of links in earlier HTML5 versions. Is there any way to turn this feature off?

[LTinker68]

If wonder if that was added as a way to address the problem with the TOC sync feature not working properly in HTML5 output in v8?

[gus1980_99]

If wonder if that was added as a way to address the problem with the TOC sync feature not working properly in HTML5 output in v8?

Maybe so. I skimmed through the v9 new features and the bug fixes and didn't find anything that explained this change, but that sounds like it could have been the reason.

[echopraxia]

I'm seeing this same issue, it's awful. If there is not a way to turn this off, I don't plan to upgrade from v8 to v9.

[LTinker68]

If there is not a way to turn this off, I don't plan to upgrade from v8 to v9.

Contact MadCap Support or submit a bug report at http://www.madcapsoftware.com/bugs/submit.aspx. In the meantime, WebHelp uses the tri-pane structure, so if that URL is really an issue, you can switch to doing WebHelp output.

[doc_guy]

I'm seeing this same issue, it's awful. If there is not a way to turn this off, I don't plan to upgrade from v8 to v9.

Can you help me understand why this is a show-stopper for you? This is a URL that gives your users a direct link to a specific page in the help system. It's ugly, I'll grant you, but it is a page-specific link, which is a wonderful enhancement from the Webhelp targets of Flare Versions Past. It may not be as pretty as v8 functionality, but it works, right? If you are trying to send customers a prettier link, you can always use a web URL shorterner for those pages.

[WayneC]

I've already had a couple of complaints about the extended tocpath details from internal users of our HTML5 webhelp.

I'll most likely have to rebuild using V8.

[echopraxia]

I'm seeing this same issue, it's awful. If there is not a way to turn this off, I don't plan to upgrade from v8 to v9.

Can you help me understand why this is a show-stopper for you? This is a URL that gives your users a direct link to a specific page in the help system. It's ugly, I'll grant you, but it is a page-specific link, which is a wonderful enhancement from the Webhelp targets of Flare Versions Past. It may not be as pretty as v8 functionality, but it works, right? If you are trying to send customers a prettier link, you can always use a web URL shorterner for those pages.

Sure. Part of the draw of HTML5 is the simplicity and overall advanced look and feel of the output. Appending a hideous band-aid to the URL is messy, and counter-productive. Why "update" to something which mangles the URL? I gain nothing and lose something instead. I can generate my Flare 8 HTML5 output and see the direct link to a specific page in the help system, without the mangled URL -- so I honestly don't understand the point of this "fix".

[echopraxia]

If there is not a way to turn this off, I don't plan to upgrade from v8 to v9.

Contact MadCap Support or submit a bug report at http://www.madcapsoftware.com/bugs/submit.aspx. In the meantime, WebHelp uses the tri-pane structure, so if that URL is really an issue, you can switch to doing WebHelp output.

Filing a bug now, thanks I don't see a reason to pay the extra money to upgrade to version 9 only so I can provide an output identical to that of a downgraded version 7 using WebHelp instead of HTML5. My users would also be less than pleased to see the return of the WebHelp output after all of the positive feedback that has been received from switching to HTML5.

[LTinker68]

Why "update" to something which mangles the URL? I gain nothing and lose something instead. I can generate my Flare 8 HTML5 output and see the direct link to a specific page in the help system, without the mangled URL -- so I honestly don't understand the point of this "fix".

If you have the TOC set to auto-sync, then it wasn't working in v8. Not completely or consistently. You might see it happen occasionally, but most times it didn't. I'd be on a topic and it either wouldn't be highlighted in the TOC or the last topic would still be highlighted. Having the TOC sync is more useful to the end user, IMO, than how simplified the URL looks. True, it doesn't look as elegant when sending the link in an email, but you could always insert a hyperlink in the email ("click here for more information") to obfuscate the URL.

[doc_guy]

What Lisa said

They didn't change this on a whim in Flare 9. They did it to make the highlighting and TOC sync work properly. The URLs aren't as pretty, I agree. But they do work. It seems like a purely cosmetic issue to me.

[Username_password]

What echopraxia said.

We have a working TOC navigation in flare 8 for our project so this is only negative for us.
Im trying to convince my boss not to move to 9. This is a drawback.
And prettify the url or obfuscate is only a workaround, and a bad one. Extra steps that I have to take.
Also when our users send links to eachother they have to take those steps to get a proper URL- an URL that was fine in Flare 8

[kellyb_pdx]

This is my first forum post so please excuse the question if the answer is obvious to all.

I'd like to submit feedback on this issue. Is there a way to "ping" the bug echopraxia mentions creating on April 15, 2013 or should I create a new bug?

My company purchased Flare 9 this past week (we're currently running Flare 8 with HTML5 output) and the extended URL path is unfortunately a deal breaker to switching over.

Working for a software company, I understand trying to balance improved functionality against "a purely cosmetic issue" so I ran some user tests: Flare 8 HTML5 vs Flare 9 HTML5. It was very clear that the extended Flare 9 URL detracted from, rather than added to, the user (and our Support team's) experience. Moving back to a WebHelp output is not an option.

Thanks for your help.

[figurnov]

Removing the ;K+=encodeURIComponent("?"+M+"Path="+Q) string from the MadCapAll.js script supresses TocPath in page links in Flare 9.

[LTinker68]

Is there a way to "ping" the bug echopraxia mentions creating on April 15, 2013 or should I create a new bug?

Submit your own report at http://www.madcapsoftware.com/bugs/submit.aspx. They'll add it to the other reports of the same bug, so the more who report it, the faster it'll get fixed (or become an option that can be turned on or off). In the meantime, try the workaround figurnov mentions above. Make sure you test it with the TOC sync; I'm curious to see if the original issue comes back with that code removed, or if TOC syncing continues to work.

[figurnov]

Make sure you test it with the TOC sync; I'm curious to see if the original issue comes back with that code removed, or if TOC syncing continues to work.

I use this trick for a year, no problem.

Moreover, the button "Navigate next" that does not run properly in Flare 9 with Cyrillic headings when there are several headings in one topic, after applying the trick works fine.

[3lliot]

I find that very annoying as well. I post a lot of URLs in other documentation (e.g. our website) & I don't want to have to delete the TocPath string every time I post one. The extra string obfuscates the URL and means that users are unable to quickly see from the URL where the topic sits in the context of the wider document.

I've raised it as a bug as well anyway.

[rpa]

In Flare 10, I deleted this entry in the file MadCapAll.js: ;K+=encodeURIComponent("?"+M+"Path="+Q) After the update to Flare11, I couldn't find the entry anmymore in the file and was therefor unable to delete it. And the problem is back again *argh*.

On the other hand, it seems as MadCap could solve the "problem" in their own webhelp.

Can anyone help me with this problem? Is there a new checkbox or something to avoid the long path. Or do I still have to delete something from MadCapAll.js? If so, what?

Thanks in advance for your help.

Patrick

[wellweapon]

I'm also having this problem and it is preventing me from using Flare 11 and beyond. If this fragment is not relevant it should really be possible to turn it off.

I'm told it's no longer a problem in 11 if you use the top-nav skin. However, if you're using tri-pane the problem remains and the workaround is no longer clear.

[rpa]

Has anyone found a solution for this problem?

[3lliot]

For Flare 11, delete this code:

Code: Select all

;L+=encodeURIComponent("?"+O+"Path="+T)

from MadCapAll.js

at

C:\Program Files (x86)\MadCap Software\MadCap Flare V11\Flare.app\Resources\WebHelp2\Desktop\Scripts

[wellweapon]

A belated thanks, 3lliot, this worked a treat and I am now no longer stuck on an old version.

[Rona Kwestel]

This worked for us, too, so thank you, threlliot. ; - )

For the sake of cleanliness, you might as well comment out the full line of code:

Code: Select all

/*if(L!=null&&O){var T=y(W,true);L+=encodeURIComponent("?"+O+"Path="+T)}*/

I had opened a ticket with MadCap support on this, and got the following reply:

This is due to the HTML5 help being published with HTML5 Tri-Pane output. The ability to remove these URL extensions in HTML5 Tripane is currently not supported. The purpose of the extensions on the URL are to sync where the user has navigated within the TOC.

But in fact, the fix suggested above not only removes the offending clutter in the URL, but it does not break the TOC synchronization. Obviously, if I select a topic from the TOC, the TOC pane will be synchronized because I did it manually. If I then use the forward and backward arrows to navigate to the next/previous topics, the TOC pane updates to highlight the currently viewed topic, and if I search and select a topic from the search results, the TOC pane synchronizes to the newly selected topic, opening any collapsed folders as needed.

So, I see no downside other than that you'll need to remember to redo this when Flare 12 comes out. As a matter of practice, when editing files in software packages, I save the original file with an _orig identifier, e.g. MadCapAll_orig.js. That way, it's easy to find later which files, if any, I've modified.

[Rona Kwestel]

Well, it seems that whenever you download a Flare software update, the MadCapAll.js file gets overwritten, and the commented-out code is restored, so you need to go back and re-comment it out.

[3lliot]

Yeah I just discovered that... 3 of my previously clean projects now have stupid URLs again.

*sigh*