Dueling Settings in the Advanced Fields in HTML5 Target?

[Mishou6779]

HI Flare community,

The configuration manager asked me why there is a Content folder in the published output in SVN. He says it wasn't there before. He also wants to know why the final published help is now seven times larger than it was the last time I published. His theory is that the Content folder is essentially duplicating everything already in the published help, and that is why it's seven times larger. I am now troubleshooting to figure out what I did wrong.

If I have an HTML5 target, and in that target I select the check box in the Do not use "Content" folder in output field and then select Content linked directly or indirectly from the target in the Content to include field, will that result in a Content folder in the destination folder where the help is published?

For the way the field works, is the Do not use "Content" folder in output field only for the folder where the help gets built? Does that also mean/include the final published output in the destination folder? Or in this case is it expected that the Content folder would not be in the Output folder after I build, but a Content folder will be in the published destination folder when I publish?

I feel like I have a decent understanding of the Content to include field as it is explained pretty well in Flare's own online help. So I don't think that explains why there is a Content folder in the published help. Nor does it seem like that is the culprit for the help getting seven times bigger.

On a recent support call with MadCap, my working files for my project were moved to another folder on my C: drive, and connected to the old location in SVN. And we also added new publishing destinations in Flare and also sent them to their previous location in SVN. I feel like that was wrong, and that we should have also created a new folder in SVN, especially for the published output. I am concerned that between moving the working files on my C: drive and then also adding a new publishing destination but not changing its location in SVN, we somehow caused the bloated output problem. To be clear, the working files in SVN are in a different folder in SVN than the publishing destination. They are not both pointing to the same end point folder in SVN.

Thanks!
Michelle

[devjoe]

These two options do very different things, and I don't think they interact in the way you are worried about.
Do not use "Content" folder in output determines the structure of the files in the output

• If this is off, then the output contains a folder named Content and all your content (from the Content folder of your source) which is included in the output appears inside it, segregated from the files and folders Flare creates at the top level to make the project work.
• If this is on, then Flare does not create the folder, and your content lives at the top level of the project, intermingled with the files Flare creates. This means the path is 8 characters shorter (good if you have paths so long in the project you run into Windows' path length limit) but it means you have to be careful not to create files and folders with conflicting names.

The attachment shows this option turned off on the left (so you can see in the Content folder at the bottom left what my actual content looks like) and turned on on the right. (In my project, the topics are all inside the Cases folder, but if I had topics directly inside the Content folder in my source, then in the second example they would appear in the same folder with Default.htm and I'd have to be careful not to name a topic Default.htm.)

Content to include determines which files are included in the output.

• All Content means everything under the Content folder of your source is included, unless conditions exclude them.
• Content linked directly or indirectly from the target means Flare starts with the TOC, topics with Context-Sensitive Help IDs, and perhaps a few other things, and adds the files linked from those, and the files linked from those, and so forth (considering images, stylesheets, scripts, hyperlinks - all kinds of links) until it doesn't find any more unlinked content, and includes those in the output, but not unlinked files in the source's Content folder
• Content linked directly from the TOC is similar, but it only includes topic files if they are directly linked from the TOC. It will still include images, stylesheets, and such linked from those topics, but it won't follow links in the topics to other topics to find content to add.

Changing the "Content" folder option should not add or remove content from the project, just organizes it differently. But changing the Content to include option changes what content is delivered, and if you set it to All Content this could greatly increase the size of what's delivered. You need to determine what you intend to deliver.

Check to make sure that you didn't duplicate content in your source when you moved things around. There should be a Content folder in your source at the same level with the project file (.flprj), and it should generally not have Content, Output, and other such folders inside it, though it may have folders you used to organize your content, as with the Cases folder in my example.

If you didn't do this, but your published content has the same content inside the Content folder and outside it, at the top level, then it sounds like something has gone wrong with your publishing and the previously published content wasn't cleared out. This might be the side-effect of creating the new publishing destination. You might need to manually clear the folder and publish again.