SDL Tridion Component Synchronizer is Dead. Long live ComponentSynchronizer!

When you change SDL Tridion content definitions or schemas, the content based on them do not update automatically. Read about schema changes in this post if the fact is new to you.

Many underestimate how "easy" synchronizing content is. The GUI does it automatically and the old PowerTools used a little XSLT, some scripts calls, and a custom page. I've seen at least four restarts by various Tridionauts which supports my "easier-than-it-looks" theory.

Update and Clarification: see Dominic's point on the PowerShell Component Synchronizer. I agree with all of his points but still think the PowerTools Component Synchronizer was harder than it looked.

And strangely, many have assumed this feature isn't in the product or that we need to re-invent the logic. It's the Groundhog Day (Movie) challenge for the Tridion community.  Content Porter can sync content and since SDL Tridion 2013 SP1, we have an API for Component Synchronizer. See the details in Eric Huiza'a post.

What's needed next is...

...absolutely nothing. After more than two years, we've had the partial attempts and no sponsors asking for a PowerTools Component Synchronizer.

So if you're interested, by the Midas Rule go for it. Ideally you'd work with those that worked on this before and avoid re-inventing the approach (again).

But this does not have to be in the PowerTools. PowerTools shouldn't be a dependency keeping you from adjusting your content model as needed.

Synchronization is just a step to something better. I want tools that report on, as well as help you adjust, a content model. See this fascinating post by colleague Miguel Miguelez on what you might decipher from an existing content model with the right query or see my start at a BA Toolkit of sorts that generates csv files detailing your authorization model.

So maybe assuming Component Synchronization is "dead" is well, overkill. Maybe Component Synchronization is simply assumed or trivial. I want a "Component Re-arranger" where you can split and combine schemas, renaming fields as you please. Synchronization, like Copy & Paste is easy. Change... well now that's hard.


  1. I'm not sure if the "restarts" support the "easier than it looks" theory. As you know, I built the "working end" of a component synchroniser for the power tools project (mostly a port of the XSLT approach used in the old tools), and stopped short of integrating it as a GUI extension. It works perfectly well from the command line - which was where my Midas itch stopped being worth scratching. We've had a couple of enquiries about a component synchroniser, and when people are pointed in that direction, they seem to lose interest. At least as far as I know, no-one has used it in anger - although that's hard to confirm for an open-source project. This rather supports the theory that actually - generic tooling for component synchronisation is fairly useless. On most projects, you won't need it, and if you do want it, then your intimate knowledge of your own technical requirements will make a non-generic approach fairly easy. The new API support also seems to confirm that a user-interface is just window dressing on what, after all, is always going to be a technical operation.

  2. I think I arrive to the same conclusion by the end of this post: a generic synchronizer isn't enough (or useless).

    I referenced your comment in the post--thanks for the feedback and the PowerShell Synchronizer. ;-)


Feel free to share your thoughts below.

Some HTML allowed including links such as: <a href="link">link text</a>.