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).

  • 1
    Why are the editors interested in linking to pages instead of Components? What happens to Components that need to link to different pages in different Publications (do they get localized)? Commented Oct 9, 2015 at 11:10
  • They are not so comfortable to use Component linking....We have only one website as of now... :) Commented Oct 9, 2015 at 12:17
  • 2
    I don't quite understand what: "they are not comfortable with Component linking" means, sounds like they just need some education on why Component linking is probably exactly what they need? Commented Oct 9, 2015 at 13:00

3 Answers 3


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).


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).

  • We had thought and proposed similar approach, but it did not look convincing to Editors. They were using some other CMS few months back (Where I believe page linking was possible) and hence they are more comfortable with page linking. Currently only one website is used and its difficult to convince them with other language or other brand publication perspective. Commented Oct 9, 2015 at 12:37
  • OK, clear - still don't think that using TCM ID is more user friendly than selecting a component in a specific tree node... but if it makes them feel better... I've also done a UI extension that exposed these components "as pages", so it looked like they were selecting a page, but under the hood the link was resolved to a component.
    – Nuno Linhares
    Commented Oct 9, 2015 at 12:45
  • Right now the TCM ID is selected by using Item Selector. So basically the Page link field is a Text field which contains TCM ID of the selected Item. Commented Oct 9, 2015 at 12:51
  • 2
    OK. then for multi-environment support you could indeed look at an Event System to convert the URI to a WebDavUrl on save.
    – Nuno Linhares
    Commented Oct 9, 2015 at 13:00

You have tagged this question with 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.

  • Example of the "Page links for our include Pages" in DXA: The 'Home Page' PT (\100 Master\Building Blocks\Modules\Core\Editor\Templates\Home Page) has 'Page Template Metadata' which includes links like "system/include/header". imgur.com/aeRPihP
    – Jan H
    Commented Oct 19, 2015 at 13:50

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.

  • I believe page links in RTF fields are managed, but I'll let someone else confirm. The functional catch would be linking from the right context since the content Publications tend to be higher than Publications for pages. Commented Oct 9, 2015 at 11:13
  • Thanks Alvin...The event system - On what event it should be? Page Movement or Page publishing.... its bit tricky.. Commented Oct 9, 2015 at 12:23
  • I'd recommend what @Nuno suggested--on save, that way you have a correct reference in the system. If we wanted a really user-friendly setup, editors would be able to paste in URLs that resolve to pages or components in the CMS, but that probably a bit of "gold plating" when editors are just asking for "page" linking. Commented Oct 12, 2015 at 13:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.