Tried 'no frames' now can't get 3-frames back

[martinsirl]

Apologies if this question is a little 'peripheral' but some time ago I posted a question as the remote Apache server to which I deploy my Help & Manual Webhelp files could not cope with multiple frames due to some setting in the server configuration that, I believe, prevented index.html from displaying when the built-in necessary Javascript was run. They always looked fine on my local server which presumably has a different set-up.

I realised shortly afterwards that there is an option in Help & Manual to output Webhelp in a 'no frames' format and when I experimented with this format it seemed to solve the issue, though obviously excluding the TOC and header. I have now switched back to 'Classic 3 frames' but when I try to access these help files on my local server, which always happily displayed multiple frames before, I still see the 'no frames' version of the help files. When I publish the project the 'preview' browser window that displays the current topic shows a beautiful 3-frame page, but as soon as I access the same page from our application it's 'no frames' again!

One possibility is that something has changed in my local server set-up but before I take this up with our IT guys I would like to check that I am not missing something I should have done or checked in Help & Manual. When swapping from 3-frames to no-frames and back again is there something I need to do, or is there any known issue with the way it generates 3-frames after you have been using the 'no frames' option?

Any tips appreciated.

Martin

[Tim Green]

Hi Martin,

Did you have custom templates in your project before you made the change, or were you using a skin? If you change the mode in the Layout tab it completely deletes any custom Layout template that was there before and replaces it with the standard template for the new mode. If you then switch back to the original mode you will not get what you had before (if it was customized) but the standard template for that mode. So it's always good to make a backup copy of your original before making far-reaching changes like this.

If you are compiling with a skin and want to experiment with things like this you need to edit the .hmskin file, not the corresponding settings in the project. When you use a skin the templates in the skin replace those in the project, so changes in the project don't have any effect.

IMPORTANT: Changing the mode in a predesigned skin will probably make the skin unusable, because it is set up to use the custom code it contains in the original templates.

[martinsirl]

Thanks, Tim.

I believe I had changed the default template so this may well explain it. What confuses me is why the page displayed immediately after publishing looks exactly as I want it (including my changes) but when the pages are accessed from the application I get 'no frames'. But this may turn out to be a problem with the application or the server.

I will experiment with skins and different templates, and perhaps create a new project from scratch, and let you know how it goes.

Thanks for your prompt reply.

Martin

[martinsirl]

OK, apologies for the late update but it seems the issue here is with the hmForceRedirect variable in the HMSyncTOC Javascript function. For some reason since I changed from 'classic 3-frame' to 'no frames' and back again this is always being set to False so the pages won't redirect to index.html. I can see from looking at other topics that it is possible to manually add the line hmForceRedirect = True to the topic page template as a workaround but I can't find where to do this. I did check the 'When a topic is loaded outside the nevigation frame...' box and this is checked too.

Please can you explain how I can add this workaround (if indeed you think it is required) but please remember you are talking to an idiot so words of one syllable please! I must admit I am struggling a little with the concepts of templates and skins but I can say with reasonable certainty that in my case I am NOT using a skin and have added NO templates of my own, so assume I am using the default template. But when I look in Configuration > HTML Page Templates > Default I can't see HMSyncTOC there at all.

If the worst comes to the worst I can load all my HTML output into a web design tool (like Dreamweaver) and do a mass 'replace' - I have to do this anyway to resolve some other issues we are having with the way our application accesses the help pages so this isn't a big deal.

Thanks in advance for your guidance.

Martin

[Tim Green]

Hi Martin,

OK, apologies for the late update but it seems the issue here is with the hmForceRedirect variable in the HMSyncTOC Javascript function.

That has been changed to deal with an important change in the way that Google indexes your pages. See below for a full explanation.

The best solution in your current situation is if you mail me a copy of the skin you are using and a small demo project illustrating your project. Please mail the project and the skin to support AT ec-software.com (replace the AT with @). We don't need the graphics initially, just the .hmskin skin file and project itself in single-file .hmxz format. If you're using .hmxp you can save a single-file .hmxz copy with Save As... in the File menu. Choose the "Help Project (single file storage)" format, (.HMXZ in the description text on the right). Then just delete all the unnecessary topics in the project copy before mailing.

Changes in automatic reloads for Google

We have just turned off the automatic redirect to the main page that used to be executed when a user visited just the topic page. This new behavior has become necessary to ensure that your WebHelp pages continue to be indexed properly by Google.

