3

We have a requirement to link pages within Tridion across multiple publications. We would need this feature to be available for some websites (200 pages) that we are migrating from another CMS tool.

Here are some of the options and some thoughts on each of them. I wanted to get some feedback from the community based on everyone's experience in the past. Are there any easier options? Should I be aware of any drawbacks that either of the approach would bring?

Option 1

Content: Create a Master Publication and have all of the child publications inherit from it.

Publish / Unpublish: Using Custom resolver, we would be able to publish items / pages from the master publications to specific child publications (than all Child Publication). This would be a customization.

Pros and Cons: Publishing is controlled and maintains all of Tridion governance. One of the disadvantages is that the child publications would see any pages or structure groups created in the parent publication. Although, Tridion security would permit us to get around who could see these pages in the CME, there could be a situation where a publisher creates a SG or page with the same name as in the parent causing Tridion to throw an error.

Option 2

Content: Create a Master publication which will publish Dynamic Component Presentations with metadata

Publish / Unpublish: DCP will be published with the metadata

Pros and Cons: Custom layer is involved. We would use a dynamic custom application that would render the page for that child website based on the metadata that was published. One of the disadvantages is that authors would NOT be able to see references of any of the pages available for a website within the CME. They would like to see the pages which were created ONLY for them

Option 3

Content: Create an orphan publication and create pages in the other publications based on the metadata and using event system (without having Blueprint conflicts)

Publish / Unpublish: Publishers will publish items from the reference publications directly

Pros and Cons: Whenever a publisher creates a page in the orphan publication and define metadata (check boxes of the list of the publications that this page should be created at), Tridion custom event will be responsible to create a local copy of the page in each on the publications checked during creation. The publishers will have to publish the items directly from each of the reference publications since the copy of the page will be local to that publication. Publishers should also be aware that the page can be modified in 2 locations, technically, i.e; the orphan and the local publication. We would have a new TCM URI but that should not impact our requirement

References: I looked at the following answers (1 and 2) to confirm that we can create a page in another publication using custom APIs.

Update 1

The number of websites in scope for this is about 5. Content for these website publication will be created at a global level and hence all of the websites in scope will inherit the content from this level. The structure group and pages is where there are reservations in a child publication inheriting all of the master or the parent publication's SGs and pages.

Editors Perspective: From a editors perspective, they should be able to create a page and choose where it needs to go (website1 -5) and save. Tridion should then either create the pages or make it available ONLY in those Publication chosen by the editor in the website layer.

Website Behaviour: First website: http://www.mywebsite1.com/mypages/1.htm, http://www.mywebsite1.com/mypages/2.htm, http://www.mywebsite1.com/mypages/3.htm Second website: http://www.mywebsite2.com/mypages/2.htm, http://www.mywebsite2.com/mypages/4.htm, Third Website: http://www.mywebsite3.com/mypages/3.htm (Can be the same as the 3.htm from website 1 or a different one too), http://www.mywebsite3.com/mypages/4.htm, http://www.mywebsite3.com/mypages/5.htm

enter image description here

  • 2
    Here is an answer on the same subject from a few years ago: tridion.stackexchange.com/questions/1264/… – Nickoli Roussakov Oct 28 '15 at 22:23
  • Hi Nickoli.. Thanks for your response! My use case would need cross publication reference of pages as well. I see the below your option as a subset of option 2 (listed above) but the authors / publishers would need to be able to browse Tridion CME and notice any pages i.e; the logic that we build with content delivery now becomes a content manager logic. Let me know if my understanding is incorrect! If you agree, I will add the above answer as a reference to option 2, with the pros and cons with this use case for better clarity. – Shiva Oct 29 '15 at 12:34
  • 1
    I see a requirement for editors to be able to choose which content and pages are published to which Publications. It looks like you also want to share content and avoid naming conflicts in the BluePrint. How would the cross-Publication linking work from an editor's perspective (as an ideal process)? What is the website behavior? – Alvin Reyes Oct 29 '15 at 13:06
  • Hi Alvin, I have updated the behavior and the BP scenarios in the question! – Shiva Oct 29 '15 at 14:22
2

I would guess this might be product information or other content that might be shared, but not necessarily wanted in every child publication. I would recommend a solution based on the following.

Option 1: Publishing controls delivery visibility on website

  • Low development cost; simple to understand and troubleshoot
  • Consider a "virtual" way to maintain what gets published where either with:
    • Bundles to let local editors control what's meant for their site
    • Metadata for search (and maybe virtual folders)

Train editors to only publish from Bundles

Option 2: Delivery controls visibility

  • Might be a good fit for "library" types of content (single folder, one Schema, and includes its own SEO fields) such as:
    • Articles
    • Blog posts
    • Simple (product) description pages
  • Not a good fit if editors need to:
    • Add additional content to pages
    • Change navigation for pages
    • Control what displays through page publishing

Bundles or metadata can also help here to keep track of what content is meant for which channel.

Option 3: Shared content, copied pages

  • Clean separation in the CME and site
  • Requires development and maintenance of Content Manager code, be sure to cover:
    • BluePrinting (translation, configuring this, etc), but also
    • DTAP (don't hard-code identifiers)
    • CRUD (what happens when a page or its content changes?)
  • Consolidating pages may be hard latter (merging shared pages)

You could also look into GUI extensions (display pages meant for a child Publication differently), but I'd confirm two things first:

  1. What do editors prefer--they have to live with the solution
  2. What will happen most of the time
    • If pages are mostly shared, I'd go for Option 1.
    • If it's a good fit for dynamic content, Option 2 is okay.
    • If the content should be available in the CMS but the pages are mostly different, then create "orphan" pages.
  • Very well put Alvin! I will vet out the use cases and update the question with my comments as well. – Shiva Oct 30 '15 at 13:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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