A Quick Guide on Setting-up Branded Microsites in Sitecore

Many organizations utilize microsites to showcase specific products, services, or campaigns to targeted audiences in a more focused way than their larger flagship site.  The development, configuration, and deployment of multiple microsites, however, can quickly become complex and unwieldy. This blog post describes a lightweight solution to allow content authors to create branded microsites with unique hostnames in Sitecore without the need for configuration updates or deployments.

The Business Requirement

We recently worked with a client to create a series of smaller sites that were composed of the same templates and components being developed for their main flagship site. These microsites needed to conform to a common layout but required the ability to have unique branding in the header as well as unique hostnames or domain names. Setting up a new site in Sitecore is a fairly straightforward process, typically - you create the new home node in the content tree then add a declaration to the web.config. In this particular scenario however, the client did not want to have to make a configuration update to deploy each new microsite - they simply wanted to create the content for it, publish it, and have it available to their audiences immediately.

Our Simple Solution

To fulfill the requirement of publishing a new site without a configuration update we created a ‘Custom Site Resolver’. This resolver would evaluate the incoming hostname and attempt to resolve it to one of the existing microsites.

The Custom Site Resolver

We started by creating a new site declaration in the site configurations:

       
              mainsite.localhost
       
       

This site, titled “Microsite”, handles all incoming requests that aren’t resolved to other sites. Since it is added after the “Website" declaration, it will not interfere when the main site is being resolved. This requires that we declare our hostnames on the other site declarations as the * hostname is usually on the “Website” declaration. With this in place, the Custom Site Resolver can do its job. This resolver inherits from HttpRequestProcessr and is placed in the HttpRequestBegin pipeline after the SiteResolver step.

A Look at Workflow and Process

The resolver performs the following actions:

• First it checks to see if the context site is “microsite” – implying that it has a hostname that is not bound to a declaration for an existing site.
• If this is true, it then looks up the requested incoming hostname in a dictionary. This dictionary contains a set of Sitecore site settings that we use to configure the site context and is created by crawling a “Bindings” field on the microsite home items. The Bindings field should contain a list of hostnames that will resolve to this microsite, pipe separated.
• Finally, if the resolver finds an entry for that hostname, the site context will be provided with the correct path and start item.

Download: Custom Site Resolver

The processor references a "Microsite" helper class, which manages the retrieval of the bindings from the Microsite home items. The dictionary is cached via a cache manager class, which uses GetMicrosites as a callback to populate the cache if it is empty. Including this in your implementation is not absolutely necessary but it is recommended that the dictionary be cached in some capacity.

Looking Forward

This process allows requests to be mapped to the appropriate site by hostname, similar to how the site resolver normally functions. However, content authors can now easily set them up in Sitecore instead of declaring these sites in the configuration. These microsites use the same templates and renderings as the main site but require their own branding and this necessitates creating separate layouts from the main site.  The details of how we accomplished this will be the topic of a future blog post that will be out soon. Watch this space for more to come.