Tridion Content Port between publications which are different

Question

I have 2 publication trees in a single Tridion Content Manager 2009 instance

I need to port one set of content (Schemas, Components, etc) from one tree to the next. None of the trees share any common publication so we have something like this

PUB_A              --->           PUB_C   (Schemas)
   PUB_B                              PUB_D   (Components)

I can export the content OK, but nothing exists in PUB_C / D (obviously the publication names are completely different). These components are horribly nested from a legacy website so recreating them is not really an option I want to explore.

Can I use the Content Porter to do this and have it create my items in the new publication? This seems like something it should be able to do but I'm struggling to get my head round the Mapping, tried renaming the "importTarget" attrib in the mapping file but it still insists on trying to reimport to the same as the source export.

Thanks

Rebane

Answer 1

You can use Content Porter to do this. First you need to rename the source Publications to something different, e.g. PUB_A_TEMP, PUB_B_TEMP. Then you need to rename your target Publications to have the original names of the source Publications, e.g. PUB_C > PUB_A, PUB_D > PUB_B. You can then run your CP import. Once the import has completed then you can rename the Publications back to the original values, starting by renaming the target Publications.

Bashibazouk

Hi Jeremy, I am doing this on a production system; can you give me a brief assessment of any risks that I should be aware of by doing this? – Rebane

Good question. I would certainly recommend restricting access while the Publications are renamed (if possible). It could be confusing to the users... Other than that the only thing I can think of would be any automation tied in to the name of the Publication, if there is any. – Bashibazouk

Yes, this is a kludge, but it's the best kludge in town! Since the beginning of time, no-one has ever succeeded in grokking the mapping file. In older versions of content porter you could work round the problem by running the export and then doing a global search and replace on the various Xml files in the export. With the current Content Porter, this is no longer possible. The mapping feature is still there, and still, nobody knows how to use it. (Or maybe I'm wrong there, and someone will pop up with clear instructions for how to do it that way!) – Lymphangitis

Gave up on this in the end, the dependency tree was so big that I'd end up repeating most of the old schemas and templates just to get it done. The lack of a simple way to move content and schemas through a Blueprint is one of my biggest frustrations with Tridion. After all is said and done it's just a DB storing XML! – Rebane

On a 2009 system consider the PowerTools Cross Copier. I agree moving things up and down a BluePrint could be easier, but across might still be challenging since the dependencies are per-item and include everything from keywords to pages. By separating design from content from definition (and context), we do have the trade-off that moves and ports take some thought. – Overprint

Answer 2

Use importContext attribute

In Content Porter up through SP1, the mappings.xml controls the old-to-new location mapping.

• Change the importContext attributes to move items.
• Though it doesn't apply here, you could also use importTitle to change the destination name.
• Be sure to "url encode" the publication names set in importContext (replace spaces with %20 and dashes with %2D). Content Porter failed when I set these attributes wrong--it's safe to edit and try again.
• We can't create new items, but we can move them within a system.

Note that we can't move entire publications, we set these per item.

Tip: after getting the mapping right, make the changes using your favorite search and replace technique. I got this move to work once or twice and the biggest issue was typos.

Example change: <tcccp:Mapping exportContext="/Publication/Building%20Blocks" exportTitle="component.xml" importContext="/Destination%20%Pub" importTitle="" />

Port Parts at a Time

For fairly clean content ports and to test mapping changes, it helps to break things down by dependency from the most basic template building blocks and up.

For example, I'd typically focus on one or two sets of the following.

1. Keywords (and Categories if needed)
2. Embeddable schema
3. Regular schema
4. Components and/or Templates
5. Pages

The biggest challenge with this kind of un-connected move might be dependencies, namely issues with moving a schema that's in use. Though I'm not entirely sure if CP will outright fail. If there's a shared parent, then moving schema up *might* work.

Relevant details:

• Content Porter SP2 temp files--I believe SP2 adds a temporary .ifmappings -- worth checking out if settings don't seem to "stick"
• Content Porter SP2 mapping details
• Content Porter SP1 mapping details
• See TridionWorld for older versions.

Overprint