Content lib Publish - includeChildren backwards compatibility in XP 7.13

Bugs
1

Enonic version: 7.13.1
OS: Enonic Cloud

While upgrading some old projects (currently on 7.11.3) I noticed that some functions do not work as before, so I checked the documentation and source code in order to find if there are any big difference.

I can see that it still mentions the backwards compatibility on Content lib publish function:

image
image1587Ă—866 167 KB

But I noticed it no more work like before (7.11.3).
When providing a combination of arguments the results are no more the same. Please, see:

Scenario 1 (Success)

- Single content publishing with no children
- Arguments {
  keys=[content_Id]
  excludeChildrenIds=null
  includeChildren=true
}

Result: The content is published successfully, as expected.

Scenario 2 (Error)

- Single content publishing with or without children
- Arguments {
  keys=[content_Id]
  excludeChildrenIds=null
  includeChildren=false
}

Result: The content is NOT published, contrary to what is expected.

So I started investigating the Enonic source code looking for clues and I found this:

image
image1919Ă—1013 254 KB

Not sure if it’s my misunderstanding, but it looks like it’s excluding ALL contents from publishing.

Could you please confirm that this backwards compatibility is still valid?

1 Like
2
  1. Why are you sending excludeChildrenIds parameter at all? Did you try without it?
  2. Are you sure that contentId that you sent in keys is not already published before your call?
3

Here are the docs for Publish API: Content library - Enonic Developer Portal.

As you can see, there’s no includeChildren parameter. It was in XP6 but should not be used in XP7. We should’ve marked it as deprecated and then remove, but apparently it was forgotten.

If you send includeChildren: false then, as you said, contentId will be added to the excludeChildrenIds parameter. And purpose of the excludeChildrenIds, as written in the docs, is “List of content keys whose descendants should be excluded from publishing”. So in your case, if the content in keys is not already published, then it should work as you intend - publish the content itself, but not its descendants.

4

1. Why are you sending excludeChildrenIds parameter at all? Did you try without it?

Sorry, I meant undefined instead of null. It’s not being sent.

2. Are you sure that contentId that you sent in keys is not already published before your call?

Yes. It’s a recently created content. We also tested in other projects from our company. All the old projects still using includeChildren=false stopped working when upgrading to XP 7.13 onwards (not tried 7.12, though).

Here are the docs for Publish API: Content library - Enonic Developer Portal .
As you can see, there’s no includeChildren parameter. It was in XP6 but should not be used in XP7. We should’ve marked it as deprecated and then remove, but apparently it was forgotten.

I see. As a least effort policy we formerly decided to trust the backwards compatibility, that’s why we still use that field. Since you explicitly mentions to not use it anymore, we’ll work to remove it whenever we upgrade any project to 7.13+.

If you send includeChildren: false then, as you said, contentId will be added to the excludeChildrenIds parameter. And purpose of the excludeChildrenIds, as written in the docs, is “List of content keys whose descendants should be excluded from publishing”. So in your case, if the content in keys is not already published, then it should work as you intend - publish the content itself, but not its descendants.

I see. So it was a misunderstanding from our side.
Probably we didn’t pay attention and didn’t take much effort on trying the excludeChildrenIds field since we were still using includeChildren.
We used to understand excludeChildrenIds as the “ID list of children contents that would be excluded from the publishing”.

Now it’s clear to me.
Thank you for your explanation.

1 Like
5

We used to understand excludeChildrenIds as the “ID list of children contents that would be excluded from the publishing”.

I completely agree, this name is confusing. But, since it’s a legacy naming, we cannot easily change it until XP8.