Use Page linking instead of component linking in tridion

Question

We have a requirement were Editors want to link to a page (Page in Tridion) from component field instead of using the Tridion component linking. We decided to use the Item Selector custom URL approach to select a page. Using Item Selector we can either retrieve the TCM ID of page or the published path. The pros and cons can be.

1. Using TCM ID

Pros: The TCM ID will remain unique in same CM environment, so even if Editors move across the pages from one SG to another, it shouldn't create a problem.

Cons: This will fail when content is ported from one env to another.

2. Using Published path of the page

Pros: The paths will not change across environments (In case if same SG structure is maintained). Also Editors feel more comfortable to see the page path/ title rather than TCM ID.

Cons: If the pages are moved across SGs, the path needs to be updated again which is not a feasible option.

Right now we are going with TCM ID approach (considering content will be created separately in each environments) and also the timelines.

Suppose we decide to go with second option, how can we automatically update the published path in component on page cut/paste?

What are the best options in either case?

(Either of the approach will require some work in JAVA Delivery side as well, which I haven't mentioned it here).

Answer 1

I've done solutions for this in the past... and as usual, there's many ways to peel this cat. While I still believe that component linking, functionally, is really what you need (even if people think it's not what they want), I agree that for certain pages you could use page linking.

Solution that works

So what I've done quite successfully in the past is to create some components that are used to identify those pages that you would want to link to (like section index pages) and create components that only exist in that page. Editors were trained to link to a component under /Building Blocks/PageLinks/MySection/SectionIndex whenever they wanted to link to the index page of "/MySection". Functionally, they are linking to a page, since only that page would contain that component (yes, this cannot be enforced, but there's nothing wrong with trusting your content editors once in a while).

Context

The challenge with Page linking is not linking to the page. We could manage those links. The real challenge is Publication context. First (and foremost), the pages do not normally exist in the same publication where your content exists, forcing us to allow cross-publication linking which is a minefield of unexpected consequences and complexity. Second, what if I don't want to link to this page in the current publication, but rather to the French version of that page in a different publication? Or that page in my "OtherBrand" website?

In other words: we're not solving this anytime soon (i.e., not in the upcoming SDL Web 8 release).

Answer 2

You have tagged this question with dxa and in there we also actually use Page links for our include Pages. Since there is no item link field in a Schema possible yet (working on that ;o), we decided to use the relative URL of the Published Page in a text field.

No matter what you use, the link will remain an unmanaged link, which is something you need to handle properly. In the case of DXA and the inlcude Pages, the web application expects the URL to be correct and the Page published, else the web application will throw a run time error. At this point we also haven't provided an interface to select the Pages, and don't do anything in regards to people moving those items.

The main reasons for not handling that is because we use those unmanaged links in Page Template metadata, so there could be a lot of items which have these unmanaged links. Building an event system which would check and update will have too much of an impact on the system (the amount of times it needs to check and the amount of checks it will have to do), which could be very bad for performance. So we decided (for now) to leave it all up to the users themselves.

Answer 3

With the second option, you'll likely still want a reference from either the linking Component or the Page. This will let you know which Components to update when the page is moved (via the Event System).

Technically you don't need to generate new paths or IDs until publishing the linking items. Page IDs would be preferred to keep dynamic page links in delivery.

Otherwise DXA has the idea of "main" components (that store SEO info) that should be linked to.