Some thoughts about Sitecore, and software development ...

This post is about how to attempt to dig a bit deeper into the workings of the ADO.NET components found in the .NET Framework BCL, in order to diagnose any awkward SQL Server issues. Obviously this technique is not specific to Sitecore, but Sitecore's SQL Server data provider leverages these components for its data access, so it's definitely worth being aware of how to easily get at the extra trace information available inside the System.Data assembly.

I was trying to help a client diagnose automatic failover issues in a SQL Server mirroring setup - in short, when the DBA team manually failed over from the primary to mirror SQL instance, the application seemed not not be able to find the mirror SQL instance. From the log messages printed out by Sitecore, it looked like the application was at least *trying* to fail over (or at least was aware that it was connected to a mirrored SQL instance.) But annoyingly, after restarting the application the mirror host was being connecting to witho…




Following my previous article which introduced Helix and Habitat - which was a (hopefully) fairly factual account of what Sitecore have put out there - I thought I’d add some thoughts, opinions and questions. I'll focus on:

  • Overall impressions of Helix and Habitat
  • Some of my general concerns
  • Some thoughts on starting to use Helix principles

Helix Logo

Overall impressions

I think it's great that Sitecore have produced Helix and Habitat, if for no other reason than encouraging debate and discussion around Sitecore architecture and standards generally. Whilst it's easy to find endless books and articles describing modern software principles and practices in an abstract sense, it's less often that concrete examples are provided in a target technology set (for instance, .NET and Sitecore!)

Some things I like about Helix/Habitat:

  • Helix has a very “anti-coupling/high-cohesion” attitude (even if this approach may allow some duplication) - from experience I've seen far worse things coded in…




I thought I’d write a little bit about Sitecore’s “Helix” principles and “Habitat” demo implementation. After having a read through the documentation and having a play with some examples, this is my take on what defines both Helix and Habitat, and where one ends and the other begins....

Sitecore’s documentation defines Helix as “a set of overall design principles and conventions for Sitecore development” and Habitat as “a real Sitecore project implemented on the Sitecore Experience Platform using Helix” (the Habitat source code and setup details can be found at http://github.com/sitecore/habitat.) In short, Sitecore are now giving more concrete recommendations on how to develop and deploy solutions based upon their products - previously this was left to the discretion/wisdom of the implementation partner and their developers! As Habitat is an example of Helix principles, and I find it easiest to consider an example of something before considering its principles, I’ll discuss Habitat f…




Technical folk are not exactly renowned for being able to get their thoughts across in a succinct and clear manner. This article summarises a few thoughts I've had as a result of experiences with the, let's say, "varying" communication quality of development team members!

I've split up my thoughts into four main themes - clarity, perspective, accuracy and usefulness.

My objectives are as follows:

  • For developers/technical people: learn about common software communications pitfalls and some tips and tricks to overcome these, as well as some thoughts about how the way you communicate can accelerate your career and increase your value to organisations
  • For non-technical stakeholders who have to deal with developers: by seeing how communication looks from the developer's "side of the fence" you should get a feel for some problems you are likely to have with technical communication, and find some ways to help guide developers into giving you the information you really need, without havi…




If you're familiar with .NET MVC, you'll know how MVC routing can be used to consume the structure and elements of a URL path and parameters to resolve to a particular Controller class and Action method. This also takes care with ensuring that the requisite parameters are extracted from the URL and passed to the Controller.

If you're familiar with Sitecore MVC, you'll know that each rendering on a Sitecore page/item resolves to its own Controller, enabling dynamic composition of page output from multiple Controller classes. Routing-wise, Sitecore MVC works very much like Web Forms versions of Sitecore - i.e. the structure and elements of the URL path are mapped pretty much directly onto the Sitecore item tree in order to resolve the "context" item.

What if you'd like to combine some of each of the above behaviours? Perhaps you have a Sitecore page which displays some different state depending on a query string parameter (you can imagine this be be something like a product details pag…




I strongly believe that the future of software development will involve more developer responsibility for quality. A little justification for this:

  • In my experience, the expectations of what level of quality control QA teams can provide often are unrealistic; they are often used as scapegoats, with little supervision or direction - set up to fail
  • Often QA teams don't have the depth of exposure to business requirements which developers have, so developers are better equipped to find bugs
  • Anecdotally, there seems to be a tendency of developers to be more lax with their work if they know there is another team of people checking that their code actually works
  • Catching bugs earlier is generally regarded as a cheap way of improving software productivity, so having greater emphasis on developers writing code which is "right first time" helps to this end
  • Developers *know* where the weak points and edge cases are in their implementation, so are often the best people to spot flaws
  • Develo…




Recently a client requested some enhancements to their "site search" feature, which is currently implemented using Solr and the Sitecore Solr "Content Search" libraries - the requirements were:

1) Idioms/synonyms: The ability to manually configure idioms/synonyms (so that words which have the same meaning return the same results, e.g. a search for “trip” might return the same results as a search for “journey”.)
2) Spelling correction: The ability to return results as if the correct term was searched for (when an incorrectly spelled search term is entered.)
3) Autocomplete: Suggested search queries appear as you begin typing in the search box.
4) The chosen solution should work unhindered for consumers in China

Having established that Coveo for Sitecore 4.0 and Google Site Search seemed to be the two main "tried and trusted" alternatives for a Sitecore installation, I set about investigating the pros and cons of each in relation to these specific requirements. The requirements listed abo…




Following my previous post where I explained a few ideas for more practical code-level testing, here's a quick update with a version of a base class I use to base my test classes on (based on the Autofac DI library). Here's the code:

using Autofac;
using NUnit.Framework;

namespace RedMoon.Test.Common
{
  [TestFixture]
  public abstract class AutofacTestBase<T>
  {       
    private void MockExternalDependencies(ContainerBuilder builder)
    {
      // TODO - Load all "default" configured dependencies here
      OverrideDefaultExternalDependencies(builder);
      AutofacContainer.Instance = builder.Build();
    }

    protected abstract void OverrideDefaultExternalDependencies(ContainerBuilder builder);

    public T SystemUnderTest
    {
      get
      {
        MockExternalDependencies(new ContainerBuilder());
        AutofacContainer.Instance.Resolve<T>();
    …




If you are leveraging any in-memory caching in your Sitecore web application (e.g. using System.Runtime.Caching.MemoryCache) to reduce the computational load on the server, and the cached data is created using some data which comes from Sitecore, you'll need to ensure the in-memory cache is cleared at the correct times in the application data's lifecycle. One example of the need for such caching might be when a rendering cannot be HTML cached (due to some data within it being unique to the user, e.g. fetched from some domain data repository) but some part of the view model (which the rendering uses) simply depends on some items within Sitecore, based on some computational logic (so why compute this over and over again?)

You can take a lead from Sitecore's out-of-the-box HtmlCacheClearer event handler, and ensure you too have a handler which clears your in-memory caches when a publish happens, to ensure that you use the most recent data from Sitecore to build up your cached values. Thi…




This blog post is less about technical know-how and code samples and more about how you can leverage dynamic content (in occasionally unexpected circumstances) to guard against loose business requirements. I'm thinking about the kind of situations where you may be asked to implement a feature depicted by a design agency, where all kinds of rules and scenarios driven by domain/application data are implied, but perhaps not explicitly specified.

You could spend days drawing up diagrams and documents to try and capture the implicit behaviour in order to ascertain whether the client has the same interpretation that you do, but you know that the amount of communication travelling back-and-forth is going to delay the start of the implementation (not to mention that this process tends to be rather painful!) Often the client is disinterested in getting down to such a low level of detail whilst they are busy with other work - preferring to delay the "moment of truth" until they actually have to…




In my previous post I alluded to an approach where I 'faked' the Sitecore IP Geolocation Service in order to recreate a range of 'unhappy path' scenarios - enabling both successful and failing responses to be faked, with a variety of time-lags. It's fairly trivial to update your hosts file to point the host name of the Sitecore IP Geolocation Service to an IP address for a server which you control (for example, your local machine.) It's also fairly trivial to cook up a WebAPI application which returns a fixed response to any request - see the bottom of the post for a few clues.


If, like me, you make no attempt to modify the service URL Sitecore uses (there wasn't an obviously quick way to tweak this) and have opted to use the host-spoofing route, you will be forced to set up the fake web service to run using SSL. Since IIS7, you can create a self-signed server certificate directly from IIS itself, which takes seconds, and is the way I usually create self-signed certificates for local …




A key part of Sitecore's personalisation offering is the ability to gear content towards a user's location. Sitecore provide plentiful information to help you set up your application to retrieve geo data for each originating IP address. Once you have this set up, Sitecore will call a web service behind the scenes, whenever it encounters a request for an IP address which it hasn't seen before. The result of this call is cached in a MongoDB collection to ensure that each IP address is only ever requested from the web service once. Once this process has completed, the Tracker.Current.Interaction.GeoData object is populated with the relevant geo data, and the out-of-the-box location-based personalisation rules will be ready to fire.

However, in the out-of-the-box setup of the Sitecore IP Geolocation Service, you'll find that the service is configured to run asynchronously; in practice, this means that if your Sitecore application is being requested from an IP which has not been seen befor…




You can find all the ingredients to do this yourself in in various blog posts out there already, but hopefully this post brings it all together (plus a couple of extras thrown in for good measure...)

If you've worked with Sitecore for any length of time you've probably come across the idea of making non-visible data editable via the Page/Experience Editor, in order to promote a "Page-Editor first" approach (so that as well as all the obvious page text and modules, things like meta data and other page configuration can be amended without having to switch back to the content editor.) Prior to Sitecore 8 and SPEAK, this could be done by adding a few items to the Core database - no coding required! It's a little more effort from Sitecore 8 onwards, although extra configurability is now available. You'll also need to install the Sitecore Rocks Visual Studio extension.

Note that the following example works for Sitecore 8.1 Update 2.

1) Add some custom JavaScript to be triggered on your bu…




This is a less Sitecore-oriented post than usual, although very much relevant in a Sitecore application context. After a couple of years of getting frustrated when trying to apply TDD principles and to try and leverage some benefit from unit tests, I was inspired by this video (and associated content such as this, this and this) to try a different tack, in an attempt to try and get my unit tests to work harder for me.

Do you write a unit test for every class? Or if not every class, is each test focussed at class level, mocking any dependencies with other classes? Do you feel that your tests express any meaningful behaviour which relates to the feature you are working on, or do the names of the tests simply reflect the connections between one class and its collaborating classes? Are you finding that your tests are highly coupled to your implementation, such that whenever you make a refactoring change, all of your tests break, discouraging you from performing cleansing of your code? And …




You might be surprised to find out that - when rendering absolute links - Sitecore will often look at the current context Request object to work out which hostname, port, scheme etc to use. This may be a little inconvenient if - for example - a production environment has separate internal URLs used to target individual Content Delivery applications; if you are using HTML caching, and an "internal" request is made, you may find these URLs are cached for the general public, at least until the next publish clears the HTML cache! Fortunately, it's fairly easy to customise Sitecore's LinkProvider and LinkBuilder classes to behave in a different manner. Below I've ensured that the context Request object is never used as the source for any of the ingredients necessary for a building a URL - instead, we pull what we need from the <sites> config. Note that I've not used this code "in the wild" yet, so use at your own risk! Also note that you may now need to define things like port number …




I've recently pushed to GitHub some wrappers and interfaces for many of the common Sitecore API classes, which I put to good use on a recent project - this will hopefully save other people doing the same work! They can be found at https://github.com/RedMoonLimited/SitecoreWrappers - you'll also need to reference the Sitecore.Kernel and Sitecore.ContentSearch dlls; note that this code was written against Sitecore version 7.1 rev 140130. I've also included a few fairly hastily written "builder" classes (which may come in useful when creating common 'aggregates' of mock Sitecore objects for testing purposes) plus some example code and its unit test to get you started.

There are a few different ways you can wrap external dependencies for isolation/testing purposes - I've grown to like using wrappers which follow the contract of the wrapped class quite closely as, especially in the case of Sitecore, you can benefit from your knowledge of the "real" underlying code by pretty much using the w…




It's simple enough to add a computed field to the list of default index fields, and therefore all indexes - a patch file containing the following will achieve this:

  <configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
    <sitecore>
      <contentSearch>
        <indexConfigurations>
          <defaultSolrIndexConfiguration>
            <fields hint="raw:AddComputedIndexField">
              <field fieldName="urllink" returnType="string">RedMoon.Services.SC.Indexing.ComputedFields.ItemUrl, RedMoon.Services.SC</field>
            </fields>
          </defaultSolrIndexConfiguration>
        </indexConfigurations>
      </contentSearch>	 
    </sitecore>
  </configuration>
  

What if we want to just add the extra field to a specific index to keep things streamlined? Firstly, ame…




I can't guarantee that this will solve your problem, but if you are seeing the same symptoms as I was, it's worth a look! After rebuilding my solution or doing an IISreset I was seeing Sitecore continually restart many times over the course of a couple of minutes (generating a new log file with each restart) with seemingly no clues as to the cause - IIS seemed to think some configuration had changed, but I couldn't see how! After a lot of digging, I found the answer was nothing to do with Sitecore at all - it was an issue with IIS under Windows 8.1. The following fix solved the problem.

 




Another nugget of knowledge concerning the Sitecore Media Framework Ooyala Edition module (2.1 rev. 150323). When embedding a video using the Rich Text Editor, the default behaviour seems to be to output the video and its controls using Flash, with a fallback to an HTML5 player when Flash is not configured for the user's browser. If you want to change this to always use the HTML5 version of the player, simply amend the <scriptUrl> elements in App_Config\Include\Sitecore.MediaFramework.Services.Ooyala.config as follows (or use a patch file ;) ...) - credit to Sitecore Support for this:

  <playerMarkupGenerators>
    <add name="ooyala_video" templateId="{C3B8C43D-AD6B-49E2-9C6E-2FB4B53A966A}" type="Sitecore.MediaFramework.Ooyala.Players.OoyalaPlayerMarkupGenerator,Sitecore.MediaFramework.Ooyala">
      <analyticsScriptUrl>/sitecore modules/Web/MediaFramework/js/Analytics/ooyala.js</analyticsScriptUrl>
      <scriptUrl>//player.ooy…




Recently I was configuring a Sitecore 8 solution (rev. 150621) to use Solr as its indexing provider, instead of Lucene. I'd also set up the solution to use the Sitecore Media Framework Ooyala Edition module (FYI, Ooyala is an online video services provider - the module enables content editors to 'import' videos, and then embed them into their pages using, for instance, the Rich Text Editor or the provided MVC controller) - the version we are using is 2.1 rev. 150323. The module comes with its own index - and a Lucene one at that (defined in the supplied file Sitecore.ContentSearch.MediaFramework.Ooyala.config) - which I had to disable as part of the Solr setup work.

Unfortunately, removing this index causes some of the module to start misbehaving - for instead, if you run an "Import" from the "Media Framework" tab, not a great deal happens except for some messages similar to the following being written to your logs:

  Exception: System.ArgumentException
  Message: Index mediafram…




Another issue with Sitecore 7.1 version 140130 is with the SPEAK date picker component. The documentation states that you can use the Format field on the component's rendering parameters to change the way the picked date is shown as a text string (the default being mm/dd/yyyy.) This not being the case, Sitecore Support provided us with the following replacement JS for the file at \sitecore\shell\client\Speak\Layouts\Renderings\Common\DatePickers\DatePicker.js:

  /// <reference path="../../../../../../assets/vendors/JQuery/jquery-1.8.2.min.js" />
  /// <reference path="../../../../../../assets/vendors/JQuery/jquery-ui-1.8.23.custom.min.js" />
  /// <reference path="../../../../../../assets/vendors/Base/Base.js" />
  /// <reference path="../../../Page/Sitecore.Page.js" />
  /// <reference path="../../../../../../assets/lib/Models/Sitecore.Types.Models.js" />
  /// <reference path="../../../../../../assets/lib/Models/Sitecore.Types.Views.…




I came across an interesting set of challenges recently when working on a Sitecore 7.1 project (version 140130 to be precise) and using the ContentSearch indexing API.

Typically a Sitecore index will be set up to crawl a subtree of items to pull in its data. Using the IntervalAsynchronousStrategy ensures that any changes to items within your specified subtree cause an incremental update to your index, ensuring that it is kept up-to-date. What if your index depends on items outside of this subtree? In one of our indexes we used some computed fields which pulled in data from items which referred to the item being indexed (using the Links database to find the references). The referrer items would always be outside of the index's subtree of items - so a modification to one of these items would not update the index in question (actually it would - but only due to a bug which means the provided crawler would ignore the root item set in the config - use the advice here to fix this!)

The <i…