Configure domain URL when publishing as .html

[danielabaila]

Hi all,

It's possible that this has been asked before but I don't really find anything at first glance in the documentation or help. I also appreciate that it can count as a slightly unusual question.

I'm saving all my help files as html on the same domain as my website, but in a child folder somewhere, not in the root. When I try to load one of the htmls in a tooltip for example - all the content referenced in the html file (JS, CSS, images) gets status 404 (since their paths are relative to the folder where the documentation lies).
Is there any way to add a prefix or configure a relative path variable for all the referenced content - automatically - right now I do it manually after I've generated the htmls but it's not sustainable longer term.

As an example, I now have a CSS file referenced like: <link type="text/css" href="default.css" rel="stylesheet" />
while I would need it to be referenced like: <link type="text/css" href="../../help/html/default.css" rel="stylesheet" />

Thank you,
Daniela

[Tim Green]

Hi Daniela,

When I try to load one of the htmls in a tooltip for example - all the content referenced in the html file (JS, CSS, images) gets status 404 (since their paths are relative to the folder where the documentation lies).

This doesn't make sense if what you are loading is one of the topic files from your WebHelp. It contains all the references it needs to its own CSS and JS files and those would be correct unless you physically moved the referenced files somewhere else.

Note that the correct syntax for calling WebHelp should include the index.html file, like this:

index.html?topicfile.htm#anchor

When you generate WebHelp with Help & Manual all the component files are re-generated every time you publish or update. For technical reasons they are all stored inside the same folder and this cannot change. You cannot move files like the default.css file somewhere else. It must stay inside the WebHelp folder, otherwise it will not be found. There are automatic references to it in every topic page that are created automatically when you publish. The only way to change this would be to grep the entire output every time you publish and then physically move all the referenced files to new locations. This would be time-consuming and also pointless, because WebHelp is a complete unit and does not need to be edited manually.

If you need to add your own CSS and JavaScript files and reference them in your templates they should also be stored in the main WebHelp folder. This can be achieved very easily by adding the files to the Project Files > Baggage Files section of the project or the skin. (It's better to add them to the skin if they are referenced there.)

[danielabaila]

Hi Tim,

Thank you for the reply and tips.
I'm loading the tooltip contents via angular-ui bootstrap (so not a pop-up or stand-alone window) - what this does is inject the contents of the referenced html into the DOM of each page, which means all the references inside the html get broken - as everything is now relative to the root (or current page).
So copying would be a solution but not something I'll go for. Most likely this tool was not intended to be used in such a way. Thank you again.

Kind regards,
Daniela

[Tim Green]

Hi Daniela,

The tool you are using sounds like a Frankenstein's monster. Definitely not something we would ever actively support, and we would not change even a single comma to help a tool like that. Also, scraping and injecting code from other pages like this is horribly insecure, and in many cases it is also an active copyright violation...

[danielabaila]

Hi Tim,

It's not really, angular is quite powerful and allows you to template and modularize. It's not however intended to work with entire pages, rather with html templates. It's interesting to see and try out what certain tools can do.
As for copyright it's only used in conjunction with our own internal, self-written documentation so no infringement there
What would be useful is to be able to export (and even pass back through a service) small bits of html that can be viewed independently of script or CSS imports. There are tools that do this but unfortunately we haven't yet reached the size or financial power to afford one, so it will probably come down to writing our own specific thing.

Kind regards,
Daniela

[Tim Green]

Hi Daniela,

What would be useful is to be able to export (and even pass back through a service) small bits of html that can be viewed independently of script or CSS imports.

Scripts are another issue, but if the original text is formatted with a CSS file and not with inline CSS you have a problem if you want to display the formatted text in another page. There are basically three ways to do it:

1) Theoretically you could dynamically add the CSS from the source file to the current page. However, if you do that the likelihood of borking the current page with the foreign CSS is so high that this is not really a viable option.

2) You could parse the CSS dynamically and convert it to inline formatting when you render the HTML in a local page. Very processor-intensive and likely to be slow with extensive CSS files. The likelihood of formatting errors is also high. Programming and maintenance would be expensive, at least in terms of time required.

3) You load the HTML page, or parts of it, in an iFrame. This is really the only viable solution, because then the page can load its own CSS that is separate from the host page. This is also the only solution where scripts are not a problem.

[Simon Dismore]

Two other alternatives come to mind:

Create a new HTML template with an absolute rather than relative path to the assets. Save close and re-open your project. The new template will now be available in the 'HTML Page Template' drop-down of each topic's Topic Options tab. Attach that template to each topic you want to use as an Angular partial. FYI in H&M7 the HTML templates don't actually have to be complete pages: you can create minimal ones like

Code: Select all

<!-- Placeholder for topic body. -->
<table style="width:100%;border:none;border-spacing:0px"><tr style="vertical-align:top"><td style="text-align:left;padding:5px">
<%TOPIC_TEXT%>
</td></tr></table>

if you don't mind seeing error messages when you publish. The partial will use the css of the enclosing document. As Tim says, if you decide to merge the H&M css with your website css you may need to tread carefully!

Convert your help pages to inline CSS before you move them. This is commonplace when sending bulk emails in HTML format, because many email clients strip out the <head> etc. Google "css inlining tool" for examples. If you are familiar with using node you might like to take a look at Remy Sharp's inliner (github). I haven't tried it myself yet.

To Tim's wider "Frankenstein's monster" point, there are known advantages in having the page content as an injectable file, subject to security etc. Daniela's scenario seems to be taking it only a little further, whereby parts of the page can be loaded dynamically when required. That could be very useful for popups, toggles, overlays, responsive ebooks etc.

[Tim Green]

Simon,

To Tim's wider "Frankenstein's monster" point, there are known advantages in having the page content as an injectable file, subject to security etc. Daniela's scenario seems to be taking it only a little further, whereby parts of the page can be loaded dynamically when required. That could be very useful for popups, toggles, overlays, responsive ebooks etc.

That's definitely true, of course. At the same time, there are limits where the added complexity starts to outweigh any other gains. We've experimented with this extensively for WebHelp 3, the first implementation of which is coming soon in the form of the Premium Pack 3 skins. While browsing, topic content is loaded into the existing page on the fly from compressed JSON versions. This reduces page load times from around a second or more to between 15ms and 100ms, inluding all the rendering and processing, and also eliminates the caching problem. Having the contents of toggles in additional separate files would have provided no added benefit at all if they were static (i.e. no variable content) so we decided against that. If you need dynamic content within the page it's another question, of course.

We are using the iFrame method for WebHelp field-level popups in the upcoming Premium Pack 3 skins (use simple links in your own web pages to display fully formatted popups from your help without the main help interface). The popups are stored as compressed JSON files and inserted in a simple iFrame page with the necessary CSS references, similar to your suggestion of a basic wireframe template. That was the only option, since we have no knowledge whatsoever of the pages where the links will display the popup, so injecting any CSS there was taboo, and inlining the CSS wasn't necessary to achieve the same result.