Under Community Review
  • What are example use cases where direct Page Links are better than Component Links?
  • If we provide Page Linking functionality, where would you put the Page Links?  In Page metadata? Or also in Component content/metadata?  Components are often defined higher up in the BluePrint than Pages, so it may not be possible to link from Components to Pages (?)
  • Should it be possible to constrain the type of Pages you can link to (by Page Template or Page Schema)?
  • Should it be possible to embed Page Links in a Rich Text field?
  • Should it be possible to unpublish a Page if another published Page links to it?

Page Linking

Tridion should allow linking to Pages directly rather than through Component Links.

In order to simulate Page Linking functionality, we have created a "shadow navigation" structure using Navigation Shadow Components (which reflect Pages), so we can use Component Links to link to Pages. This solution is customization heavy and hard to maintain.
 

Chris Chrcek
  • in reply to Rick Pannekoek

    I think if the product were to add page linking, it should be from and to the same Publication. 

    I've seen "headless" CMS requirements reflected in flatter BluePrint hierarchies, where more recent projects had parent/owning Components and Pages combined into the same Publication.

    Some of this might be from organizations wanting fewer brands and websites as well as the dynamic nature of Content Delivery. You don't necessarily need separate websites and publications when differences can be handled by CD queries and metadata.

    I've even seen at least one customer combine Content and Pages to simplify translation processes, moving away from the familiar "diamond Blueprint" pattern. This seems to work when there isn't much sharing of content beyond the published pages and when there isn't a difference between language and market localization. The language is the market (or the market-specific information is more global or available to anyone, if that makes sense).

    If doing something with page links across publications, I think Business Process Types (BPT) might matter, where maybe you can only link to Publications that have the same BPT so the link resolves to the right CD environment?

  • I'm seeing more recent challenges for customers trying to understand and adopt Component Linking, especially with the latest (GraphQL-based) Content Delivery API. With CM-side templating, we can programatically generate the <tcdl> tags to create Component links, with control over template and schema priority to influence the resolved page. The Default Finish Action Template Building Block automatically handled making Component links work.

    Now with the CD API, we currently need to get a component ID and its page to then construct a separate component link query in GraphQL, especially for Component Link fields (I'm not completely sure on rich text format links). This is perhaps less "automatic" than it was for CM templating and it takes a bit of code in the GraphQL queries. Tangentially related to this, on the CD side it'd be interesting to get more of the linked (nested) Components in fewer requests. Slight smile

    It seems Component Linking only works to resolve target Component Presentations on Pages (as it always has). When a Page has a "target" Component without a template, the Component Link to that target won't resolve to that page in CD. There is a new resolved link property on Components that will return a page URL if the Component is published on a page. However, it doesn't seem to (can't) follow the existing Content Delivery Component Link resolving logic because it doesn't have a way to pass the page. Finally, without the TCDL format link, we don't have the automatic "fallback" option to change a link to just text if it's not resolved (again, for direct Component links outside of RTF).    

    I can see how customers might prefer page links based on this additional CD code needed and the lack of control on how Component Links resolve. .

    Other takes on this could be to either:

    • Simplify and revisit how template-less component linking should work in CD
    • More drastically, consider offering a way to get URL links for Components without pages Thinking

  • This is really one of those "that's just how Tridion works, get over it" things. The point is that component linking is a very powerful concept, but people don't immediately see the benefit of it. They want to link to a page, and working with component links seems like overhead. Obviously, Tridion /does/ have page linking, and there are probably some cases where it would be nice to have UI support for it, just not everywhere. The obvious use case is where there's a special page of some sort rather than a generic content page. Maybe it has only dynamic content, so there's no component to link to. (Many implementations just use dummy components for this, but if feels clunky.) The challenge is to add support for page linking where it will genuinely help, without creating a situation where people use page links for everything and component linking never gets into their comfort zone.

  • Sorry for the delay in getting back to you Rick. I didn't get a notification of your comment for some reason and have only just come back here after reading your blog post about Page Linking.

    Both the Pages and the Components were in the same Publication(s) for the solution that we built (I know - It was a legacy application that we picked up and was already like this!), so fortunately, we didn't have to worry about this.

    I guess that there are a few ways to handle this though, including:

    1. A user can select only one page to link to in one of the child publications (not ideal - unless this Page was inherited by the majority of the sites)

    2. A user can select multiple pages to link to, depending on the website publication

    I don't envy you guys the UX and UI design on that one! :)

  • What about the BluePrinting aspects? Do you allow links from Components to Pages? If so, aren't your Components higher up in the BluePrint than your Pages? If so, how does that work?