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

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

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

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

Children
No Data