Breadcrumb path displays Content Explorer file location?

[techwriter31]

Hi all,

We've noticed a problem with some of the breadcrumb proxy paths in our help file. According to the Flare 8 help:

If a breadcrumbs proxy is included in a master page, the output will display a "trail of breadcrumbs" composed of the table of contents (TOC) entries above the current topic in the TOC hierarchy.

But we've found that if we have a single topic that has more than one TOC entry, the breadcrumbs path displays the actual Content Explorer folder location for the topic, rather than the TOC entries above it.

For example, say we have an "Emergency License" topic that resides within the "Troubleshooting" folder in Content Explorer. But when creating the TOC, we create two entries for this topic, one under the "Setup" TOC entry book, and one under the "Troubleshooting" TOC entry book:

- Setup
---> Install the Software
---> Configure the Software
---> Emergency LIcenses

- Troubleshooting
---> Emergency Licenses

When you open the topic in the generated help file, the breadcrumbs proxy in both topics displays "Troubleshooting > Emergency License" (rather than "Setup > Emergency License" and "Troubleshooting > Emergency License"). Our workaround at the moment is to create two separate topics that reside in the relevant locations in the Content Explorer, create a snippet of the topic content and insert the snippet into the two topics. But this seems redundant even if we are able to single-source the content via the snippet.

[crdmerge]

Use a redirect topic for your other TOC location(s).

Create a New topic, make it blank, and add this line in the HEAD section of the code:

Code: Select all

<meta http-equiv="refresh" content="0;URL=<path>/original_topic.htm" /><title>Original Topic Title</title>

"path" would be used for folders or a merged project.
content="0; indicates no delay in redirecting (user sees nothing but the original topic being displayed).


Good luck,
Leon

[LTinker68]

Our workaround at the moment is to create two separate topics that reside in the relevant locations in the Content Explorer, create a snippet of the topic content and insert the snippet into the two topics. But this seems redundant even if we are able to single-source the content via the snippet.

That's what we users generally recommend you do. Although I'd go a step further and mark one of those topics as not being searchable so your users don't get two identical topics returned when they do searches.

The reason Flare behaves as it does is because when the output is generated, the breadcrumb trail is written into the topic file -- it's not dynamic -- so it can't change depending on which TOC entry you click on. You could perhaps put in a feature request asking for the breadcrumb trail be dynamic relative to the TOC entry, but that would require client-side scripting, which could be disabled by the user or by the user's corporate policies, so there's a chance the breadcrumb trail wouldn't work at all. At least by having the breadcrumb trail hard-coded into the topic file it will work for all users.

[techwriter31]

Thanks for your responses!

[MarinaMichaels]

How does this work with indexing? I thought I read something about how to prevent the indexing in the snippet from being picked up multiple times.

[GinnyR]

@Marina: For the indexing, you can put the index entries in the topic heading, outside of the snippet.
Or you can use snippet conditions on the index entries inside the snippet to exclude them from some of the topics that use that snippet.

[MarinaMichaels]

Thanks, Ginny! The first solution is perfect.

[MarinaMichaels]

I've been implementing snippets for the past week or so and love them. Way cool! However, although the process is working for the materials I am inputting now (different tutorials with lots of shared information), the idea of having index entries outside the snippets won't work in many cases. This is because our help has many tables of parameters (names, values, and meanings). Some of those tables apply to more than one set of topics; of course, rather than create copies of each table, I just have multiple TOC entries pointing to the same table. All fine and good.

However, the index entries for each parameter are in the table cell for that parameter. I did this instead of placing the index entries at the top of the table because

(a) for the longer tables, I wanted people to click on the index link and be taken directly to the row with that parameter's information in it;
(b) when I was creating the index entries, it was much easier to see which parameters I had indexed already (because I could see the entries right there next to the parameter name); and
(c) some of the table rows are hidden for now until we implement those parameters; it was easier to just apply a condition to an entire row (including the index entries for that row) than try to apply conditions within a set of clustered index entries.

Given that I am not going to re-do over a thousand index entries, is there a way to mark an entire topic so that the index entries in that topic aren't looked at (similar to marking a topic so it isn't searchable)?

Thanks!