Warning: this post is highly technical. Non-programmers, please avert your eyes.
Deane Barker (from Blend Interactive) and I have a running conversation about CMS architectures. One of the recurring topics is how content models and other configuration is managed. There are two high-level approaches: inside the repository and outside the repository. Both have their advantages and disadvantages.
- Managing content types outside the repository
My preferred approach is to manage content type definitions in files that can be maintained in a source code management system. This way you can replicate a content type definition to different environments without moving the content. Developers can keep up to date with changes made by their colleagues. Configuration can be tested on Development and QA before moving to production. There is no user-interface to get in the way. No repetitive configuration tasks. Everything is scriptable and can be automated. I especially like it when content types are actual code classes so you can add helper methods in addition to traditional fields. Of course, when you get into this, it is a slippery slope into a tightly coupled display tier that can execute that logic.
On the downside, it is often difficult to de-couple the content (which sits in the repository) from the content model (which defines the repository). When you push an updated content type to a site instance, you might need to change how the content is stored in the repository. This is more problematic in repositories that store content attributes as columns in a database. It is less of a problem in repositories that use XML or object databases (or name-value pairs in a relational database) where content from two different versions of the same model can coexist more easily.
If you do manage content type definitions outside of the repository, a good pattern to follow is data migrations, which was made popular by Ruby on Rails. I am using a similar migration framework for Django called South. Basically, each migration is a little program that has two methods: forward and back (“up” and “down” in RoR. “Forwards” and “backwards” in South) that can add, remove, and alter columns and also move data around. The forward updates the database, the backward reverts to the earlier version.
- Managing content types within the repository
Most CMSs follow the approach of managing the content type definitions inside the repository and provide an administrative interface to create and edit content types. This is really convenient when you have one instance of the application and you want to do something like add a new field. There is no syntax to know and application validation can stop you from doing anything stupid. Some CMSs allow you to version content type definitions so that you can revert an upgrade.
When you have multiple instances of your site, managing content types can be tedious and error prone if you need to go through the administrative interface of each instance and repeat your work. Of course, you can’t copy the entire repository from one instance unless you want to overwrite your content. If your CMS is designed in this way, you should look for a packaging system that allows you to export a content definition (and other configurations) so that it can be deployed to another instance. Many CMSs allow an instance to push a package directly over to another instance. The packaging system may also do some data manipulation (like setting a default value for a required new field).
Unless you are building your own custom CMS, this all may seem like an academic question. It really is quite philosophical: is configuration content that is managed inside the application or does it need to be managed as part of the application. The same thing goes for presentation templates (but that is another blog post). However, if you intend to select a CMS (like most people should), it is important to understand the choice that the CMS developers made and how they work around the limitations of their choice. If you are watching a demo, and you see the sales engineer smartly adding fields through a UI, you should ask if this is the only way to update the content model and if you can push a content type definition from one instance to another. If the sales engineer is working in a code editor, you need to ask how the content is updated when a model update is deployed.
Related posts:
- CMS Architecture: Managing Presentation Templates Another geeky post… In my last post, I described the...
- Code moves forward. Content moves backward. One of the primary functions of a web content management...
- Finally, Drupal Gets Deployment Greg Dunlap, over at Palantir, has a post introducing a...
- Managing Projects with Trac [This is a continuation of a sporadic series that started...
- NoSQL Deja Vu Around thirteen years ago, I helped build a prototype for...
Dexterity, the new framework for managing content types in Plone, marries these two concepts, allowing definition of type schemas through a web UI and subsequent dumping of it to version controlled code definitions. The model is fully roundtrip, and provides the advantages of both approaches above.
http://plone.org/products/dexterity
We habitually use a home-made set of “Daisy project tools” during our turnkey projects which make use of the export/import scripts that come with Daisy (http://www.daisycms.org/daisydocs-2_3/impexp/332-cd.html) That way, we can define the document schema using the admin UI, export as an XML document and possibly tweak that if needed. Having your CMS config under version control is paramount when upgrading between product releases, and makes sense when setting up a dev/test/deploy staged environment. We also prefer to have a plain file-based config format – I realize others store config in a database but we find that slightly more cumbersome (and often causes an unnecessary mix-up between config and data). Nice post!
In SDL Tridion, content types are known as schemas. These map directly to XML schemas, and for most scenarios, schemas are editable via a user interface that allows for adding fields, etc. Schemas are held in the repository. In addition to UI-based editing, you can also manipulate them via the API and/pr move them between instances using replication tools such as SDL Tridion Content Porter.
EPiServer has an great open-source project now called PageTypeBuilder (http://pagetypebuilder.codeplex.com/) which moves content type definitions from the database and into code files in the source.
There are multiple benefits:
1. You can extend types, like in OO programming.
2. Definitions are now versionable.
3. The content objects you get in code are strongly typed — they have actual, typed properties for the defined properties of the type.
I’m very much leaning in this direction in general, these days. I thought you were nuts the first time I saw how you did it in Plone, but I’m drinking the Koolaid on it.