A Missing Field Type - Part 2

In part 1 of this series I made an argument that Sitecore needs a new field type that would support workflow and versioning without adding language variance. Let’s see why.


Presentation details were Shared in older versions of Sitecore . It means no versioning, no workflow support, and no language variance. A page item under workflow will not publish its latest version until the workflow reaches the final state. Too bad for the Shared fields though. Once modified, the change will be picked up by the smart or full publish. A threat is very much real - just like I hope you are using workflows, I also hope that you are using scheduled publishing agents and don’t let your authors work as admins.

Versioned Layouts

Sitecore 8 introduced versioned layouts. Presentation details can now be both Shared and Final and the end result is merged at run time. The promise of versioned layouts is to workflow-enable the presentation details and to also allow language variance. The problem is - you can’t get one without the other.

One Language

I stand corrected. You actually can have workflow support without language variance. Just don’t translate your content. If your site only supports one language, you’ll enjoy using versioned layouts. I would even suggest that you forego the good old __Renderings (Shared layout) altogether to ensure proper versioning and workflow support of your presentation. Rejoice!


There are more than one way to build a multilingual site in Sitecore. Previously, if your layout was the same across languages you could safely translate a single content tree. Now you can do even more with a single content tree thanks to version layouts that can easily accommodate certain language variances. If the content varies significantly and translated sites feel more like distinct online properties, you will probably build parallel content structures but let’s focus on a more common example.

Single content tree. Translated. Under a workflow. Scheduled publishing agents. Best practices. Right?

A change to the Shared portion of the layout is susceptible to the same accidental publishing as the entire layout in older version of Sitecore.

Understood. Can we use final layouts?

A change to the Versioned portion of the layout, while workflow controlled and versioned, only affects a single language.

Wait a minute. Can I or can I not safely and soundly workflow control my layout?

The answer is - it depends. If your presentation details are exactly the same across all translations, then you probably can. You will need language fallback and a little discipline. Language fallback will propagate the value from one language to another provided that the value in another language is null. An empty layout is not null (try resetting it and look at the raw value if you wonder what it is) so there goes the first wrinkle. Any accidental (or not) change to the layout in Experience Editor done not in context of the primary language will break the fallback chain.

Tough. And what if you have a layout variance in a given language?

The Missing Field Type

Well, like I said, Sitecore needs another field type - Workflowed. And I wouldn’t worry about migration issues to be honest. One of the recent updates changed the way clones are handled. A breaking change indeed. Migration instructions included a simple SQL script to upmigrate all clones. Easy, no big deal. Same could be done to legacy __Renderings if field type changed from Shared to a new Workflowed.

Call your congressman.

Something occurred to me while I was writing this small series. There is another best practice that has a very complicated relationship with the workflow. We embrace it and bet our content architectures on it and yet it gets in a way of a smooth and predictable editorial process. Datasorces. Why is it? Can something be done about it?

Next time on this blog. Stay tuned!

p.s. You can also account for language variance in a layout with personalization by language but I would probably advise against it. Assuming, of course, that you are using marketing automation capabilities of Sitecore and specifically the A/B content testing. Algorithms that generate multivariate permutations and track test performance can’t tell the difference between a functional personalization and a marketing-driven experience variance. Hopefully I get to write about it some time later.

A Missing Field Type - Part 1

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 Shared, Unversioned, and Versioned is 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 - __Renderings.


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 Help section.


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 Shared fields. 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 Shared fields.

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.


Do you have a dedicated devops person on your team? Maybe you have a shared team of devops engineers? Do you hire for devops role and build centers of excellence (CoE) around it? These engineers are responsible for environment provisioning and builds, they create and maintain your CI/CD pipelines, they chose a specialization in Chef or PowerShell DSC or Gradle? If you are Rackspace or a Rackspace-wannabe, then you’re probably on the right track. And if you are not then I don’t think you are doing it right.

A dedicated DevOps role is basically ops co-located with devs. It’s a lot better than old school functional structure with ops and devs isolated but it’s not yet the DevOps nirvana.

