Temporary excluding topics from publication incl. children

[Rainer Oehry]

Let’s say I want to exclude certain topics including all their children from a test publication run (to save time, and to avoid getting error messages from issues in these topics that I don’t want or need to fix right now).

I cannot just set the topmost topic of the branch to "None" – if I do that, the children are still processed and produce error messages (even if the parent topic does not appear in a TOC).

I could of course fully expand the parent topic and exclude all children as well by setting the include options to "None", but several of the children have individual include options set which would get eliminated. I could apply an additional "Ignore" build option (that I don’t select for the test publication), but then I would still include the topics with individual build options that I must activate because they are needed in the topics that I actually want to test publish, and this would require special care not to mix up anything when undoing the "Ignore" option.

I am probably missing something basic here, but Is there an easy way to exclude a whole branch of topics by just modifying the settings of the topmost topic of this branch?

[Tim Green]

I am probably missing something basic here, but Is there an easy way to exclude a whole branch of topics by just modifying the settings of the topmost topic of this branch?

Not really, because that is the way the logic was currently defined. You do need to explicitly exclude anything that you want to exclude. However, you can achieve this with the multiple TOCs option, because in secondary TOCs branches that are not there don't get included in the export:

1. Right-click on the Table of Contents node at the top of your TOC, select Create new Table of Contents and choose the option to make a copy of your main TOC.
2. In the new secondary TOC delete the branches you don't want to include in your publish.
3. When you publish, select the secondary TOC as the table of contents to use in the Publish screen.

[Rainer Oehry]

Thank you for your suggestion, Tim.

In fact, I use the multiple TOC functionality a lot (one of the many strengths of H&M). This seems to be a very good alternative to my intended workflow — I can always drag and drop additional branches to the "test" TOC, or delete anything I don’t need anymore. And I do not even have to remove any "ignore" markers in the production TOC afterwards, because I didn’t have to change anything there.

I like it!

Edit: Just noted a little detail: After creating an empty new TOC, it is not possible to dragdrop a topic from another TOC to the "empty" new TOC. One has to first create a "local" child topic. Only after that it is possible to drop anything under the new TOC header. Is this the intended behavior, or maybe a technical necessity?

No big deal, though.

Another Edit:
When deleting a TOC entry, there is a little, easy to miss option at the bottom of the popup window which lets the user select whether the referred topic files should be deleted, too. This option is activated by default, even when deleting entries from additional TOCs. I believe this to be unnecessary risky — more often than not, deleting a TOC entry from an additional TOC should not result in the deletion of the topic file itself.
Could you please consider to unselect this option by default, at least for secondary TOCs?

[Tim Green]

Hi Rainer,

Edit: Just noted a little detail: After creating an empty new TOC, it is not possible to dragdrop a topic from another TOC to the "empty" new TOC. One has to first create a "local" child topic. Only after that it is possible to drop anything under the new TOC header. Is this the intended behavior, or maybe a technical necessity?

More of a technical necessity, really: You need to have a target to be able to drag and drop something, and the TOC node is really just an empty heading. The TOC doesn't actually exist until it has at least one entry.

When deleting a TOC entry, there is a little, easy to miss option at the bottom of the popup window which lets the user select whether the referred topic files should be deleted, too.

Not a problem, actually. The referred file will only really be deleted if the TOC entry is the last reference to that file. It looks scary, but as long as you're working on copies in secondary TOCs and not new original topics in secondary TOCs you won't delete the files even if you leave it on.

Changing the default is tricky here: I believe it used to be the other way around a long time ago and then there were howls of protest because users thought they had deleted topics but they had only deleted the TOC references and the topics were still getting exported to their CHM and WebHelp.