Certainly you must republish the master.
I always did then republish all the child projects but mostly because the
number of projects was small.
I think you will be OK skipping republishing unchanged child projects but
you are using a different output, I was using WebHelp. Check it once to see
if it works.
The merged help pages on my site have a small demo. Download that and test.
What doesn't work is generating/publishing the parent and not doing the
same at least once for each child the parent knows about. Thus don't add
say 10 children to the parent TOC and just generate/publish the first child
only and test. You must generate/publish all ten at least once. Then you
can just update changed children.
I see you said "republish" as opposed to regenerate.
(In my original question, I was using terms "publish" and "generate" indiscriminately.)
I'm not quite up yet on generating versus publishing. I haven't had a chance to use the RoboHelp publishing function yet, as I don't yet have clearance or ability to publish to a gov server. Meanwhile, I am building the file structure of Master Project and Children while awaiting clearance.
If I understand correctly, you are saying I can:
1) Generate and publish the Master Project with an original five child projects (children 1 through 5)
2) Publish children 1 through 5 into their respective mergedProject folders
When I later want to add children 6 through 10, I can:
3) Open up the Master,
4) Add children 6 through 10 into the TOC,
5) REPUBLISH (rather than regenerate) the Master Project, and that
6) When I republish (rather than regenerate) the master, children 1 through 5 will remain intact? (I won't end up with empty folders for children 1 through 5 under mergedProjects?)
(In other words, if nothing in children 1 through 5 had changed, I wouldn't have to republish them. I could then proceed with publishing children 6 through 10 into their respective mergedProject folders in the now-updated (republished) Master Project output file structure on the server?
Also, I assume that:
1) regenerating means regenerating an entire project/website in its entirety;
2) publishing means you can publish selected topics within a project;
3) publishing (or republishing) selected topics means that those selected topics are first generated, then published;
4) dates in footers will reflect date a file was generated, not published.
If I have a footer in all topics, with a date field, and all of Child 01 was published in 2017, but then selected topics in Child 01 were republished in 2019, will the dates in the footers reflect those differences -- with most topics having a date footer of 2017, while selected topics will have footers with 2019 dates?
I will look in the morning but you need to understand the difference
between generating and publishing. See my site.
Hopefully Peter won't mind my offering a brief explanation.
Working with RoboHelp is a lot like working in your kitchen. The process of generating is similar to mixing ingredients in a mixing bowl, placing the mixed ingredients into the oven, baking them, then taking that final result out of the oven and placing it on the stovetop.
Once the dish is complete, it needs to be copied to a location for folks to consume it. And that's where Publishing comes in. When you Publish, you copy that Generated output to the final destination. Most often, that destination is a web server.
Certainly, to publish something means to make it public.
My question is really about:
Generating and publishing a Master Project creates empty folders for each child under mergedProjects.
Each child is then generated and published into its respective folder.
So if I have this master/parent project, and child folders 1-5 are populated/filled, and I then edit the master to add placeholders for new children 6-10 and REPUBLISH the master project, will the folders for child 1-5 now once again be empty?
once you have created your master project and filled the already existing child folders, a regeneration of your master with additional children will not delete the content in the existing child folders, but only add the missing folders. Thus, you will only have to create the new child projects. The existing ones only have to be regenerated, if there have been changes to these projects. I'm doing this with HTML5. Notice, that also folders that are no longer part of your master will not be deleted automatically from your output destination. They will just no longer be displayed in the TOC of your master index.
However, just in case: keep a backup!
Let's look at a single project first.
When you generate, you generate to the same drive as your project, local is preferred but network is OK if the project will work on your network, that's a whole separate subject. Each time you generate, RoboHelp first empties the folder to which you generate and then creates the new output. You could give that to developers and it would work OK. They would copy that to the locations from which users access it. RoboHelp though gives you an option to publish and by selecting the option not to republish all, it will only upload changed files. A difference between generating and publishing is that the latter does not delete anything from the location. That can be useful if you need users to access anything that would not get uploaded by the publishing process.
When you generate on subsequent occasions, only the target of the project gets cleared. Regenerating the parent does not clear the sub-folders for previously generated child projects but it does add holders for the new child projects.
Please download my demo and see the structure there. It keeps the generation folders separate from the parent and is a much clearer way of working. Also you can publish locally and that is set up so that you can learn about that process.
See www.grainge.org for RoboHelp and Authoring information
I think it's great that you are trying to plan for issues you could possibly encounter as your help system grows. In addition to the advice from everyone that has replied to your inquiry, I suggest that you start writing a DOS batch file with the commands necessary to compile your projects. Given the wide range of how many projects you think you could end up with, if you start building the DOS batch file now and test it as you go, you can make adding a line to that DOS batch file become part of your process when you add a new child project.
I have set up my file structure according to the advice in your Merging WebHelp article.
I'm in a gov office, so there are lots of concerns with firewalls, security, network drives. I've run into issues keeping anything on network drives, so now I keep everything on my C drive.
Moreover, I keep everything at the highest level possible in my root directory. C://01_SOURCE_CSS_MANUAL.
Also, I try to keep folder names as short as possible.
I keep all output in a separate file: C://02_OUTPUT_CSS_MANUAL.
I've put my Resource Manager shared files in the source files folder, so that it is under the same root folder as the master project and child projects.
I will institute the redirect from Master to 1st Child, as you suggest in your article.
Thanks for all your help.
I will probably need to link extensively from child project to child project. That's another hurdle. I'm using your same article (Merging WebHelp) for that.
Thank you very much, Karin!
You've put my mind at ease. (I wrestled with this all day yesterday.)
It seems counter-intuitive that regenerating the master will not regenerate clean (empty) mergedProject child folders, but you are right. I just tested it.
Thank you for the advice. I will have to get back to you on that. I am under big time constraints, and will have to learn about this DOS batch file thing a little later on.
Because my entire (master) project is so complex and massive (and I am building it from scratch), I am spending a lot of frontloaded time trying to future-proof it, get the fundamentals right, allow for tons of shared content, modular reusable content, updating, etc. Also, I'm a one-man show right now, but need to plan for future multiple authors, etc. This means my building fundamental file structures etc correctly, but also templates etc to standardize workflows for multiple workers in the future.
I know Paul's advice likely works well for him for however he's managing his projects, but I personally question the value of a batch file for a merged setup.
Here's why. Normally, with a merged setup, you only make edits to a single project at a time. And 99% of the time you are only modifying child projects. So after you modify the child project, you generate and publish to the location for its slot in the merged setup.
The batch file would seem to imply that any change to a single child project then requires opening ALL the projects (Master and all child projects) Generating all of them and re-publishing all of them. And that's seldom the case. It seems massive overkill and a huge waste of time to take that approach.
But that's just my own opinion.
Keeping links between child projects only the way I describe is easily the safest option, so long as all the child projects are delivered. If some users will only have the parent and some children, it's important those children don't have links to topics they will not have.
See www.grainge.org for RoboHelp and Authoring information
I don't know if my advice is appropriate for mthiel2016, but I just wanted to throw it out there. To me, it would be easier to build it as you go instead of all of a sudden being in the situation where all the RH projects need to be republished. When that day arrives, there will be two options:
1) opening, compiling, & publishing "dozens to hundreds" of projects through the UI
2) double-clicking a DOS batch file and going for a walk outside while it churns. <grin>
My perspective comes from a situation many years ago when I had a central project with a page that all of my child projects linked to and a need arose to rename that linked to filename. it was not something I could control - it was dictated by changes to the system(s) I was documenting in those RH projects. The bottom-line was I needed to modify all of my child projects and recompile and republish. This was happening on top of other high priority work that had to be done. Being able to recompile / republish all my RH projects helped me immensely.
Again, it could be a huge waste of time, but since I went through what I described above, I felt it was relevant.
Duly noted, Peter.
Interesting situation you have there Paul. I do recall in the days of WinHelp, my project had about 255 or so separate merged projects. But that's about the only instance I've personally ever seen or heard of where one would have dozens or hundreds of projects. And even in that case, I never once had a need to recompile all of them at one time.
I suspect the most common setup just involves a handful of projects.
But I know I'm also unique. Just like everyone else. LOL