Let’s make a step back for a second. What are we trying to achieve? Use the modern infrastructure-as-code toolset? Be more agile in the operational aspects? Deliver continuously? Or maybe we also want shared responsibility? Devs thinking about Ops concerns (migration, monitoring, scalability, automation, instrumentation, upgrades, business continuity) when writing code and designing systems, not after? Not just deliver continuously but do so with confidence? Maybe we also want to better our dev teams? Make them not only full stack but also cross stack?

Expose your dev teams to ops concerns. Make them orchestrate provisioning and automate builds. Make them monitor and instrument their deployments. Have them learn some Chef, Shell, Powershell, Gradle, Buildr, Capistrano, Whathaveyou. It will only make better technologists out of them. Dedicate ops to run the underlying stacks (the vSpheres, and Swarms, and Kuberneteses of the world), to expose custom infrastructure concerns as code, to maintain an ever-growing repository of scripts and images and containers, to establish best practices. Using it should be part of the dev role.

What doesn’t kill you makes you stronger. Or so it should.


Digital Experience Platforms. Where To?

I have been actively looking at a number of digital experience platforms and services lately. Some I have very recent encounters with and some are relatively new to me. As I put them all together on one plate and look at their roadmaps, certain trends become very apparent. In this blog post I would like to quickly share my thoughts about the state of the union in digital experience platforms and also make some projections as to where I believe we’re headed.

The Stage

Have you seen the most recent Forrester Wave for the Digital Experience Platforms? Let’s put it side by side with the Gartner’s latest magic quadrant for Web Content Management:

Gartner Magic Quadrant WCM 2015 and The Forrester Wave Digital Experience Platforms Q4 2015

Thanks to Adobe and Sitecore I learned to use Experience Management where I would previously say Content Management. The opposite is also true - I learned to think that Experience Management is primarily done by Content Management systems. I guess it’s time to re-learn what experience management means. While Sitecore and Adobe are clearly leading the pack on the Web Content Management field, SAP Hybris, Demandware, and Salesforce are breathing down their necks if not surpassing them in the Digital Experience Platforms race.

The proliferation of touchpoints and the emergence of new forms of digital interactions have blurred the lines between content, marketing, commerce, analytics, and mobile.

Acquia has an integrated content and commerce story. Sitecore is catching up with the acquisition of the Commerce Server and a very recent strategic partnership with the Dynamics AX. While Adobe AEM doesn’t have a pre-integrated transactional commerce backend yet, it has a very compelling integration-ready experience-driven commerce story. And now it also has a unique position in the world of enterprise mobile apps with their recent overhaul of the Digital Publishing Suite and AEM Apps (it is now AEM Mobile).

The appearance of Salesforce in the strong performers wave surprised me so I went to check their offering. They don’t have transactional commerce and neither do they have content management - just like I remember them - but they do have a very strong B2C and B2B digital marketing suite, analytics, unique apps platform, and have recently acquired prediction.io.


Just a couple weeks ago SAP Hybris had their clients and partners summit in Munich, Germany. Take a closer look at their new products announcement - Hybris Marketing, Hybris Profile, Hybris CX. They are clearly expanding their portfolio to cover more ground in the big experience management space. No wonder Hybris is right in the middle of the strong performers wave and I’m sure will keep climbing.

Projection #1. I believe we are going to see less and less cross-vendor integrated-at-the-core solutions powering digital business transformations. We will sure see integrations, especially where companies have previous investments not yet capitalized on, but the majority of greenfield overhauls will be primarily single vendor led or at least centered around one suite of products. The shape of it will change as well.


Retail was traditionally one of the main focus for the e-commerce vendors and lately for the larger ecosystem of digital experience management players. That said, retail is far from being the only industry that converts users, provides shopping experience, or otherwise engages customers online. Entertainment, Travel, Utilities, Automotive - just to name a few - are next in line.

SAP Hybris, for example, is planning on releasing a number of new industry-focused accelerators to augment their traditional set of B2C, B2B, and Telco. Once one player starts targeting the industries with tailored solutions the others will likely follow.

Projection #2. It will be increasingly more important to be able to accelerate the build. It will shorten the expected ROI cycle and help win the business over. Implementation partners were the ones doing it traditionally but I believe leading digital experience product vendors will be getting into the driver seat. It will naturally shift the cost from implementation services to licenses and as-a-service subscriptions.


