If you haven’t read my post from last year about Sitecore’s Items, Fields, Versions, and Languages I would recommend that you do it first. In this post i will make an argument that
Versionedis not enough and we need another field type -
Workflowed. Even if only for one particular field.
Shared fields are very basic. Value of a shared field has no language variance and no history. It cannot be workflow controlled and it cannot be restored to a previous value. You probably rarely use them on content items managed by the authoring teams exactly for the reasons outlined. You will find them, however, on the
Standard Template and throughout the Sitecore internals in general.
Things that are inherently global and stable, things that an item either has or doesn’t have, things that never vary across translations, things that don’t change how an item is rendered - these are the qualities of a
shared field. Good examples -
__Is Bucket and
__Enforce version presence. Bad example -
Unversioned fields are rare these days. Value of an unversioned field will differ across translations but it still has no history and no workflow support. Same qualities as
Shared basically plus a per-language variance. An attribute of an item has to be textual or otherwise different per language and yet be global and stable to warrant an unversioned field. Good example -
__Short description from the
The bread and butter of content items. Supports language translation, has history, and is subject to a workflow. What’s not to like? The majority of the fields you create should be
versioned. Well, at least they should have history and workflow support and what other choice you have then, right?
Having both language and version angles can sometimes produce friction. You can have former without the latter (the
Unversioned fields) but not the other way around. If you need history and workflow - and you do almost always need it - you have to also deal with the fact that each language translation has its own value.
I feel that we need one more field type.
Unversioned fields add the language (translation) dimension to the
Versioned fields add the version (history and workflow) dimension to the
Unversioned fields. What if I wanted history and workflow support without language variance? What if there was a
Workflowed field type that was subject to a workflow and supported history rollbacks but didn’t have the language angle? Basically, a version dimension added to the
A field without a language angle represents something that is the same across all translations. If you use
Shared field type you subject yourself to accidental publishing of new values while everything versioned is still in the draft state. If you use
Versioned field type you have to maintain the same value for all translations contract.
Why is it a problem? Next time on this blog. Stay tuned for Part 2.