Content Porter got you down, friend? You’ve got components from a lower environment that need to be migrated to a staging or production environment, but the schema they’re based on has changes that aren’t ready for prime time yet. It’s 1 am, and if you don’t get this solved by the start of business the sky will fall.
Panic! Don’t panic. This has a very simple solution.
Once upon a time…
There livedÂ a component schema named Steve, a wondrous little schema containingÂ fields that pertainedÂ to page SEO. Steve had aÂ field for keywords, a field for description, and a field for page title. Steve was a simple schema, upon which many components were created. HeÂ and his offspring were promoted from their original Development environment all the way to Production, and for a time it was good.
Until one day, when the brilliantÂ developer Robtimus Prime added an optional field to Steve that would help him populate an element in the markup for accessibility. Despite having modified Steve way down in the Development environment, and despite having labeled the field as “DO NOT USE,” a nefarious band of content editors began using Steve’s new field across many components unbeknownst to anyone!
Months passed, and it was time to promote those components to Production again. Steve was believed to have not changed, and so the heroic Tridion administrators, with the help of the mighty
sword Excalibur toolÂ Content Porter, exported Steve’s components from the Development environment without Steve himself. When they attempted toÂ import the components into Production… Oh no! The import failed!
The components contained extra fields that were present in the schema at Development, but weren’t present in the schema at the Production environment. When saving a component, Tridion validates itsÂ XML against what it knows of that component, the schema. When the schema differs from the component on saveÂ Tridion will reject it. Behind the scenes Content Porter isn’t doing anything magical.Â It’s doing the exact same steps that a content editor would to add or update an item; it’s just not using the user interface to do it. When a new component is created or an existing one updated, the same validations are fired off whether it’s a Content Porter import or Johnny Appleseed over in Marketing using the Tridion CM in Internet Exploder. To put it another way, this would be akin to manually modifying a component’s XML in the Source tab of the interface by inserting XML nodes that the schema doesn’t include. Validation will fail, and the save will be rejected.
This is going to sound crazy! Embrace the modified schema, and port it! Use Content Porter to port the schema to the new environment along with its components. After successfully importing the components, revert the schema in the new environment. That’s right: revert the one that was just portedÂ (italicized for dramatic effect). Any invalid field content stored in components will remain until the next time they’re opened, at which time Tridion will just omit them entirely.
And that’s it! Post questions or comments below, and thanks for playing along!
All characters appearing in this work are fictitious. Any resemblance to real persons, living or (un)dead, is purely coincidental.