Speaking about as-a-service. On-premise got old long time ago. IaaS has been commoditized and those who run on-premise most of the time just run their own IaaS on in-house-virtualized hardware. All vendors I mentioned have as-a-service offerings but they differ in flavor and in the direction they are going.

Sitecore is very naturally focusing on Azure PaaS but it’s not yet a managed services offering - it’s rather a technology enablement. Adobe goes a little further with the AEM managed services. So does Acquia. Oh, and all Adobe Marketing Cloud products are, of course, as-a-service. Salesforce pioneered the model, they now own heroku, and all their products are naturally as-a-service.

But wait, There’s more!

Have you looked at YaaS - Hybris as a service? Unlike other as-a-service offerings that I mentioned YaaS is actually a marketplace. Functionalities such as Loyalty, Coupons, Order Management, for example, packaged and priced as-a-service. It’s very young and we’re yet to see if it has legs but SAP makes big investments and bets its Hybris strategy on it.

What do you think in context of digital experience when you hear IBM? If you think WebSphere Commerce please think again. Look at IBM Bluemix and the application services catalog. My first impression was that it’s like heroku but then I realized that it goes beyond infrastructure and application development. Take a closer look at Mobile Application Content Manager, for example.

Last but not least, please take a closer look at Azure. Here’s fersh from the press - new Dynamics AX is Azure-first. And it’s also a marketplace where third parties can host industry-tailored services and solutions.

Projection #3. I believe we will see further commoditization of implementation and operation aspects of digital business platforms. It will happen via advanced and innovative as-a-service strategies well beyond technology enablement and managed services. Vendors will have to keep up before someone releases their current key differentiators as-a-service. Imlementation partners will have to pivot their models towards service providers as well.


Machine Learning, Natural Language Understanding, Real-Time Analytics are no longer bleeding edge R&D. So much so that Amazon published Alexa Skills SDK and opened a marketplace and you can do Cognitive Commerce as-a-service. No wonder Salesforce rushed to acquire prediction.io and Sitecore is tinkering with Azure ML for segmentation and multivariate content testing.

Everything is elastic and will soon be as-a-service and soon after will become cognitive. 360 degree customer view will be “so yesterday”, flat, static. Businesses will be pursuing a predictive-real-time-3D customer view instead. That’s what the next breed of cloud-first machine-learning-powered digital experience platform with voice-first interface will promise you.

Projection 4. It’s only going to get better. And it’s going to happen fast.

Exciting times!

Sitecore 8.1. Developer's Notes

I took a two months long hiatus from writing to transition into my new role at work. It’s all good now and I am back with an overdue post about Sitecore 8.1

Routes and the MVC Areas

Sitecore 8.1 has finally added native support for MVC areas. If you’ve used areas before (using this option, for example) you probably were calling AreaRegistration.RegisterAllAreas() during <initialize> and registering your routes in RegisterArea():

using System.Web.Mvc;

namespace Solution.Web.Areas.Site
public class SiteAreaRegistration : AreaRegistration
public override string AreaName
return "Site";

public override void RegisterArea(AreaRegistrationContext context)

// Register your MVC routes here

You can now take your own area registration out. Or can you? Here’s how Sitecore changed the InitializeRoutes:

protected virtual void RegisterRoutes(RouteCollection routes, PipelineArgs args)

RouteCollectionExtensions.MapRoute(routes, MvcSettings.SitecoreRouteName ... );
this.SetDefaultValues(routes, args);

// <-- Pay attention to the order
this.SetRouteHandlers(routes, args);

// <-- This is new in 8.1


The problem is - area registration is called after route handlers have been set. I briefly mentioned the custom route handlers in my older blog post about Sitecore MVC routing mechanisms. This is what makes otherwise regular MVC routes Sitecore aware. No custom handlers on your routes means no mvc.* pipelines, no PageContext, no analytics.

All the routes that you were registering in RegisterArea() are now not part of the Sitecore MVC ceremonies. They are late to the party.

Read More

Digest of my Sitecore blogs

Before I launched this blog I was actively writing on www.jockstothecore.com and before that on pveller.blogspot.com

Heres’s a collection of everything I have pubished on JocksToTheCore in the last two years:

My Favorites

Sitecore 8 Versioned Layouts

Dynamic Product Details Pages

Sitecore 8 Experience Editor

To The Controller And Back

Web Forms For Marketers


Custom Field Types