2017 R2 broke all of my TOCs

[lanval]

I installed the new R2 release today, and it broke all of my TOCs. I had set them up to use the first Heading of each file. R2 is using random text in the files.

I've tried the following entries in Label field:
[%=Heading.AnyLevel%]
[%=System.LinkedTitle%]
[%=System.LinkedHeader%]

Is anyone else having the same issue?

[Nita Beck]

Yes, I am seeing this, too, in one of my project and haven't yet looked at others. We use the System.LinkedTitle variable. Some but not all of the TOC items are exhibiting the problem. At first glance, I don't see the pattern yet. In HTML5 Tripane output, the TOC headings in the Contents resolve correctly, as do the breadcrumbs, and (at first glance) as do xrefs. In PDF output, headings in the generated table of contents resolve correctly, as (at first glance) do xrefs. Can't say about Top Nav output because the project I'm looking at doesn't produce Top Nav output.

Time to report a bug...

[lanval]

Thanks Nita,

I checked my Word and PDF output and there are clean. Thanks, that somewhat eases my concern.

However, my Tripane output does have the broken labels.

[ChoccieMuffin]

I really don't like the feature, so all of my TOC items just have text rather than [%=System.LinkedTitle%], but that's only because any time I add a new entry I change it manually.

Is there any way to TURN OFF this unwanted feature?

[lanval]

ChoccieMuffin: Yes, you can simply enter the text in the Label field.

We often have variables in titles and headings, so variables in the label was a god-send for us. We were overjoyed when the feature appeared in the January release. I'm sure it will be fixed, hopefully shortly.

I have already submitted a support ticket and if a work around or a fix comes of it, I'll reply in this thread.

[LeslieT]

I looked at mine and I saw this happen in one spot where I had a condition applied in the Heading text. I took that out and re-added it to the TOC and now it seems to be behaving.

[lanval]

I'm glad it worked for you Leslie. In my situation conditions make no difference in my case - every single TOC entry is wrong. I hope to hear from Madcap today.

[kmorrison]

All the TOC items where the headings were switched out for text in my project were topics with snippets. Converting the snippets to text fixed the TOC entries, but they're snippets for a reason, so I'm going back to 2017 until this is fixed.

Also, I noticed some strange spacing in PDF bookmarks after installing r2, but I haven't figured out why I'm seeing that in some topics and not others.

[Jess77]

Flare was not able to open my TOC in the source files; instead, it created a blank one. I received an error that a file with same key already existed.
For some background, just prior to upgrading, I had applied the new LinkedHeader variable from the January 2017 release - which is phenomenal, by the way.

I was able to solve the problem by creating a copy of the TOC and then pasting into the same folder. Then, I pointed the outputs to the copy instead of the original. The project published and works; however, I noticed the following:
- The lowest-level subtopics - when clicked - take you to the main topic but not the heading of the subtopic. (I am auto-generating sub-topics by replacing with computed entries.)
- The lowest-level subtopics display the variable in the browser tab.

All the TOC items where the headings were switched out for text in my project were topics with snippets. Converting the snippets to text fixed the TOC entries, but they're snippets for a reason, so I'm going back to 2017 until this is fixed.

I thought the problem occurred only with topics that use the same snippet twice. Is it any topic with even one snippet in the body?
The principle is the same, though, snippets are meant to be used over and over again, so it shouldn't matter. I'm just curious.

EDIT: I just ran a test in the project of mine that is working--one with no snippets at all. I added one snippet to the body of one topic and then refreshed the TOC and then published. Everything was fine. I added the same snippet to the body of same topic again and ... received the same error message I receive in the broken project about the item having the same key already.
I hope they fix this soon or I will have to go back to the previous version as well. The snippet I'm working with is one I am sure you all have some variation of: "Complete these steps:" (for tasks).

[ThomasK]

I'm having the same issue with duplicate snippets, which is particularly interesting when they are used in the "Global" projects, as none of the child projects have a working TOC anymore.

from MadCap's support the only workaround for now is to convert the duplicates to snippets to text. Hardly ideal, but I can live with that for a few days.
I've added some comment brackets around it so I can later do a bulk REGEX "search & replace" using a simple tool like notepad++ to revert them back without having to manually go through all files.

Code: Select all

<!--SNIPPETBUG_ORIGINAL <MadCap:snippetBlock src="../../Snippets/Common/Lipsum.flsnp" /> -->
<!--SNIPPETBUG_TEXT
lorem ipsum ....
-->

If I run into more issues though, i'm going back to r1 until everything is solved..

[Linguistica]

Another TOC issue - perhaps related?
My deployed help system menus just disappeared and displayed an eternally spinning ball where the TOC used to be. The content of the pages is fine, but navigation is unruly without a menu.
I noticed in the physical structure of the Deliverables builds that there was a brand new unsync'd "Tocs" directory under Content/Data with the files: Help_System.js and Help_System_Chunk0.js, despite the fact that these files existed in their normal location directly under Content/Data. Since this new Tocs directory was not set up to be sync'd to our subversion directory that feeds where clients access Help, I added and then set them up to Sync. Hoping this resolves the issue. Is there a more basic solution?

[ryanhaber]

For me, what worked was to change problematic <MadCap:snippetText>'s to <MadCap:snippetBlock>. In our case at least, <MadCap:snippetText> had been interpreted as we intended (a block) whether rightly or wrongly. Changing the code to force interpretation as a block seems to have done the trick.

[kgdyall]

Does anyone know if this is fixed in r2 build 6355? I see "Snippets caused linked labels to display incorrectly in the TOC Editor" listed as a bug fix in the New Updates Available dialog.

[ChoccieMuffin]

ChoccieMuffin: Yes, you can simply enter the text in the Label field.

Is there a way to stop it shoving in the variable by default every time? I really don't like this feature and don't want to use it, so it's tedious to have to retype the title every time.