Multiscreen publishing - parent publishes all children?

[Amebr]

Hi all,

Just setting up merging in Multiscreen HTML5 output. It appears that publishing the parent publishes all the children that might exist in the "mergedProjects" folder. This is pretty undesirable behaviour when different people are working on each of the children and with different publishing schedules.

How do people manage this so that outdated or draft/test builds aren't pubished?

And does anyone know if this is the same for Responsive HTML5? Would we need to publish the parent and children all at the same time every time (given the children have to be generated into the parent build - or is that only the first time)?

Regards,

Amber

[Peter Grainge]

It often happens the first time you generate the merge and I have never understood why that should be. I think you will find that whenever you generate the parent again, it will not happen.

No guarantees. It is best to generate somewhere and then publish. If it should generate all, you simply don't publish as well.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Amebr]

Thanks Peter.

I realised I have Republish All ticked in the parent which forces everything to be republished all the time. When this setting is unticked, then RH only publishes stuff it thinks is different, including stuff in the mergedProjects. How it determines that I'm not sure.

To be safe, I think I'll remove the publish destination from the parent, and manually copy the output across to the server when needed - theoretically the parent shouldn't have to change very often.

Thanks again,

Amber

[Peter Grainge]

Nope! It only forces all the topics in the individual projects. What you have encountered is not because you unticked the box but because it is not the first time you have generated, as above.

It is unlikely to happen again but don't rule that out, hence my advice to generate and publish.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Amebr]

Maybe I'm misunderstanding what you're saying. I did try it several times.

