Sitecore Tip #7: How to Properly Store Settings in Sitecore

Vasiliy Fomichev

In Best Practices, Development Posted March 14, 2014

One of my biggest pet peeves in C# is when developers hard-code things that have a high chance of changing – settings, URLs, paths, queries …etc. The main problems with this approach are lack of flexibility, leaking separation of concerns, and additional maintenance overhead, which will come back to haunt developers and clients later. So how can we avoid that?

Common Types of Settings Used in Sitecore Development

Essentially there are two ways of storing settings in Sitecore:

• Content – settings can be stored in the content tree right along the rest of the content.
  Settings are store in content for the following reasons:
  • They are updated very frequently
  • Sitecore users, including authors, designers, and administrators require access to these settings
  • Settings are database-specific
  • Settings are website specific in multi-site instances
  • Setting values require translation in multilingual instances
  • Settings need to be accessible by Sitecore fields
  • Settings changes require triggering a workflow
  • Settings must have validation
  • Some of the less common reasons include lack of technical staff on the client’s end and business rules like access restrictions in the hosting environment.
• Configuration Files – settings stored in configuration files located in \Website\App_Config\Include (How to auto-include configuration files?)

As a rule of thumb, whatever does not fit into the content category, yet is still considered a setting should be included in the configuration files. Some things I find frequently including in configuration are: item ids, paths, queries, service URLs and certain field settings.

Overall this approach seems very straight-forward, however, it is very easy to fall into the development paralysis and overlook certain things. It is very hard for Sitecore developers to stop and think through all business use cases every time they develop a component; however, it is something that absolutely needs to be done without a question. This is one of those things that separate good Sitecore developers from the great ones.

Considerations for Setting Storage Strategy

Although the topic of settings does not usually attract much attention,  it can become a real pain point, if not planned for properly. Settings can get very messy, confusing, and hard to trace. The following are the strategies I have found very helpful after years of Sitecore development:

• Each separate project in the solution should have its own settings file
• Give settings files names that correspond to the base namespace of the hosting project (example: Company.Website.Metadata.config) to help easily trace the source of the file from looking at the \Website\App_Config\Includes folder
• Give settings names that correspond to the base namespace of the project to easily trace the settings source from looking at the compiled configuration file (example: <setting name=” Company.Website.Metadata.SomeSetting” value=”important setting” />)
• Separate files hosting different types of settings into separate files (example: Company.Website.Metadata.Performance.config and Company.Website.Metadata.Security.config) to reduce the risk during manual edits

Sometimes, if requirements do not state explicitly whether settings should be stored in content or not, following the guidelines outlines above for making a decision. Here are some things to look out for that may help to make a decision:

• Is the component generic enough to be reusable? – reusable components require settings to be stored in content to allow for more flexibility
• Do personalization requirements call for having settings stored in content?
• Are there any A/B or multi-variant test use cases that would require content editors to have access to these settings?
• Did the person creating the requirements simply omit details that would have drawn a bigger and more clear picture?

The biggest thing watch out for here is falling into the outer space, exactly what Architecture Astronauts tend to do. Architecture Astronauts tend to venture on endless voyages into the space of possibilities, and assumptions about content editors, and end up creating something over-complicated and confusing.

In other words, if there are no clear indicators for one or the other, no hints, or pointers, do not go wondering into imagining and speculating on all possible use cases, raise a flag, if it is important enough or get a second opinion.