Swapping Parent-Child Publications in SDL Tridion

Tridion BluePrint changes can be difficult simply because of dependencies. Creating a BluePrint and some changes like inserting layers, adding branches, and changing priority are trivial.

You could even "copy" certain items up a BluePrint by changing releationships, making a copy, and rewiring the original setup. Again, the biggest catch is not having the right dependencies higher in the BluePrint (e.g. no templates to make pages in a content Publication)

Don't let anyone tell you BluePrint changes are impossible or extremely hard unless they understand BluePrinting and how your BluePrint is designed.

Here's an example where I swapped a Parent and Child relationship. Don't try this at home without a backup and a strong understanding of the Tridion Object Model (I'm not taking about the API).

You most likely have this in your BluePrint:

New Publication

Inserting a new Publication is simple:

1. Create a new Publication (250 in the example), adding the same 200 parent Publication before saving
2. Add the new 250 Publication as a parent to the 300 Publication

It's like cutting in line.

Swap

To perform a "swap" make the changes in reverse:

1. In 300 swap parents.
2. In 250 swap parents. 
3. Fix names.

What can go wrong?

For most issues, Tridion will prevent you from saving a Publication change that breaks a dependency, thing includes things like:

• Naming conflicts
• Links to items local to a parent Publication that would break
• Localized items in child Publications as seen below

But with clever timing or dumb luck you might be able to trick Tridion into saving an invalid reference. So always make a backup before making these types of changes and possibly validate relationships manually or with the Content Manager APIs (Core Service for the developers).

BluePrint Change in Under Five Minutes

After SDL Innovate 2014, I'm feeling bold enough to add audio and my smiling, drowsy, face. But notice the "Context Collapse" David Wesch describes. Without an audience, it's easy to draw inward.

Maybe I'll present to an SDL Buddy or when I'm more awake to liven up the presentation next time.

SDL Connected: Important Tridion Integration Questions

We learned about disruptive, yet innovative, technologies in the first day of SDL Connected, my team's knowledge sharing event. From cloud use seen in today's clients, to interesting projects our partners are working on, to updates in Microsoft development stack and our own Media Manager, it looks like 2014 and 2015 will be just as interesting as 2011. Get ready for the 5 Stages all over again (but it'll be easier this time, trust me).

Questions

Such updates should prompt three questions from any experienced Tridionaut:

1. How will it work with BluePrinting?
2. How will it work in DTAP?
3. How will it work in the Fifth (personal) and Sixth (training) environments? This includes licensing as well as a potential one-to-many relationship (as seen when starting cloud training instances).
4. Update: How will it work with Create, Read, Update, and Delete (plus search/list and publish)?

For example, for Media Manager, we have:

1. BluePrinted. The MediaManager Connector, as an External Content Library (ECL), is "somewhat BluePrint aware." Items are shared throughout a BluePrint and you can localize Tridion-side metadata if you have any configured. Most importantly, you can pass querystring parameters such as subtitle, voice over, and backslide (sl, vo, and bl respectively) to the unique distribution URL to get a shared (video) asset with the correct localization or translation.
2. Shared across DTAP. Unless you license multiple Media Manager accounts, DTAP could have multiple SDL Tridion environments share a Media Manager connection. Frank Taylor was asked the same question and has used a test folder of sorts in his implementations.
3. One-to-Many Environments. Personal and Training environments may also connect to the same Media Manager connection, which means training exercises should be unique to individuals. Personal naming conventions for creation can help, otherwise read-only access (using a distribution on a page, for example) is fine. With more awareness of the Media Manager Web service, I'm sure we can also work out smart ways to clean up and organize items.

Considerations for an Answer

Whether your background is system architecture, object-oriented design, data modeling, or content modeling, the same principles apply:

• What are the systems, classes/objects, data, or fields? How many are there?
• What are the relationships? Are there sets (-tuples) that belong together. Are the items related one-to-one (1:1), one-to-many (1:many), or many-to-many? Are there limits such as minimums or maximums?
• How will CRUD work? With CMS you also have to consider publishing and search in addition to create, read, update, and delete (P-SCRUD?). Update: I moved this up as an important fourth point.
• Which way do updates work (which way do the arrows point?)?
• Who will manage which parts and where?

BluePrinting, DTAP, and ad-hoc environments, got it?

Bonus: apparently I missed publishing my CRUD post. I guess it's a 2-for-1 kind of blogging day.

The 4 D's of BluePrinting "Promotion"

"Wouldn't it be great to easily move content up an SDL Tridion BluePrint?"

Assuming you made something in the wrong publication on accident and the set up was perfect, then you could script or automate such a move. This might be "easy" since the dependency rules are known and fairly simple on their own, but are you aware of the four main considerations?

1. Decisions
2. Distance (and Direction)
3. Dependencies
4. Directories

1. Decisions

First of all, who gets to make such moves? If this is a CMS admin task for you, then a script or even Content Porter is all you need.

If you want certain authors to be able to promote content, you'll want to confirm who will get this power and how much you will rely on the user's actual authorization (just like Content Porter) or if you'll impersonate an admin, which can lead to major changes without typical authorization checks.

2. Distance (and Direction)

The typical use cases for "moving something up" are either an accident or to share something popular across an organization. I've heard it called the, "ooh, we like that" requirement. Before considering a "BluePrint Promotion" extension, you have some simple ways to prevent both of these scenarios.

1. Remove read as needed from certain child publications and/or for certain authors. You can't make a mistake if the system prevents it.
2. Follow the practice of minimizing localization with a content-forward strategy and place content in a global publication. Use permissions to manage who gets to see what. This is how nearly every-system-that-is-not Tridion works.
3. Naming conventions can help with either of the above. You might even localize certain folders as a hint to authors (giving them some context in the CME, but be careful with code that relies on paths).

If these aren't enough for you, then be sure to handle this series of questions.

• Will you only handle parent (local) items or will you do something for localized or shared (children) items?
• If so, how far up or down will you move? To the first localized item in the BluePrint tree or all the way to the top or bottom? Is "apply this localized item to this Publication" part of your tool?
• If so, what happens to localized items up or down the tree? Do you unlocalize everything or might you save a copy of the localized items to re-apply the changes?

3. Dependencies

If you fully build out a BluePrint Promoting tool (first join PowerTools then) you must handle dependencies. In essence you're creating a version of Content Porter but in the CME. Content Porter is challenging to some because of these dependencies (see my post on top-down Tridion development).

To move content up you need to have the right folder, schema, linked items. In terms of decisions, you also need to choose if these dependencies will automatically be created or if you'll recursively handle each of these scenarios.

Also, if a dependency is missing in a higher Publication, should a single item fail or the entire attempt?

4. Directories

After figuring out who decides, where items will move to, and how you want to handle dependencies, you'll want to confirm the impact to directories throughout the BluePrint.

Mainly, will your new item conflict with items above or below it? Luckily Tridion handles this out-of-the-box for new items by preventing such issues*, but if you want to give the hypthetical BluePrint promotion user options, you'll have to decide what your tool should do.

Note: out-of-the-box, Tridion doesn't check for potential naming conflicts based on history or localized items. The one-off, rather confusing scenario you may want to handle or ignore is same-named items with matching paths could be different items if you localize a child item then re-use its old name (thanks to Nick for pointing this out).

So a multi-purpose content promotion tool has several considerations but isn't impossible. Content Porter for example does all this logic already and it's both configurable and transactional (allowing rollbacks). So my advice would be to only consider such a tool if you have a specific use case or you're ready to build a friendlier version of Content Porter. Maybe submit the idea to R&D, though I'm sure they've heard the request before.

What CMS teams probably need are a set of tools to maintain a BluePrint. For example:

• "Copy Up"
• "Swap in Place"
• "Replace Component Presentation in Page"
• "Clone Page" (including making copies of the CPs on it, just like Page Types)
• "Show/Hide sets of publications" -- this is already available through Publication Type filters in the Content Manager Explorer

But take a practical look at this. If you really want cross-publication functionality, where it doesn't matter what or where you link items to, then maybe you don't need that many publications or levels of publications.

If it's okay to share items and you know that some future content, template, widget, or whatever might be popular, then start by making it easy to share but hidden for everyone else. Then sharing is a matter of copying and pasting between folders, rather than handling the 4D's of BluePrinting Promotions.

Read more about SDL Tridion BluePrinting:

• Rather than promoting up, I flipped the scenario around and came up with a way to have a parent act as a long-running development track
• Forget parents and children, think of layers and BluePrints
• Make your own BluePrinting fridge-magnet kit
• A basic approach to making a Tridion BluePrint
• A sometimes missed tool to see how an item is used in a BluePrint (and it's not Where Used)
• Where to place keywords in a BluePrint
• Who I've looked to for BluePrinting guidance

Any other gotchas or recommendations? Are you doing BluePrinting Promotions? 

Find Your Way With Tridion's BluePrint Viewer

As you start working with a larger SDL Tridion BluePrint, especially in a multi-lingual setup, it gets harder knowing where and how your content and pages are used across publications.

The Where Used feature gets you most of this information, but also consider using the BluePrint Viewer to see and navigate to an item's variations in other publications. 

Open the viewer with either:

Select the Item > Home > BluePrint Hierarchy

Right-click Item > BluePrinting > BluePrint Hierarchy

Tip: open the viewer enough to see your selected item information in the bottom-left corner. The pop-up may hide this useful information if it's too small.

See checked-out and sharing status as well as where the item's original parent exists. It's GPS for your BluePrint!

Creating an SDL Tridion BluePrint

I've yet to achieve BluePrinting mastery, but I've learned some useful strategy and tactics along the way. First some SDL Tridion terms for the uninitiated:

• A Publication is a repository of content, the largest "container" in SDL Tridion. It may feel like a Web Cabinet to Documentum Web Publisher users, but it differs in how publications share or inherit items across publications.
• A BluePrint is the relationship of SDL Tridion publications, which have parent-child relationships in a hierarchy of sorts. The layers in this diagram are logical and don't necessarily represent actual levels in Tridion.
• A Shared item is a representation of an item in a child publication. All items are shared by default from the publication immediately above. They don't all have to be used in pages nor published below, though.
• Localization in Tridion is the ability to change the text in a component, while keeping its place on a page or relationship to other components.

Let's Make a BluePrint

A general approach at creating a BluePrint design is to:

1. Start with the scalability layer ("empty" parent) at the top with a Schemas publication below it.
2. Add a Content Publication.
3. Add a translation layer if needed. I typically assume so, but I've seen one-language BluePrints.
4. Add the publishable sites at the bottom and their localized child publications. You can use current Web domains to estimate the number of publications needed. You don't have to add them all to the diagram up front, though :-)
5. Add corresponding publications on the design side.

I personally like a flatter design layer with a design publication per publishable site, but some might prefer replicating the content relationships--meaning if you have a Master Publication to create Structure Groups and Pages with children publication, you'd have a Master Template Publication and two children publications on the design side. This assumes you're okay with localizing templates, though.

The rest of BluePrint design is revising, adding, and removing publications as needed. I personally prefer a minimalist approach with just enough separation and publications, but I've seen the "let's create the fully-exploded tree first" approach work as well.

Avoid a Bad BluePrint

You might have heard horror stories about "BluePrinting Gone Wild" and problems from bad BluePrint designs. Don't let this scare you off, it's really a matter of avoiding three scenarios:

1. A single publication. It's actually not impossible to pull this apart, but expect down time and lots of manual work including infrastructure changes and "re-doing" pages.
2. A missing scalability ("empty") parent. Simply because we can only add children publications. Not having an empty parent means any future high-level publications are forced to inherit whatever you have at the top (typically all the schemas from the schemas publication).
3. An over-engineered marvel of a diagram that achieves ultimate flexibility. Too much choice is really a bad thing.

Understand that if you have a central set of content authors (who also edit pages), jumping between publications can be tedious. Really consider the authoring context surrounding your content before attempting to create multiple content layers.

Changing a BluePrint

If you really need a future Publication layer, the biggest challenge is avoiding naming conflicts in folder and structure group paths. Also, pushing items down is easier that moving them up, especially with "dynamic" content. So adding a "Shared set of pages" or components above your publishable Publications is relatively easy later, but re-doing publications with pages is hard since templates are "in use."

Though we might segment regions at the lowest publication level (e.g. "Canadian French"), it gets problematic if we attempt to use BluePrinting and localization for personalization.

Read more on how Localization and Personalization differ on TridionDeveloper.com.

BluePrinting Naming Conventions. More Questions than Answers.

I wish I could explain the history behind various names I've seen in BluePrint design diagrams. But I have more questions than answers. Feel free to leave comments and/or explanations on your favorite BluePrint naming conventions.

000 Empty Parent vs 000 Scalability Parent

• Form?
• Function?
• Habit? Was this diagram from a template or a copy of an existing BluePrint diagram?
• I've also seen the layer called " Scalability  " but the publication in it called Empty Parent.

010 Functionality vs 010 Schemas and Categories

• Does the name tell you what it's for or what to put in it?

020 Design vs 020 Layout

• Does either capture functionality as well?
• Is design a more sophisticated term?

040 www.createandbreak.net vs 040 Alvin's Blog

• www. because it's the publishing website?
• Or the function it serves?
• Does it matter? It's easy enough to rename, right?

Master, Standard, Global

• The word "Master" might make sense technologically (ever set the jumper settings on an old hard drive?), but can have strong negative connotations in the US
• There's also the genealogy metaphor with "Parent"
• I saw Standard on Manuel Garrido's post on BluePrinting and translation. "Standard Design" has a nice sound to it. 

100 vs 010 vs 10a and 10b

• I'm used to 010, but realize exactly how many layers do we want to be able to scale to?)
• SDL WCMS Senior Consultant Robert Mathieu pointed out the useful side affect of using suffixes in the naming convention--though theoretically at the same level, we can group Content Publications and Design publications in order alphabetically. I've also seen this achieved by prepending something like "Site - " before the publication name.
• I've also seen prefixing the numbers with letters.

I really don't mind what you use as long as it's easy to use, easy to maintain, and consistent within an organization if at all possible.

As long as you have some semblance of the classic BluePrint diagram, we're speaking the same language.

BluePrinting Metaphor Re-imagined

Have you ever heard, "BluePrinting is Tridion" or "Tridion is BluePrinting?" In terms of functionality, I submit that a SDL Tridion BluePrint is one of the most awesome and potentially-dangerous weapons you can wield in your Tridion toolkit. Think Sword of Omens with a light saber blade and the One Ring embedded in the handle.

So how do we approach this versatile and dangerous tool? By talking about... kids, of course! Here are some misaligned metaphors and not-so-new thoughts on BluePrinting.

Misaligned Metaphors

From BluePrint... to Genealogy?

David Adams, Director of Services Solutions at SDL and a recent Innovate speaker shared some interesting points on the "classic" BluePrinting metaphor with me and Kelly Thompson, Global Education Manager with SDL WCMS (this was sometime before for their Innovate speech). He mentioned we use  "blueprint," a fairly specific architectural term, but switch to genealogy and object-oriented programming when we explain BluePrinting to the business and IT, respectively. On top of that, the phrase "Empty Parent" is devoid of any positive connotation.

I'm imagining the typical teen-angst rant, "I hate you! I wish I was never born! You're such an empty parent!" followed by a slamming door.

Some of the BluePrint lexicon includes terms and concepts that really fit a different, but possibly old, core idea about design and architecture.

Tridion BluePrinting Use Case

I prefer the acronym WCMS. Coming from a Web development and IT background in a healthcare-related company, "CMS" means something completely different.

Here's a use case for Blueprinting and localization for websites that need to be reviewed by external reviewers such as Centers for Medicare & Medicaid Services (CMS). I had a chance to run the scenario by Tory Johnson, a Tridion Professional Services consultant (who earlier identified better ways to use the Tridion 2011 Criteria Objects). He gave me the impression that my following setup might work (or at least confirmed I know a little bit about BluePrinting technology), but do see caveats below before trying this at home... er work.

But first some background and terminology.

Tridion BluePrinting

The Tridion BluePrint model allows developers, designers, and content owners the ability to create publications (collections of content, templates, and functionality) that share (think inheritance... sort of) content, style, or behavior. The BluePrint consists of parent and child publications where content is shared down from parent to child. BluePrinting may mean different things to technical audiences versus the business.

The Tridion localization feature is very important to BluePrinting.

Content Localization

Localization is a Tridion feature that lets you create a "one-off" version of an item, that is then shared down the BluePrint hierarchy. This item will have (almost*) the same Tridion content management identifier (tcmid), will be linked from the same components, but will no longer (automatically) share the same content from its parent publication. After localization, the item will keep its own history and can be updated independent of its parent item.

*The publication part of the 3-part ID will differ between the shared item's tcmid in different publications.

BluePrinting plus localization makes Tridion a strong fit for scenarios where you need to deliver content in multiple languages or targeted to different regions. But it's more than that, a well-designed BluePrint lets teams take the "component + component template = component presentation" concept all the way up to the publication level, where "Content Publication + Template Publication = Website Publication." Read on for an idea I worked on for a colleague (and yes, he gave me that "what?" look after we set it up).

Review Scenario

If you maintain a near-duplicate website for internal or external review, a simple solution is to simply publish content to the site. When it is approved, you can then publish this to the live site.

There's a problem, however, if you have a site that needs to be more than just website preview or user acceptance testing.

For Medicare (CMS) reviewed websites, there are restrictions on what content can be released. In this type of controlled scenario, only minor typos and select non-reviewed content are published to the Live site without CMS approval (from the technical side I'm not really sure what needs to be reviewed--the business side knows more, but this setup lets them pick-and-choose what and how things get updated).

Rather than having editors use versioning or edit history to control what gets published, a separate publication, higher in the blueprint can be used to separate the new yet-to-be-approved changes for the next iteration from the current live site.

Assuming a year-long iteration that begins in the New Year ("1/1 as a date is a hard deadline for many health or benefit-driven programs"), we start off with two publications:

• Review Website Publication, which is a parent of...
• Live Website Publication

In actuality we wouldn't use "Live" for the publication name since it might be confused with the live www. website or with the "Live" publication target (which publishes to the live www. website). Since the BluePrint is listed alphabetically, you might have names like "0035 MySuperMedicareProgram (CMS-Review)" and "040 MySuperMedicareProgram."

When the blueprint is first set up both sites are exactly the same. Review (this is not Preview) and Live have the same content shared down through the BluePrint.

1. To create the CMS Review site, everything is set up the same as the Live site and all currently Live content is published.
2. To make changes for approval for the next year, content owners determine the type of change:

New

Proposed content, new layout, and major changes can be made by first creating the proposed change (or localizing the Live Website version first if the items exist) and then publishing the changes. These new items shouldn't be published to the Live Website until approved and any localized items will keep their old approved versions unchanged regardless of how many revisions the Review Website goes through.

Fix in Both

A "must fix immediately" minor typo can be updated in the Review publication and published from Review and again in its child publication. If this typo fix applies to something that has been localized, content editors would update the Live Website localized item, then manually make the same correction to the Preview Website "proposed" item as needed.

Year-End or Approved

When CMS (Medicare) approves a change for the Review Website Publication, the content owners and their developers would:
1. publish new items that don't have shared localized versions
2. unlocalize items in the Live Website Publication, which will wipe out any localized edits and replace the items with their Medicare-approved versions
3. publish the now-matching (unlocalized) components to Live and start over with both sites matching
A content clean-up and a review of which items never received approval might also be helpful after the go-live date. :-)

Issues and Caveats

I helped set this BluePrint change in a production environment, but have not seen how it works in practical use (I've since changed teams a few times and haven't heard any issues--which strongly suggests it's not being used). The concept is sound, but I suspect there would be issues with the following.
1. Training -- when should you localize (probably everything in the Live Site at the start of the year or iteration, but always before an edit)?
2. Troubleshooting -- with content coming from two or more places, the ability to localize at different levels, and the fact that content owners sometimes forget to publish, I can imagine a few "hey, my page doesn't match my last change" type emails.
3. Support -- a Tridion BluePrint really needs to match the needs of the content. Apparently some organizations want to set up a BluePrint to match an org chart (really?), which is friendly fodder for another blog post. Like any other powerful and flexible technology, BluePrinting shouldn't be underestimated and it isn't something typical business analysts, programmers, or other support roles would understand right away. It's not quite inheritance, nor do the terms "share" and "localize" do it justice.
Watch out for confusion or misunderstandings around:
• Preview vs Review
• Tridion Publication versus Website
• The word "Publish" (component? page? .NET site?), but this isn't unique to BluePrinting!
  Terminology (feel free to point out any inconsistencies above)

If you have internal content owners publishing content for Review's Preview before it gets published to Preview's Live for CMS review of the WCMS-enabled content before it ever goes out to Live's Preview and Live's Live site, someone is bound to become confused.