Logic behind dependency resolution for publishing content

Enonic version: 6.15.3
OS: Window Server

We are having a problem with unrelated content appearing in the “these contents also needs publishing”-list when we try to publish a content. We have checked that these content are not related directly, and one of them is not even under the same site-node.

This is what the dialog looks like when I try to publish “Hvordan slipe kniv på en trygg måte”:

image

The only content nodes that are directly related to this content are the three featured nodes:
image

This is the content viewer version of the content in the draft branch:
{
“_id”: “d28de80f-2716-44c6-86db-63f9acc60245”,
“_name”: “hvordan-slipe-kniv”,
“_path”: “/tine/oppskrifter/tips/hvordan-slipe-kniv”,
“creator”: “redacted”,
“modifier”: “redacted”,
“createdTime”: “2018-09-24T17:52:46.491Z”,
“modifiedTime”: “2018-10-01T12:44:01.225Z”,
“owner”: “redacted”,
“type”: “no.tine.tine:article”,
“displayName”: “Hvordan slipe kniv på en trygg måte”,
“hasChildren”: false,
“valid”: true,
“data”: {
“media”: {
“_selected”: “mediaVideo”,
“mediaVideo”: {
“youtubeLink”: “MatSans®: Hvordan slipe kniv på en trygg måte - YouTube
}
},
“preface”: “TINE viser deg hvordan du skjerper kniver for å få de så kvasse som mulig.”,
“conShowComments”: false,
“featured”: {
“_selected”: “content”,
“content”: {
“featuredNodes”: [
“0344d0d0-5b17-4abf-8c79-4ed103cc62fa”,
“39f2846b-8148-482f-8641-e08cec34963c”,
“4fb76088-21a8-4a70-bdcc-3f96682a1665”
]
}
}
},
“x”: {
“com-enonic-app-metafields”: {
“meta-data”: {
“blockRobots”: false
}
}
},
“page”: {},
“attachments”: {},
“publish”: {
“from”: “2018-09-24T17:55:22.798Z”,
“first”: “2018-09-24T17:55:22.798Z”
}
}

Does the dependency resolution traverse multiple levels out from the current content and that there is some deep dependency between these content?

1 Like

It is as you said - when content is about to get published, the logic behind is unwinding the entire chain of dependencies to make sure all of the items higher in the chain are published, otherwise the target content may not become previewable in the master branch.

Is there any limit to the directions it traverses? If I am publishing a content that directly references a tag I usually don’t want to publish all the other content that other people are working (with references to the same tag), for instance.

We are also getting one detected dependency on a content from a totally different site, with no shared reference that we can find. Is there any way to actually figure out why it thinks these two contents are related? Some kind of dependency traversal function we can call from an admin tool app or something?

When you are about to publish content, all of its dependencies - both inbound and outbound - will be fetched and shown under the list of “other items that will be published”. In addition to these, all descendants (parent items) of both the selected content and its dependencies will also be added to the list. While you can exclude the dependencies from the list (the “x” icon is enabled), you can NOT exclude the descendants, since you cannot publish a child item without publishing all of its descendants.

There’s no limit when it comes to the logic of traversing, it goes up from the selected item(s) all the way up to the root (+ dependencies).

We are also getting one detected dependency on a content from a totally different site, with no shared reference that we can find.

Most likely it happened when a content was duplicated and the copy preserved references to some content in the original site.

Is there any way to actually figure out why it thinks these two contents are related? Some kind of dependency traversal function we can call from an admin tool app or something?

The only way to do it as of now is manually - look at the list of dependencies in the “Dependencies” widget, then look at dependencies of dependencies etc. The widget shows only direct dependencies, but we are planning implementing a mode where it will show indirect dependencies as well.

Is there a way to debug this further? in our case the issue with content on a differnt site is somehow showen as a dependency. We’re pretty sure there is noe duplication going on since these two sites are developed independently.

Hopefully there is a logical explanation here and not a serious bug. Otherwise our editors will not be able to work efficiently as they keep getting more and more random content they manually have to exclude each time. The risk of missing a content is high as some content is time sensitive (new products, corporate news etc) and can’t be published

You can always debug it yourself since the code is open source, but I’m sure there’s logical explanation. We got a few similar questions before and - when we had access to the data - were always able to find how the content was related. If you set up a temporary user or send us a dump - via Zendesk, of course - we’ll be able to give you a bit more info on the dependency resolution.

Sounds good. We’ll have to supply you a dump anyway to solve the refresh issue