We recently upgraded from Robohelp 2015 to Robohelp 2017. We have a large help project that has over 1000 topics and our software applications calls help topics by generating a URL with the Responsive HTML5 Help path and the appropriate Map ID for the topic. The application also adds arguments to the URL to specify the appropriate content filters. All of this was working fine in Robohelp 2015 (except for the defect that Multi-Level lists don't number correctly).
After upgrading to Robohelp 2017, calls to open topics do not work the way they should. The framed layout should open and display the correct topic with the correct filters, but instead it only opens the (correct) topic but without the framed layout and without any filtering. To confirm that this is a problem, I copied the exact same project file set to two computers, one with Robohelp 2015 and one with Robohelp 2017. I used the same settings to generate the Responsive HTML5 output on each and then I then used the same URL to call a topic. Here are the results:
Has anyone else encountered this? Is there a workaround? This is a critical issue for us and we can't wait for Adobe to put it into their backlog and not address it as they typically do. We might have to cancel our Tech Com Suite subscription and go back to Robohelp 2015.
First, have you applied the patches & regenerated the content? There was some flipping back & forth in another thread about the CSH call including the left pane and without it (as your screenshot shows). I think the way it was showing with the pane was a bug; it should have been launching straight to the topic; Google searches had something to do with it IIRC...
We're actually launching the index.htm (or the equivalent as we renamed it) every time and selecting the topic via Map ID. I use the methods described here: https://www.wvanweelden.eu/articles/context-sensitivity-responsive-and-multiscreen-html5
Also, see Item 4 in Snippets HTML5 on my site where there is some further information.
The change actually started in RoboHelp 2015 so I am thinking maybe you didn't install Update 4. The change was for the benefit of users who want there output searched by Google. My own view is that is far from the majority of users so there should be an on/off switch.
Please follow this link to report bugs and request features. The more people who do so, the higher it gets prioritised.
Post the link to your submission in this thread and others can vote for it.
See www.grainge.org for RoboHelp and Authoring information
There's some good information there. Thanks. But what's supposed to happen if you include the filtering arguments? Is it still supposed to filter the content, or did they effectively kill that feature?
Not sure on that. I'll see what I can find out.
Thinking some more, I think filtering should still work. If you find
otherwise, I will take it with Adobe.
If the left pane is being suppressed & you want filtering, I don't think there's anyway to turn it on unless you click a "Show" link to expose the control in the "full" help.
Filtering does not work. It just shows everything. The icon at the top left is also broken, though it's fine in the framed version.
I tried adding a master page with the script to show the frames. That's a decent workaround except that it doesn't retain the filtering criteria from the URL. I'm pretty sure we're using it correctly. It's been working in past versions just fine. We have a lot of topics that are split with tagged information for specific applications. The applications are supposed to set the filter criteria automatically so that the correct information displays when a User clicks the Help button.
I'll see if I can get some more information. Likely not until next week.
I tried the filter with a sample project and it gets applied correctly in the output. Is it the combination of CSH and a filter that is broken only?
Ok. So I did a lot more testing this morning to see if I was going crazy. After adding in the script in the master page to open the layout, I'm finding different behavior when I call the topic on my local machine versus when I put the files on a web server. When I access the topic locally in Internet Explorer with the proper CSH arguments, it does not set the filter correctly. However, when I put the files on a web server and use the exact same arguments, it does seem to apply the filter. This is a change in behavior from before. Some of our applications access the Help locally and some from a Web Server. I just attached newly generated Help files to one of our applications that calls the Help files locally and it does not set the filter correctly. However, if I place the same set of files on a web server and use the same CSH arguments, it sets the filters. To make sure that the local files worked before, I regenerated the project in Robohelp 2015 with different default filters and then copied the generated files to our application and had it call a topic locally. The filters were applied correctly, so this feature seems to have broken in Update 4 or Robohelp 2017. It works in the version of Robohelp 2015 that we have installed. So this is still a problem for us where our applications call the topics from the hard drive.
Since you get different behaviour, I think this would classify as a bug. Did you already create a bug report with Adobe? If so, please add your additional findings there. If you share the link to the bug, others can vote for it too in the hope that Adobe will give it more priority.
Yes. Robohelp 2017 is up to date. We prefer that it launch with the left pane, but even if it doesn't it should include the filter criteria. I'm not sure if it can filter without the other pane, but as of now it doesn't seem to filter anything at all. I've also noticed buggy behavior in the filter pane when launching from the index topic. The filter groups controlling the wrong filter criteria... the whole thing seems very, very buggy.