Helixbase to Headless Helixbase

We are all excited about Sitecore 10 and the direction the platform is taking towards .Net Core and Headless. However the task of updating your existing solution to conform to the new headless approach, might seem overwhelming.

Sitecore 10 Headless is now split to into two project types, Platform and Rendering Host.


Platform is specific to Sitecore (CM), and only configurations and code directly related to either extending or configuring Sitecore should exist here.


Rendering (Rendering Host) is specific to the Application and should contain all code and configurations required for the application to run.


Following Helix conventions you’ll now most likely need to have two projects (.csproj) per module. See Hero example below;

  • Helixbase.Feature.Hero.Platform – .Net Framework
  • Helixbase.Feature.Hero.Rendering – .Net Core

Making the Move to Headless (NetCore)

Updating an existing Helix MVC solution the new Headless approach is a time consuming task. I have written a Powershell script to take some of the pain away.
Simply run the script within a Helixbase solution from the ./tools directory and it will update your solution ready for Headless development.

Before Running

  1. Update the variable in the script $solutionName to match you solution name, if its not equal to Helixbase.
  2. Close the solution
  3. Execute Powershell script with elevated privileges (Admin)

The script will perform the following tasks:

  • Converts all existing Helix modules into Platform relative projects, updating the Framework reference to .Net Framework 4.8
  • Creates a new Rendering .Net Core project for each Module (Includes nuget packages for Rendering Engine and Layout Service)
  • Updates any (HPP) Helix Publishing Pipeline projects and sets them to only work with Platform modules.
  • Creates a new Rendering Host .Net Core web app along side the HPP site.
  • Updates all namespace reference to meet the new naming conventions of SolutionName.Layer.Module.Platform and SolutionName.Layer.Module.Rendering

On Completion

Once complete open the solution and you’ll see changes to each module. See below

You now have a solution that is ready to start being used for Headless development. All of your existing code is in the Platform (CM) project, you will now need to decouple this, moving the application over to the Relevant Rendering project.

Rendering Host

The rendering host project will need configuring and setting up as the script currently only generates a vanilla .NetCore Web App. You can use Sitecores documentation as guide for this here or check Helixbase Headless for an example. Helixbase headless is currently work in progress but I intend to have the Rendering Host available shortly.


Get the scrip here

Sitecore: Scripted Content Change – Automated


Have you ever needed to update a single field on a Sitecore item across multiple environments without affecting or changing the entire item?

This is not a replacement for Unicorn, as Unicorn provides a great way to serialize entire Sitecore items. However if you only want to change a single field value on a item and you want these changes reflected from from you local development environment all the way to QA and Production, Unicorn will only overwrite all fields for serialized items.

In a nutshell

This PowerShell library provides support with writing Sitecore PowerShell scripts, decoupled from Sitecore ISE that can be executed once within a CI/CD pipeline. Additionally custom event logging is used to prevent previously executed scripts from unnecessarily running.

Getting started


  1. SPE (Sitecore Powershell Extensions) must be installed on Sitecore
  2. Download SPE Remoting Library. This must be the same version of the SPE module installed on Sitecore.
  3. SPE Remoting must be enabled. See patch config as an example: https://github.com/ethisysltd/Sitecore-Powershell-Remote-Tools/blob/master/Configs/ShieldsDown.config

The SPE Remoting Library enables PowerShell scripts to be executed from a remote location from the Sitecore CM instance. ~
Get SPE Module and Remoting Library here:

SPE Remote Tools Download

  1. Pull the repository here: https://github.com/ethisysltd/Sitecore-Powershell-Remote-Tools
  2. Extract the SPE Remoting library into the into the PowerShell Extensions folder within its relevant version folder.
    Example: .\Sitecore-Powershell-Remote-Tools\PowershellExtensions\v6.1.1\SPE\SPE.psm1


The key folders here are explained below;

All PowerShell scripts (*.ps1) will be run on the remote server for each time this library is executed.

Only PowerShell scripts (*.ps1) that have not run or have run but have changed since the last run will be executed. *Once per change

A folder to store reusable functions for any of the scripts that will be executed on the remote server.

This library creates a PowerShell ScriptBlock payload which contains the individual script and reusable functions along with additional configurations.

Somewhere to archive scripts that have run across all environments and you no longer need them in the _Current folder. An archive could happen once a production release is complete.

The file system should look similar to this.

* Once per change
Each time a script is executed on an environment this is logged with hash value of of the script.

  • If an script has already been executed on an environment and not changed, it won’t run again.
  • If an script has already been executed on an environment and the script contents have been changed, the script will run again.


To execute the library its simple. Just run the SPE-Executer.ps1 with environment details you wish to execute against.

-SitecoreInstanceUri http://my-sitecore-cm-instance.com `
    -SitecoreUsername "admin" `
    -SitecorePassword "b"
    -PathToSPEModule "{Remoteing-Library-Path}" # Default is .\PowershellExtensions\v5.0\SPE

Example Scripts

Now when writing SPE scripts you don’t need to worry about connections to Sitecore or using Sitecore PowerShell ISE.
Its recommended to create child folders within _Current and _RunAlways to help organise and categories your scripts.

There are a couple examples within the repository in _Current and _RunAlways folders that reference shared functions.
This is _Current\02-TestScripts\01-Home-Content-Update.ps1

# ---------------------------------------------------------------------------------- 
# Sitecore Home
# ---------------------------------------------------------------------------------- 
# Items: 
#   /sitecore/content/Home - {110D559F-DEA5-42EA-9C1C-8A5DF7E70EF9}

$dateTime = Get-Date -Format "dddd MM/dd/yyyy HH:mm"
Update-SitecoreItemContent `
    -ItemId "{110D559F-DEA5-42EA-9C1C-8A5DF7E70EF9}" `
    -FieldUpdates @{
        "Title" = "Title field value updated at $dateTime"
        "Text" = "Text field value updated at $dateTime"

The script above updates the default Sitecore Home item using the shared function Update-SitecoreItemContent.


This library was originally created to assist with automating content changes across environments, but as this all leverages SPE this could be used to automate anything Sitecore within a CI/CD pipeline.

  • Rebuilding the Search Index
  • Adding a User or Role
  • Performing a Task such as a Site publish.