Helix Base now available on GitHub

Hopefully we’re all aware of the brilliant Sitecore Habitat – a demo site based on Helix principles which assists us in creating a modular architecture by following the principles of package design. I believe it’s a solution that everybody should try and become familiar with.

As the purpose of Habitat is a demo site rather than a starting point for Greenfield projects, I decided to follow the example of Habitat and have created a solution to be used as a base for Greenfield projects. It’s called ‘Helix Base’ and you can find it on GitHub.

I started with the Helix PowerShell script – Akshay Sura. Please feel free to contribute towards the project as there are many ways in which it could be improved upon – but please note that the intention of the project is not to contain an expansive demo site, for that you should use Habitat.

The current features include:

  • Glass Mapper v5 – with fluent configuration and automated mapping registration
  • Unicorn – including user and role sync
  • Sitecore 9.1 ready
  • Bootstrap v4
  • Native dependency injection with auto controller registration
  • A sample hero banner feature and sample site project for demonstration
  • Generic content repositories (by Rendering, Item Context, or Glass Content)
  • 301 Redirects
  • Version trimming rules engine – Items limited to 10 versions by default
  • Search Templates computed index field – find all items from an index by any templates they implement
  • Non admin Item Unlock
  • Auto unlocks items when a user is deleted
  • Gulp publish with webroot clean
  • Show Title When Blank patch, the forgotten Sitecore feature!
  • A module just for fun – currently adds logos to the Unicorn console

You can find instructions on how to download and configure the solution in the GitHub readme.

Please feel free to use, share and contribute! Hopefully we can now save some time in setting up a modular Sitecore solution.

The project was influenced by some resources which are due a mention/thanks… Akshay Sura (PowerShell script), Jason Wilkerson/Phil Wicklund (Sitecore 8 book), Thomas Eldblom (Habitat), apologies if I’ve missed anybody out.

Sitecore tip: Disable the Content Editor for a better user experience

It may seem odd to suggest completely disabling a whole editing feature for users, but if we want a better user experience which can reduce the requirement for user guides and/or training, and ensure good practice for devs – It’s a good idea to make the Experience Editor the only option for certain groups of users. Disclaimer… not all users!

I believe this advice is also backed up by Sitecore who advised me to use the Experience Editor when performing a live demonstration at Symposium. Nice to be on the same page!

How it benefits developers

While the Content Editor is a useful feature for those we’re creating a solution for, it can allow us to be lazy when it comes to the user experience. If a dev is writing a system based around the Experience Editor they have no option but to ensure the likes of the following are setup:

  • Insert options
  • Edit frames
  • Custom experience buttons
  • User friendly WebEdit ribbons
  • Compatible renderings in allowed controls (which can be bypassed in Content Editor by using presentation details)

These are aspects of the system which may have previously been covered using the Content Editor, and are tasks which should be considered regardless of the availability of the Content Editor. However, they’re often ignored as they’re not compulsory due to the availability of the Content Editor. Therefore, switching off the Content Editor forces our devs to be user driven, which assists us in the reduction of technical debt.

How it benefits end users

Introducing change is never an easy task and the best way to make the process as seamless as possible is to introduce something which is simple, and will make a user’s life easier. The way we do this is by creating a user friendly system, and the barometer for that is found in both its reception by the end user, and the amount of support/user documentation required. There should be a very little requirement for training, ongoing support and documentation.

So if we’re presenting our users with different tools to edit content, will they see the value or will we baffle them with too many options? We have to bear in mind that many of our users will not be familiar with the Sitecore platform. Our users do not need to see a whole host of fields and a content tree, the best thing we can do is present them with a visual representation of what they will be editing and leaving it there. Which is easier, to show something visual, or to spend time training somebody how to edit fields in the Content Editor? A well constructed solution should be self explanatory, and the Sitecore Experience Editor is just that. It exists for a reason.

How to remove Content Editor access

To remove the tool you must remove permissions to the following item in the core database:

Content->Applications->Content Editor

It’s also a good idea to remove permission to the following item as it will throw an exception if the user does not have permission to the Content Editor tool.

Content->Applications->WebEdit->Ribbons->WebEdit->Page Editor->Edit->Workbox

In closing

The time to act is now because if an editor currently has access to the Content Editor they will use it, become familiar with it, and any changes to access will upset them.

We cannot simply turn off the Content Editor as a default – but there are certain situations where this will be a very beneficial exercise. Choose carefully when to implement this architectural decision. Now we can go ahead and create a great user experience, writing user friendly systems which require little/no tuition.

