The Sitecore Habitat Homepage

So, you want to build something using Sitecore Habitat?

Posted 02/04/2016 by Ed Kapuscinski

I recently participated in the 2016 Sitecore Hackathon, which was a great experience. Not only did I get a chance to work with some of my colleagues that I otherwise don’t, but I also got a chance to learn a lot about one of the newest things in the Sitecore world: Sitecore Habitat.

Sitecore Habitat is a new “Demo” site provided by Sitecore, but is actually much more than that. It’s a new proposed “standard architecture”, the first one really put out and supported by Sitecore themselves. For this reason, it’s a big thing, and worth becoming familiar with. There’s an excellent blog post explaining what Habitat is by Anders Laub, so I won’t get into that. What I will talk about is how to actually DO something with Habitat.

Habitat is, like most modern solutions, dependent on a number of other technologies, all of which are also worth understanding. It definitely stands on the shoulders of some giants.

The first is Git and GitHub. Git is a source control management tool that is very popular, and is my own personal version control tool of choice. The original distribution of the Habitat solution source is hosted in GitHub, which is a web based Git repository hosting service.

Next up is Unicorn. Unicorn is a Sitecore item serialization tool. It takes Sitecore items and converts them into text files, which are then able to be version controlled in an SCM tool. This is helpful, because it means that Sitecore content is no longer locked up in a database, and can move along with the source code. Unicorn performs similar tasks to the more well-known “Team Development for Sitecore” tool, but approaches the same problem with a different approach.

Because Habitat is meant to create published websites, it needs a front end layer as well. To that end, it uses Bootstrap (and attendant front end tools like Sass, Jquery, etc…). If you are developing front end code yourself, you’ll want to be familiar with these tools. Otherwise, they only really come into play by needing to make sure that whoever is doing the design and front end development are familiar with and know how to work with those tools. For setup purposes, however, you’ll also need to install Node.js and NPM (the node package manager).

Additionally, there are some other tools and conventions you’ll need to be familiar with to work in Habitat. The first is the idea of developing outside the web root, and using tools to “publish” your work into the location where your site actually lives. This is a good practice from a DevOps perspective since it increases the ability and flexibility of deployments of your code. Habitat is built around this approach, and uses Visual Studio’s built in publishing mechanisms and Gulp (a Javascript based task runner) to deploy your compiled code and assets to the target location.

The Habitat installation also is structured around the idea of developing against a local database. That means installing SQL Server (of some flavor) on your local machine, and having your development instance of Sitecore use it for its databases (as opposed to a single SQL Server instance shared between developers). This is important, because it will prevent potential problems while working with Unicorn.

Getting these tools up and running is pretty straight forward, and is described well in the Habitat documentation itself, so I’m not going to replicate that effort.

A quick familiarization with the Habitat architecture

I’m not going to dive too far into the ins and outs of Habitat’s architecture, but it’s important to be familiar with some key concepts before beginning development.

Habitat is built around a layered, modular architecture. But, what does that really mean you might ask? It means that individual pieces of functionality should be self-contained: blog components should just be built to be a blog, not a sprawling monster, and should be portable between Habitat solutions with a minimum of dependencies (ideally, none beyond Habitat itself).

The most concrete example of building following the Habitat architecture is that units of functionality, referred to as a “feature”, should be built inside its own Visual Studio project. The Habitat base installation has a number of these already created, which will help guide us in creating our own.

When you’re developing functionality that you would like exposed across multiple areas of a site, or multiple features, it’ll need to be built into the platform layer.

Our Example Feature

For our Hackathon entry, we created a module (a “Feature” in Habitat parlance) that allows content editors to quickly and easily manage 301 redirects for URLs that don’t otherwise exist on a website. This is a common task when a site launches, because the URLs on it won’t match the site it’s replacing, and is also frequently needed later to support marketing initiatives (It’s a lot easier to put http://nttdata.com/sitecore on a brochure than something like http://nttdata.com/practices/cms/Sitecore).

This is all done by managing content items representing each redirect under a redirects folder in the content tree. Each redirect item has two fields: an “Incoming URL” single line text field that holds the url that visitors would go to, and a “Redirect Target” general link field that determines where a user is redirected to.

We then use a pipeline processor (put in Sitecore’s httpRequestBegin pipeline) to watch for requests that are going to be a 404 error, and do the redirect if the Incoming URL matches the requested URL.

To keep things nice for content editors, we also created a preview rendering for the redirect itself, so that they can be edited in Experience Editor, and so that users who stumble on the redirect themselves will see something inside the CMS.

Also, in keeping with Habitat’s goal of supporting the widest range of Sitecore functionality, we’re also going to make our presentation components multi-lingual.

Downloading Habitat and setting up the solution

The Habitat documentation is good, and includes most of the steps for setting up your solution so I’m just going to give you a link to that. Don’t forget the prerequisites too, which you'll need to setup before you start the actual installation.

What Needs to Be Created For Our Solution

Once you have your solution setup and running, there are a number of things you’ll need to create for your feature: a project, feature specific configurations (possibly), feature specific data templates, and feature specific presentation components. In order to actually use your feature, you’ll also need to create some project (site) specific data templates.

The Details...

The details of how to create the things you need for a Habitat Feature are in part two of this blog post.


Share:

Archive

Syndication