Public roadmap item: https://trello.com/c/KtpsQ466/19-publishing-of-related-content
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
- 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!