Sitecore setup considerations

After working with the Sitecore platform for a few years I’ve summed up a few useful tips which I’ve used to enhance the setup. These are mainly based around optimisation but also cover some other issues that can arise. As with any architectural decision it’s best to plan these as early as possible, but the following should be considered whether you already have an instance setup, or if you’re about to embark upon a new project:

Trim your versions

Versioning is something which can be overlooked but our out of the box Sitecore instance will create an endless amount of page versions which carries a very large performance implication. Each time an editor changes a page they create a new version, so we could end up with literally hundreds of versions of pages on our site, most of which are not required.

We need to limit the amount of versions for our Sitecore items. The first tip is to implement a rule to limit versioning and if you don’t read any further, at least pay attention to this step and ensure that you limit your page versions to a useful number such as ten.

File unlocks

There is a common problem for those with more than a handful of content editors whereby editors will often need access to a file has been locked by another user who has forgotten to check it in. For good reason Sitecore out of the box doesn’t allow users to unlock another users items and if organisational governance dictates that only admins can unlock files we’re restricted to the following options:

  1. Make sure editors are educated to check in any items that they have locked – This is unreliable and doesn’t account for human error.
  2. Ensure that the users can always contact an admin – this places a dependency on an admin and could be quite time consuming for them which doesn’t help efficiency.
  3. Write and admin tool to allow mass unlocks – This could be useful but still requires an admin to be present who would have to issue caution when using such a tool.
  4. Make editors an admin – This is a bad idea for obvious reasons. Also, when an admin edits a page it doesn’t automatically create a new version so it adds a requirement for them to remember to manually add a version.

The best solution is to reduce the dependency on an admin by creating a new user access right. We can then allow editors to unlock certain items within Sitecore that have been locked by other editors. Obviously this still requires governance and education in the use of the new feature, but it resolves our issue.


Publishing impacts data, item and HTML cache so we need to use it sparingly and there needs to be a reason for anything other than a Smart publish of items.

It is important to assign the correct user access rights to restrict publishing options. If a user has all publish options available to them they will likely use them so accounts must be restricted, ideally to a Smart publish only. We can restrict the publish options available to our users by setting security in the Core database. It probably goes without saying that a full site publish should be a rare thing, as should a full search re-index.

Patch your configs

This is an absolute must. Patch your configs and leave the originals well alone! For one, it will make life a lot easier when you upgrade a Sitecore instance.

Patch files by default are stored in App_Settings/Include but this setting can be overridden within Sitecore. Don’t forget the ShowConfig.aspx admin tool to view the results of your patch files.

Use Sitecore NuGet

As the title says, make use of the Sitecore NuGet feed and if you’re using VSTS for CI/CD be sure to read the following article.

You should also be using a NuGet package restore for a clean development environment and smaller repository size.

Avoid performance degrading methods

Methods such as GetDescendants in the content API will impact upon site performance as your site data grows. A Sitecore instance which is making heavy use of such methods will suffer from slow performance, instead we should use a Sitecore search API which will make use of Solr/Lucene for queries.

I have also seen performance issues with large Sitecore trees. If for example you have 200 child items which all use a template with a Treelist field, a simple switch to the TreelistEx field type will offer a significant performance increase. We should conduct an audit of our templates and ensure that the field types have been optimised. Obviously we also need to consider buckets.


Although we need to think about the values of Prefetch, Data and Item Cache in our config files I wan’t to remind us of a very obvious tip which is to make your renderings cacheable. There are very few occasions where I have had to completely switch off caching on a rendering, so you should check all renderings and ensure that some form of caching is enabled.

Dependency Injection

Implementing this software design pattern allows us to swap our providers, unit test, and ensures that our code is loosely coupled, reusable and maintainable. However, the use of a DI container carries a performance hit so we should study the DI container benchmarks and choose accordingly. Obviously we should be aware that with an IOC container we can lose compile time checking, and we must carefully think about this architectural decision.


Fields should contain user friendly titles to assist our content editors, this is a fairly obvious step but it’s one that’s often ignored.


Using IIS redirects is best for performance but if for any reason you’re not doing this you need to handle them in Sitecore. We have access to alias’s but it’s a good idea to setup your own 301 redirect component and manage your redirects as items in a folder. Remember to give your folder structure some consideration. It’s easy enough to create your own module or you can follow a 301 redirect setup guide.