Hide fields on specific Sitecore Items

There are certain scenarios when working with Sitecore when you need to hide fields on specific Sitecore items in the content editor. Its worth noting the solution shown below actually hides things rather than correcting the template hierarchy. For certain scenarios this may be a quicker solution which doesn’t require editing any of the existing content of the Sitecore tree.

The two key aspects are:

  • Configuring the rules for hiding and showing fields
  • Applying the rules to the ui via the getContentEditorFields pipeline

As per normal, Sitecore makes this easy once you know which pipelines to tap into. During the lifecycle of an item in the content editor several pipelines run – the difference here is some are from Sitecore.Client rather than the kernel. In the example shown below the bulk of the code is around querying xml (config) for the rules. This could come from any datastore.

The rules I adopted were pretty simple and based around the following idea. Either you always want to show or always want to hide the field. You would then want to decide the opposite case eg when to show the field based on a set of rules – here it uses the context item as the starting point for each rule.

An example rule then becomes: Always hide the logo field unless you are below the navigation node.

Why do this – surely this points at a problem with my template hierachy? Yes it does. However the amount of regression testing involved with changing base templates of a large tree could be high. Certain assertions in code may apply rules based on templateId so changing base templates isnt a feasible option. It may be down the line you do want the logo field on certain items elsewhere in the tree as well – to bring that into play would mean simply config changes.

First you need the code:

This is then patched into the config via:

What I like about this approach:

  • Additional field rules can be added without any code changes – its all config (as long as the rules you need eg unlessIsDescendentOf exist)
  • The patch:attribute on the include file allows swapping out the existing type attribute
  • Its very easy to bolt in new IFilterRules

What I don’t like about this approach:

  • I’ve subclassed the dtos and interfaces for eg IFilterRule – the rational here was these are only ever going to needed by the FieldFilter class (and it kept the amount of code blocks in the blog post down :S)
  • More complex combinations of IFilterRules eg combining and/or logic doesn’t work yet
  • It loads the config for every field – some simple caching would get around this
  • Big or naive filter rules could really slow down the content editor

Leave a Reply

Your email address will not be published.