Google has recently introduced some important changes that have forced us to change the way that WebHelp works. When search engines like Google link to topics in WebHelp, they always link to just the page, i.e. to "topic.htm" and not to "index.html?topic.htm". In the past, HM WebHelp would automatically reload the topic with the full user interface and table of contents when pages were linked to like this. However, Googlebot now classes these redirects as "duplicate content" and does not index the pages that do this. As a result, users found that their WebHelp was no longer indexed by Google.

To deal with this, we have turned off the automatic redirect for topics by default. Now, a link to a topic file will only open the topic file. The standard skins included with Help & Manual and the Premium Pack skins all automatically display a "Click to Display Table of Contents" link at the top of the topic when this happens. The user can then click on this manually to redisplay the topic with the full user interface.

IMPORTANT: Any external links to your WebHelp and links to WebHelp from your applications should now *always* use the full "index.html?topic.htm" syntax to ensure that they open with the full user interface. This was actually always important, because the user's browser history does not work properly when you use the redirect links.

If having your WebHelp indexed by Google is important to you, you should not re-activate the automatic redirects. If you don't care whether Google indexes your site (for example if it is only used by users who know where it is), you can reactivate the redirects and return to the old behavior: Open your project (if you are not using a skin) or the .hmskin skin file (if you are using a skin) in Help & Manual. Then in the Project Explorer on the left go to Configuration > Publishing Options > WebHelp > Navigation. Locate the option "When a topic is loaded outside the navigation frame, force it to reload the navigation frame" and turn it ON.

To get the new standard skins with the "Click to Display Table of Contents" link when a topic is opened on its own you just need to update to the current version of Help & Manual 6, which you can download here:

http://www.helpandmanual.com/downloads.html

Just install on top of your current copy of Help & Manual 6 to update. You can then find the new standard skins in the /Templates/HTML Skins folder in the Help & Manual program directory.

If you are using a Premium Pack skin you can get the new version by downloading the current version of the Premium Pack installer with the download link and installation password you received when you purchased the Premium Pack. If you no longer have this information just send us a mail and we will help you out.

[martinsirl]

Thanks, Tim, for your very thorough response. The support service you guys offer is top notch!

It seems the 'When a topic is loaded outside' tick box is already checked, but today something strange happened: our IT Support guys swapped my old Windows XP PC for a new one running Windows 7 and the compiled Webhelp HTML files now correctly redirect even when called directly, which is exactly what I wanted. So thanks you to your sound advice and a little good luck I am slowly getting to where I need to be.

The point you make about pages having to be called with the full "index.html?topic.htm" syntax is in an interesting one as most of the problems I have experienced so far stem from the fact that our application simply doesn't do this. Our application runs on an Apache server hosted on an IBM iSeries machine and stringent security settings prevent users from accessing the help pages directly. Instead our application includes a 'help text retrieval' program which is called passing topic.htm (actual topic ID) as a parameter and "streams" the content of the page back to the user's browser. So you can see that I am stuck between the customer who are security-paranoid and our developers who simply refuse to modify our application to handle what I consider to be the industry standard for on-line help. I now have a new issue with the default.css stylesheet not being respected which I suspect is caused by the same streaming problem, but that particular issue can wait for another day so no need for you to respond.

Thanks again.

Martin

[Tim Green]

Hi Martin,

Instead our application includes a 'help text retrieval' program which is called passing topic.htm (actual topic ID) as a parameter and "streams" the content of the page back to the user's browser.

That could cause all kinds of problems, because WebHelp expects to be displayed in a browser with full interactive access to the site's pages. Since it can consist of hundreds or even thousands of topics it needs to be browsable within the page, which means that components of the page, like the table of contents, index and search form, need to be loaded dynamically into iFrames to make everything accessible enough.

[martinsirl]

Yes, at the moment it seems to be hanging together reasonably well but I agree, it's not at all desirable. As I understand it the first page retrieval is 'streamed' but all subsequent calls from hyperlinks within the page(s) are simple HTML calls so most things should work...I think.

I'm told we stream the first page because typically Apache servers running on IBM iSeries boxes are configured to prevent any direct access to HTML pages in the iSeries IFS (Integrated File System) so I am hoping I can persuade the customer to allow this in this instance or, failing that, I will need to use the 'no frames' Webhelp pages which stream more happily.

Neither is a perfect solution so if any other help authors have had a similar experience I would love to hear from them. It's not a Help & Manual issue as any tool would, I guess, generate the same type of pages.

Martin