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.
Ugh. This guy.
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 problem…
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.
The solution…
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.
Nice article! Really enjoyed the story.
One note that when porting a Schema to another environment, be careful with the namespaces of the Schemas. From my experience, if the namespaces are different, it will update the destination Schema with the namespace of the source Schema. This is good news from your Components from the source CMS, but bad news for the Components in the destination. This is one of the reasons to give your Schemas a meaningful namespace and not accept the default uuid… that Tridion provides when creating new Schemas. Of course, if you’ve done a DB restore from Prod back to Acceptance and Dev then it shouldn’t be an issue, since all Schemas would have the same root namespace.
Interesting point Rob, I think the option that allows Content Porter to ‘synchorise components’ should reduce this risk but it’s a fair point that (I think) it’s good practice to not use the GUID for the schema namespace.
I know that even with the magical synchornisastion I have had problems particularly with deeply nested patterns.
You had a backup anyway, right? I’m sure you did. But just in case anyone reading this is considering content portering into production without a backup, let this serve as a lesson to them. Great that you found an answer, but I bet that “heh – I have a backup” feeling was a comfort to you at the time.
And even more so now that content porter can do synchronisation too. Make sure there’s a backup, guys!
Nice point that you don’t always have to synchronize Components, Rob.
One thing to also check when delaying the sync is publishing, especially rendering. For things like root node changes or template logic that depend on fields (I believe missing fields will work but loops fail, right?), we won’t see an issue until template run (preview or publishing).