For me, with the checkbox unticked, only the changed topics in the parent published. With the checkbox ticked, all the children published, even when the children had not changed (at least, I'm assuming it was all - at any rate "lots"). I'll give it one more go on Monday, in case I was suffering end-of-week-itis.

[Captiv8r]

Hi Amber

I think what you have said makes perfect sense. And it's quite logical when you think about it. But first, we need to make note of some behaviors.

Let's talk publishing generically. As I understand it, here is how publishing works.

The first time it happens, there is nothing to compare against. So it behaves as if you have the "Republish All" check box enabled. Each and every file in the output location is copied from the source location to the destination location. And at that time, RoboHelp creates a list to track files.

So you edit two or three topics, generate and click Publish again. And as you have noted, only the files that have changed and need to be copied are copied.

If at any point you enable "Republish All", it's as if publishing has never been done. All files will be copied regardless of whether they are new or not.

So that's basic publishing behavior.

But in your case you aren't talking about a basic project. You are talking about a MERGED project. And from the way you have described things, it would seem that you have configured your output so that the parent as well as all children are in the same output location. And I suppose on some level that makes sense, as you likely want to test where all children are present and accounted for.

And if this is the case, it makes total sense to me that publishing would copy all the children across with the "Republish All" check box enabled. This is because you have instructed RoboHelp to ignore any list it had and publish everything in the folder again. But without the option enabled, if all you did was change some of the parent files, only those changes in the parent would be published because there were no changes to the child projects.

One place I'm unclear on, however, is that when you generate, typically the first step in the process clears the folder in preparation for the new batch of files. And I might think that would include the children as well. But it sounds like I may be misunderstanding that aspect or possibly Adobe has arranged it so that the child projects aren't erased in that process.

Cheers... Rick

[Peter Grainge]

So when did making sense come into it? I agree that what Amber says makes sense. I have have one teensy weensy issue with it, reality. I have had merges that quite happily only generate what you want, the parent alone and then any one or all of the children. Then suddenly one day you generate the parent without changing the Republish All setting and this time it generates all. Repeat the process and it generates just the parent.

I stand by what I said, generate and publish so that if it decides to generate all, you have the option of not publishing as well to preserve that. Republish All is a bit misleading. I'm pretty sure it applies to the generation as well. I do know for sure that it can generate all when previously it has just generated the parent.

Why? I'm not high enough up the pay grade to be told that.

Peter Grainge

www.grainge.org

[Captiv8r]

Hmmm, I thought the only issue was publishing. Perhaps I should carefully re-read the thread? I've never seen the process of generating actually generate the child projects as well. How would that happen? Does it launch another instance of RoboHelp and generate the children?

I'm confused.

Cheers... Rick

[Peter Grainge]

My dear Rick, will you please stop applying logic to this? No of course

generating one project should not generate all the children, any more than

should publishing.

It's the generating that goes beserk rather than the publishing. Generating

will always generate all the topics in a project because the generate

process clears the generate folder. Sometimes though it just carried away

and then goes on to generate every project in the merge. No it doesn't open

another instance, it just generates from the parent.

Republish All only applies the publishing part of the generate and publish

process because generating is always all topics.

I believe the problem may have a connection with the phase of the moon.

[Captiv8r]

What can I say? I'm a logical kind a guy.

I bow to you on all things merged and if you say you have seen it I take you at your word.

Very strange! Then again, I do believe this is Multiscreen, which is a bit of a Hydra.

Cheers... Rick

[Amebr]

Sheesh. And it all used to work so well and simply with chms. :S

Thanks for all your help, guys. I'm definitely disabling publishing in my parent and will keep a close on on the children, just in case.

[Peter Grainge]

Amber

I'm not sure you have picked up on my key point.

It is the generate part of the generate and publish processes that can go

wild and when they go wild it does not matter whether or not Republish All

is ticked.

What Republish All does is another matter.

[Amebr]

I believe I understand Peter. By my reasoning, if it goes mad and generates everything in the merge, if there is no option to publish then the re-generated children can't be published by accident. I always use generate, then publish as a separate action. However, with multiple authors, it's possible someone else prefers generate and publish as one action.

[Peter Grainge]

Publishing does not happen automatically. After generating if publish

locations have been set up, then the Publish button is enabled. If it goes

wild when generating, when it has finished generating just don't hit the

publish button.

At that point your generate folders have been updated but your publish

target has not been touched.

[Amebr]

Apologies, I thought you meant when you choose Publish then say 'yes' to 'do you want to generate first?'. That then goes ahead and generates and publishes in one action.

[Amebr]

Okay, I have conducted more tests this morning with Republish All unticked.

I set up a simple merge following Peter's webhelp merging guide Merging WebHelp - RoboHelp 9 and 10.

1. Generated the parent.

2. Generated the child.

3. Published the parent. Both parent and child were published.

4. Changed the child and generated only.

5. Published the parent without making any changes to the parent. All changed child files were published. There were no changes to publish from the parent.

This shows that the parent publishes changed child files.

Given this, for my situation, I believe it will be safer to remove the publishing destination from the parent.  This means the Publish button will not be available, so I can't click the button when my brain is in neutral (and mine is regularly. ).

[Captiv8r]

Curiosity question

Did it surprise you that publishing from the parent project would also publish the child files?

If so, why?

Cheers... Rick

[Amebr]

Not if you assume a single author and a single deployment date. But I've always worked in situations with multiple authors and multiple deployment dates. Possibly 'frustrated' would be a more accurate description.

For example, C1 is released on Mondays by A1, C2 on Fridays by A2, C3 every second month by A2. Then the parent may need to be updated by A1 when a new product is brought on board. A1 risks accidentally releasing incomplete help for C1 if they have generated it since last time they published (highly likely); or C2 or C3 if they have generated those to check something - with the added bonus of potentially having generated an old version because they didn't get the latest (because they were just quickly checking something).

[Captiv8r]

In that case what I would recommend is to create a second publishing destination that points only to the specific child folder location. If this were configured, only that specific child should be published.

Cheers... Rick

[Amebr]

I'm not sure what you mean? If I create another destination in the parent, wouldn't that then publish the parent into the child folder instead, then replicate the merge structure within the child?

[Captiv8r]

Hi Amber

It's likely I'm misunderstanding your workflow. So please allow me to try and explain my own understanding and you can tell me if I'm off.

As I understand it, you have multiple authors. In my example, I'll call them A1, A2 and A3. It's my understanding that perhaps A2 and A3 only work on child projects. So if A2 updated the child project and are ready to deploy, they have a publish source defined as only the folder where the child project exists. And when they published, only that folder would be affected because the source for the child project is only that specific folder (and its subfolders).

Cheers... Rick

[Amebr]

Yes, that bit is working fine. The point where trouble strikes is with publishing the parent, which will also publish all child project files it deems to have changed.

A2 is happily working on their child project and publishing C2 as required to the specific child location. They are in the middle of a release cycle and generating C2 regularly to check links etc. One day A1 is sick and they need to release a change to P. A2 gets the latest version of P and generates. When they publish P, all the changes in C2 are also published because those files are different from the last time they published.

(Remember this is following Peter's guidelines to generate the parent and children into a common structure.)