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
Parents

  • 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
Comment

  • 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
Children
No Data