Page tree
Skip to end of metadata
Go to start of metadata

Public roadmap item: 

Moderator: Vivian Steller


Lemonize did a lot of work on the topic - but on asingle project basis.

The group thinks this should be delivered at the CMS level.

Lemonize suggests a nice API to get the dependencies of an item. Then 3rd parties cover any other needs or use cases they have that relate to the topic. Should be a core feature of the CMS. For any piece of content. Who do i depend on? Who depends on me? Make a graph of dependencies.

Core media has it - suprised that magnoila does not have it. They provide UX to tell you if everything is published or not. (All dependencies have been published.)

MGNLCDEP-62 - Getting issue details... STATUS

SUGGEST-83 - Getting issue details... STATUS

SUGGEST-66 - Getting issue details... STATUS

Use cases

  • When publishing a page - detect that an asset is not published, 
    • to prevent publishing a page and getting a different result on public website as on author instance.
  • Cache invalidation. (If a cached page included a description of a tour - and then the tour title changes - the cache for the page should be invalidated.)
  • Publishing related content.
  • Detecting stale content. 
    • For example, over time some assets will not be used on any pages anymore - there could be thousands of them. This could help detect which ones are not used so they can be removed from the system.
  • SEO: detect alternate links

Potential technical approaches

  • For a content item, look at any link fields and consider the targets of the links.
    • Content types should help with this by supplying an explicit model of what links to what.
    • Unfortunately, link field itself only stores UUID which is not complete information.
    • Must also consider the "transient dependencies".
  • Look at the rendering process - and note all the nodes that were accessed. On a rendering level instead of searching for content by dependencies.
    • This makes sense with pages which have a clear rendering process.
    • But what about headless use of content items - in this case Magnolia is unaware of the rendering process.
  • Separate content dependencies and content itself for fully manage its dependencies, however there also be an idea about self-contained metadata of content item which supports low-coupling between contents themselves.


Some dependencies might be hidden. It's not trivial to detect all of the dependencies.

  • What about Inheritance of a page?
  • What about "dynamic dependencies" things depended on as the result of code execution, logic in a content model or templating function - you wont catch those by simply "walking the content" and resolving the items in the link fields.

Problem with how links are stored. Just a UUID, you wouldnt even know how to link to it. It should not depend on knowledge of the dialog definition.

→ Look at how links are stored with rich text editor (JSON-like format). Vivian recommends this.


If Magnolia cannot reliably detect dependencies 100% - should the feature be implemented? It could be worse than now if people depend on it and it does not work reliably.

  • Maybe the UX can help with this, a dialog box always includes a disclaimer "be sure all dependencies are published."


Back in the day, Magnolia thought we could do it for 95% of cases - but not for all. So there is a risk in including this feature.


Vivian: like JCR observation - could that help.

Content dependency module exists and does cover some of these cases. 

  • You just need to configure it. to handle more than assets. But its a campaign to publish.
  • But its EE!

Open minds module had a different approach - it did not let you link to assets that were not published!

  • No labels

1 Comment

  1. Thanks, Christopher Zimmermann taking the notes.

    Though, I don't agree with this statement:

    We thought we could do it for 95% but not for all. So there is a risk in including this feature.

    IMHO let's take, for instance, the use case of "publishing with dependencies": it's much worse not being aware of broken content on public at all ("no saying anything") opposed to giving developers the ability to solve these issues productively using a core API. I'm convinced there are many cases that can be covered even 100%, though there might be some that you cannot cover at that level. In this case though, it would be even better to state "We cannot guarantee that all dependencies have been identified. Please ensure .... manually." instead of saying nothing.

    I'd not expect Magnolia to implement all Use Cases that take use of dependencies. Instead I'd love Magnolia to:

    1. provide a "low level" API for resolving and querying dependencies graphs. Simply make the resolvers pluggable and the responsibility for completeness is up to the developer. The low level API could serve as a basis, for instance, for implementing cyclic dependency detection, dependency caching, etc. (BTW the API is actually there, though it could be improved)
    2. promote best practicesto ensure that resolving dependencies could be implemented in the future (by some one), like storing at least the workspace name along with any UUID stored in JCR properties (which you promote for Assets already), for instance.