Validate Your Understanding of Sitecore Field Validation


Brandon Bruno


November 07, 2018


Validate Your Understanding of Sitecore Field Validation

User trust is a major issue for any digital system. In the case of Sitecore, content authors need to trust that content they enter into the CMS is displayed as they intended. While there are many steps between content entry and rendering, validation is one significant step that developers and administrators need to get right the first time.

Out of the box, Sitecore provides many ways to validated content, and I'm going to focus on two here:

  • Validation and Validation Text fields on the Standard Template
  • Validation Rules fields on the Template Field template

Validation and Validation Text

Both of these fields are on the Template Field data template, which all content fields must utilize. They look like standard text fields without any further explanation as to what they do:

The Validation field accepts a regular expression that matches against the field value. If that match fails, the Validation Text is dislpayed to the user. Simple, right? Here's an example of a validation configuration:

And here's the result of a failed validation:

This is pretty in-your-face: the author cannot save the content item until the error has been fixed.

There are numerous downsides to this approach, however:

  • Multiple validations don't run at once. If a template has multiple field validations, only the latest validation will be run and displayed, so a content author would have to click "save" until all validations pass.
  • Authors can't create draft content. Drafting content is an important step of the authoring process, and drafting content should be an error-filled process. Forcing authors to get their content 100% correct while drafting removes the benefits of iteration and revision.
  • No multilingual support. The Validation Text field is unversioned, which means that it doesn't support multiple languages, which means you can only use one language for validation messages.

The Validation and Validation Text fields are more-or-less legacy at this point. While they do work, there are better alternatives available in Validation Rules.

Validation Rules

Validation Rules provide highly-configurable and highly-customizable validation options for template fields. Instead of a simple regular expression, Validation Rules utilize a combination of backend code and parameters via the Content Editor. In typical Sitecore fashion, developers can modify or create their own validation logic, which means the sky's the limit for validating content.

Unlike the simpler Validation / Validation Text fields, Rules are configured in the content tree (/sitecore/system/Settings/Validation Rules). What's more, these rules can be applied in multiple places and stacked, so multiple rules can be evaluated at once:

Being able to use Validation Rules in multiple places is a huge benefit. In fact, different rules can be assigned to different usage points on the same field. For example, authors could draft content and use the Validation button (on the "Reivew" tab) to see if they are on the right track with their content. Then a different set of rules on the Workflow action would validate that content further and let others provide feedback based on the validation result. The following field is displaying errors right in the Content Editor:

Another advantage of Validation Rules: parameterized configuration. Validation Rules execute custom Sitecore processors on the backend, and these processors accept parameters from the rule definition item. This allows a generic "base" rule to be created by developers and have its behavior quickly changed based on what parameters are provided on the definition items. Sitecore does this with the "Result" parameter on all out of the box validators (See Brian Pedersen's blog post linked below for more information).

Which Should You Use?

The simplicity of the Validation + Validation Text fields may be tempting to quickly hack out validation on a simple field, but they are basically legacy fields at this point. All validation should be done with the infinitely more flexible Validation Rules.

For additional reading, check out:

Do you have questions, comments, or corrections for this post? Find me on Twitter: @BrandonMBruno