The eagle-eyed amongst you may have noticed that our website is recently both the same and different. This is indeed the case – we have spent considerable effort in migrating our main site from Telligent Community to Sitecore. "What a pointless exercise" you might think and in part, your thoughts are correct. However, there are a number of compelling reasons why we have done it and why we hope it adds value to what we offer our customers and partners. In this blog post, I’ll list our thought process and also demonstrate some of the technical challenges we have overcome in this implementation.
We set out on this journey because we are a long-standing partner of Telligent and also, as of last year, Sitecore – and we feel it's important that our own website demonstrates the capabilities of both platforms, putting the Social Starter Kit (SSK) in action.
The second reason is that we wanted to rebuild our website using Twitter Bootstrap to utilize its support for responsiveness and a set of conventions to ease collaboration among our developers, allowing us to make use of the ready-made components offered by the framework.
Our final motivation for making this change was to enable our marketing and sales team greater control over the site's behavior and content. This is reflected in our choice to use Sitecore Web Forms for Marketers rather than rolling custom forms everywhere.
Up to this point we have only had the opportunity to work with Sitecore in pre-developed solutions, so this has really been our first opportunity to work from the ground up. We wanted to produce a site that followed best practices and replicated the standards and techniques that we already apply to Telligent Community projects. We also wanted to push Sitecore to see what technical limitations we could discover to help us become better informed on best practices.
The first decision we made when redeveloping the site was that we wanted to use Razor and Sitecore's Model View Controller (MVC) support – this is where we found our first catch. With the standard Sitecore MVC solution, your site is either a MVC site or a Web Forms app and never the twain shall meet. This introduces some inherent limitations, such as Web Forms for Marketers and the Telligent SSK not working. Since we required both, we had to come up with a better strategy. Fortunately there are some great Sitecore partners out there and thanks to the HedgeHog team, who (we are using TDS incidentally) had already created a demo pipeline module that supported mixed Web Forms and MVC. We extended this by adding support so that ASCX controls could also include MVC renderings using a similar technique. The only limitation we were left with was that the main layout has to be an ASPX page; this we considered acceptable compromise.
Once we had the architecture of the site finalized, development pressed ahead quite quickly with the theme and the content. We then reached user accounts; in order to be able to effectively use the Digital Marketing Suite (DMS), users need to be traceable in Sitecore. This means that when a user fills in a web form, they enter their email address and this is typically used to create a user account with the email address used as the user name. Unfortunately, this means that public profiles would contain email addresses in the profile url. After considering and trialling several different solutions, we decided that we would implement our own profile provider and expose a vanity username when a user officially registers. Internally, Sitecore continues to use the email address as a username; this has allowed us to keep the Sitecore WFM implementation in it's native form with no customizations.
The final large component of our new site was the SSK integration. We only wanted to expose our community blog to the Sitecore site, but due to some predefined limitations of the implementation this was not possible with the SSK out of the box. Fortunately, we know a little bit about Telligent's nVelocity widgets and also how the SSK works internally to communicate with Telligent Community. We implicitly overloaded IExtensionOverrideService and intercepted methods and properties that are responsible for finding the current blog, blog posts, comments and users. The blog context in our solution is now specified using a Sitecore Template Data Field.
This has been an interesting journey for the team and we have digested many lessons on the way. The site is only just finished and the marketing team is now just beginning to change and upload more content so things are still evolving. I'm personally looking forward to building and using engagement plans to help our customers.
The source code detailing how we overrode the standard functionality is attached to this blog post for anyone curious. We do hope that the new site is better than the old one and at the same time familiar, please contact us if you have any feedback.