Friday, April 9, 2010

Push CMSs and Version Control

If you are choosing a CMS, you may want to look into whether it gives you a clean and obvious way to view differences between the managed content and the published/served content. This is not often a straightforward task. In fact, some CMSs have features that make this a nearly impossible task, because the content you view in the CMS does not have a 1:1 relationship with the published files in the case of a push CMS (possibly because there are transforms during the publish, etc.). Having audit history of changes made just within the CMS or just being able to view changes between versions of content in the CMS might be nice, but if it doesn't take into account what was actually published or is still viewable by the user or another application, those alone may not be sufficient.

A few examples of things that could go wrong if you don't have a good handle on what resides in the publish destination:

  • Users and applications can continue to access old content via deep-links.
  • You might not be aware of content that was corrupted on/after publish or was only partially-published.
For this reason, I'm a much bigger fan these days of the concept of a pull CMS (a CMS that serves content) as they seem to do a better job with "What you see is what you get". Caching and copying static rendered content from a pull CMS (a CMS that serves content) seems enough for most of the needs we'd have, even if it doesn't solve every problem.

No comments: