Monday, September 19, 2016

The new Sitecore standard - Helix principals

As a consultant working with Sitecore for a number of years I have had the pleasure to be involved with a large number of Sitecore implementations. These ranged from complete end-to-end implementation to reviews of existing sites. This has allowed me to see Sitecore development principals from a large amount of developers across multiple countries. One surprising aspect of this is the true extent that developers have implemented Sitecore, and whilst it's often pretty good, there are plenty of live examples of John West's Sitecore worst practices.

Luckily Sitecore has recently released the Helix principals which provide: "A set of overall design principles and conventions for Sitecore development". Whilst this has also been released in tandem with the habitat Sitecore project example (which I was lucky enough to be on a team which released one if the first production examples), the topic of this blog post will be primarily on Helix.

So why follow Helix principals?

Well I think Sitecore puts it best on the Helix site itself:
Helix provide a set of guidelines for your Sitecore projects. The Habitat example provides you with a pre-built and tested set of common modules that you can use as an inspiration to your project. Both improve the efficiency of your projects, reduce costs and time to market. As more and more people and organisations adopt the Helix conventions and principles, it will become a Sitecore standard. This means that people who are familiar with the conventions or the Habitat example will be able to work more easily on other convention-based projects with minimal training. It will be easier for Sitecore Product Support to understand projects built using the conventions, enabling them to resolve issues more quickly.
Some of the key take-aways for me are around the project efficiency, setting a global Sitecore standard and of course allowing official support to better understand your project.

What does it cover?

Rather than me rewriting the documentation in a blog format, lets cover off the main areas covered in Helix.

Patterns, Principles and Conventions
  • Architecture Principles: Looks at a modular solution architecturally.
  • Visual Studio: How to setup and structure and Visual Studio solution with projects.
  • File and Disk Structure: The physical structure of solutions and modules.
  • Managing Sitecore Items: Covers managing items in development and deploying them.
  • Templates: The setup of templates and how to reference them in code.
  • Page Layout: A look at page layouts, renderings, data sources and of course placeholders.
  • Configuration and Settings: Strategies for configuration and how to work with Sitecore configuration files.
  • Multi-site and multi-tenant: How to create multi site or tenant (logical grouping such as business unit).
  • Language and culture support: Multi-language implementations of Sitecore and use of Dictionaries.
  • Security and workflows: How to handle permissions in Sitecore and workflows for content editors.
  • Working with code: Code formatting for Sitecore.
  • Visual Design and Theming: A look at the front-end stack for your Sitecore site.
DevOps and development lifecycle management
  • Development: Covers general development and version control.
  • Build and integration: Covers build options for Sitecore projects along with integration points.
  • Testing: Covers managing your tests, along with unit testing and other testing activities (acceptance testing for example).
  • Deployment: Deployment strategy for Sitecore and what should be deployed where.

Get started!

For those users with large existing implementations, this can seem like a daunting list of changes to make your Sitecore solution standardised. But we all have to start somewhere, so I recommend taking one piece at a time. Fixing up how you deal with configuration can make upgrades easier so is a good start. As is the testing and deployment to ensure you have control and quality for what is released into each environment.

For the lucky ones who are starting a clean Sitecore solution, you have the option of taking the Habitat solution and using it outright (or as a best practice example). Or as intended you can take the Helix principals and bring them into your development team as general rules/guiding principals.

Wherever you are at with your particular Sitecore solution, lets all get on board with Habitat and ensure that moving forward we are all producing quality Sitecore sites that are efficient, easy to maintain and best practice!

Thursday, September 8, 2016

Setting a Sitecore password policy and protecting from brute force attacks

You might notice that out of the box Sitecore has no real password policy - take the default password for admin, a single character "b". This is not ideal and a security audit will often bring up this fact. On top of a secure password policy is the amount of times that a user can attempt to log in (with an incorrect password) before they are locked out.

By default, the web.config of your Sitecore website will have the following section:
<add name="sql" type="System.Web.Security.SqlMembershipProvider" connectionStringName="core" applicationName="sitecore" minRequiredPasswordLength="1" minRequiredNonalphanumericCharacters="0" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="256" />
The key attributes are:
  1. minRequiredPasswordLength - the minimum length that a password can be. By default this is 1 and is recommended to be changed to 8 or greater.
  2. minRequiredNonalphanumericCharacters - is the minimum required non alphabetic or numeric characters (such as @ or $). By default this is 0, and to enhance password security it should be set to at least 1.
  3. maxInvalidPasswordAttempts - is the number of failed logins a given user account can have before it is locked. By default it is set to 256, which is rather high and could allow for brute force access to an account. This should be changed to a much lower number, such as 10.
Remember as with any password policy it's important to communicate with users and have policies in place for unlocking accounts that breach the maximum invalid login attempts. 

Thursday, September 1, 2016

Sitecore custom button on the experience editor ribbon

Many content editors have a preference for using the experience editor (or page editor) to edit the Sitecore content. Much like the content editor it is possible to add your own buttons to the ribbon at the top, it's just done in a different way. In this example I am working with Sitecore 8.

Creating the button

  1. Open up the Sitecore desktop and load the content editor with the core database selected
  2. Navigate to "/sitecore/content/Applications/WebEdit/Ribbons/WebEdit/Page Editor" - it may have a display name of experience editor
  3. In my case I want the button to appear in the edit section, so under Edit I insert a large button (/sitecore/templates/System/Ribbon/Large Button)
    1. The Header field is required and contains the text that will display for the button
    2. The Icon field is required and will be the actual button
    3. The ID field is required and should be a unique id for the button

Creating the code

Firstly we need to create the code that will be run on the button click, this is a c# class.

namespace MyProject.Commands
{
    public class MyCommand : PipelineProcessorRequest<ItemContext>
    {
        public override PipelineProcessorResponseValue ProcessRequest()
        {
            Item item = base.RequestContext.Item; // The item being edited

            // Do code

            return new PipelineProcessorResponseValue
            {
                Value = "Return Value" // Return an object here on value
            };
        }
    }
}

Then we need to register this inside App_Config/Include/Sitecore.ExperienceEditor.Speak.Requests.config.
<request name="ExperienceEditor.MyCommand" type="MyProject.Commands.MyCommand, MyProject"/>

Now inside Website\sitecore\shell\client\Sitecore\ExperienceEditor\Commands we create a JavaScript file MyCommand.js. This is the code which the button click will call.
define(["sitecore"], function(Sitecore) {
    Sitecore.Commands.MyCommand = {
        canExecute: function(context) {
            // Determines whether command is disabled or enabled.
            return true;
        },
        execute: function(context) {
            Sitecore.ExperienceEditor.PipelinesUtil.generateRequestProcessor("ExperienceEditor.MyCommand", function(response) {
                // response.responseValue.value is the value passed back from the code
            }).execute(context);
        }
    };
});
The above JavaScript method uses canExecute to decide if the button is available for the given context/item and execute to run once the button is clicked.

Connecting the button

  1. Open up Sitecore rocks and locate the button just created (remembering it's in the core database)
  2. Right click the item and select Tasks > Design Layout


  3. Add a rendering and select Large Button


  4. Double click the newly added rendering to edit it's properties
    1. Id is required and should be a unique value (and different from the previous step)
    2. Click is required and should be set to "trigger:button:click"
    3. Command is required and should be the name of the command created earlier (MyCommand)
    4. PageCodeScriptFile is required and should be the location of the JavaScript file created earlier (/sitecore/shell/client/Sitecore/ExperienceEditor/Commands/MyCommand.js)

The button should now appear on the experience editor and run as expected! Remember you can secure the button via the item created in the core database if required.

Wednesday, August 31, 2016

Improving the speed of Sitecore's experience editor

One thing I noticed when speaking with Sitecore content users who have upgraded from earlier versions (such as 6.5) to version 8 and beyond is that the experience editor (or page editor) runs slow in the newer versions.

After opening up developer tools in Google Chrome and running analysis of the network tab, I was able to identify the three components of the experience editor which tool the most time to run.


Of these three items, the following two could be fixed to reduce loading times. In Sitecore implementations with a large amount of items and therefore large master database, these two components can be very slow to load.

  1. Optimization.SuggestedTests.Count: Gives suggestions on A/B multivariate tests which can be run on the page.
  2. ExperienceEditor.MyItems.Count: Shows the number of items currently locked by you, this functionality does not optimally return the count so may take some time to load.

The following Sitecore knowledge base articles provide details on these two items:
  1. How to disable Content Testing functionality
  2. Performance issue with the My items functionality
After applying both fixes, you will notice that Optimization.SuggestedTests.Count will no longer run at all and the performance of ExperienceEditor.MyItems.Count should be improved (this one will be noticed more by content editors who keep items locked).

Tuesday, August 30, 2016

Installing Sitecore performance counters

The performance monitor tool on windows is a great friend when it comes to troubleshooting a slow performing Sitecore website. In the past I have used performance monitor to troubleshoot IIS, however Sitecore expands upon the concept and provides a number of custom counters to monitor.

The counters can be installed via the following executable from Sitecore: Sitecore Counters. This package appears to be for Sitecore 8+. However if you made the mistake of installing the counters for Sitecore 6, the installation likely fails and corrupts performance monitor on your windows instance. Running the command "LODCTR /R" will fix up performance monitor by rebuilding it's settings.

Once the counters have been installed, the various counters can now be added/monitored in the performance monitor tool.


The important configuration settings in Sitecore related to this are available in Sitecore.config:

  • Counters.Enabled: Indicates if performance counters are enabled.
  • Counters.InstanceName: Instance name for performance counters.
  • Counters.ResetOnStartup: Indicates if performance counters will be reset on Sitecore startup.
Once installing and running these counters will enable you to better troubleshoot your Sitecore instances.