SPE Archives - Page 2 of 2 - Flux Digital Sitecore Blog

Creating Sitecore Items with a Specific ID with SPE

I recently needed to re-create an item that had been deleted by accident and was no longer available in the recycling bin or anywhere else. However this item needed to be created again with the same Id to avoid a lot of re-configuration.

I figured I might be able to do this with SPE (Sitecore Powershell Extensions) and after some digging it turns out there is a –ForceId param supported by the ‘New Item‘ function that I hadn’t come across before.

It can be used like so – note: the -ForceId parameter that you will need to update to the Item Id you wish to use:

Once you’ve run this command you should see an item created with the Id you set as below:

I haven’t seen any other blog posts on this so hopefully it’s useful for anyone else who needs to do this in future.

Bulk Adding Captchas to WFFM Forms with Sitecore Powershell Extensions

Last week we had some Robots submitting a lot of WFFM forms across the website, creating thousands of submissions. I knew the quickest way to solve this was to add the out of the box CAPTCHA to the forms. However we had to put a solution in place quickly but with over 350 form instances across the website this needed a automated solution.

I immediately thought SPE might come to the rescue here (as it often does), so had a look on Google/SSE etc but couldn’t see anyone else who’d done this. So I fired up SPE and the following script is what I ended up with:

Add a CAPTCHA to all WFFM Forms with SPE

google-recaptcha

The script recursively loops through all the forms in the root folder set in script and checks if a CAPTCHA exists on the form already. If it doesn’t find one, it creates one as the last field in the form using the settings defined in the script. You can easily update any of the field settings to your liking such as the name and if it’s required etc.
It could also be modified to filter forms based on criteria such as name, folder or send/save actions if required too.

I hope this is useful for someone else in the future.

Automate Adding Experience Editor Buttons to Renderings with SPE

I had an situation last week where I needed to add a experience editor button to all components and we have 63 of them. So Instead of doing this manually I decided to see if I can do this easily with SPE.

The other thing I had to consider is that most renderings had some custom experience editor buttons already, so I needed to make sure these were maintained.

Also I only wanted to add the button if there was a datasource set as it is only relevent to components with buttons.

It turns out this wasn’t that tricky and this same script could be used to populate any multi-list field, such as auto-setting the compatible renderings:

Show Me The Script Already

Hopefully someone else will find this useful too.

Fixing Standard Values without Affecting Existing Content

Unfortunately I wasn’t able to attend Sitecore Symposium this week so won’t be writing up an overview of what I’ve learned, there were some exciting things announced for Sitecore in 2020 though from what I’ve seen on Twitter so I’ll keep an eye out for those Symposium Blog posts for more info on what I missed.

Instead this Blog Post is about an slightly odd situation regarding fixing Standard Values when they have been set incorrectly for a number of templates.

Standard values provide initial values for all items based on a given data template.

We had around 30 page data templates that have an field value set on the standard values to an incorrect value. Unfortunately there are thousands of items based on these templates and I needed to maintain the existing values so I couldn’t just change the standard values to the right ones as it would also re-set all items still using the Standard Values.

Reading up on How Standard Values Work again the import part is this:

A field can contain the same value as its standard value without actually containing that standard value. For example, an item contains its standard value. The user updates that field; the field no longer contains its standard value.

The user updates the field again, setting the value to the same value as the standard value for the field, but without resetting the field to its standard value. The field now contains the same value as its standard value; however, it does not contain its standard value.

So I decided that SPE would be the perfect tool to solve this issue. I initially wrote an script to update the item field value to another value and then a 2nd script to set it back to the same value as the standard value. This means the item would no longer be inheriting the field value from the Standard Values.

However this wasn’t very efficient and there was a risk of my items loosing the correct value when being set back again. My colleague Mobeen suggested that perhaps if I updated the script to set the value to something and then immediately back to the same value as the standard value then this would work and only require one script. It did and here is the final script I came up with:

The script makes use of the .ContainsStandardValue property of a field which Sitecore uses to track if a field is using the Standard Value or not. Once the script has run the ContainsStandardValue for the field is false for all items and therefore the Page template can be updated without affecting them.

You will see it sets a field called ‘content type’ so to re-use it you should change the field name used. Also ensure you set the path to the items in the pages query.
You can run this with the value of $global:updateContentTypeField set to false to just report which items are using the standard values for this field. If you wish to update the field value for items then set this to true.

Once this had run I was safe to correct the standard values on all my page templates without affecting the existing content :-).

Hopefully this will help someone else who has this issue.

Copying Final Renderings back to the Standard Values on Page Templates with SPE

Following on from my post last month where I’ve been trying to automate some of the tedious tasks involved when building pages and components in Sitecore, I had another task which I wanted to try and automate with SPE also. This time round it was automating copying Final Renderings back to the Page Template after adding lots of components to a page in Experience Editor.

copypaste

I have been building quite a few new Page Templates with between 10 and 20 components on each. I was using Experience Editor to build up the pages as it’s much quicker than using Content Editor. Once I’d finished the page I needed to ensure that all the renderings are copied back to the Page Template Standard Values Renderings field so that when Content Editors create a new page using the Template it has a default set of components. I could do this manually but is a bit tedious so I figured there must be an easier way.

I initially looked at the options available out of the box and in SPE but none of these (including the SPE Merge-Layout function) support copying renderings back to the Page Template of the item so I decided to write my own function for this.

You can call the Function as follows – note the optional -ResetLayout Switch Parameter which allows you to also reset the page you are copying the renderings from to use the Standard Values of the page template.

Import-Function Copy-Page-FinalLayout-To-Template

Copy-Page-FinalLayout-To-Template “/sitecore/content/Home/Test Landing Page” -ResetLayout

Hopefully others will find this useful when building new templates and pages and this will save you some time.

As usual there were a number of Community posts that were useful for writing this:

https://sitecore.stackexchange.com/questions/7102/using-sitecore-powershell-extensions-to-copy-layout-details-from-one-device-to-a?rq=1

https://sitecore.stackexchange.com/questions/4620/copy-final-layout-to-shared-layout/4623

http://blog.martinmiles.net/post/sitecore-powershell-extension-snippets-collection

Accelerating Development of Sitecore Components with SPE

I’ve recently been creating a lot of new pages and component for the latest designs for the client I’m working with and and after creating a bunch of components I thought there must be an quicker and easier way to do this.

TLDR: Use Sitecore Powershell Extensions to automate the process of creating Components in Sitecore

Lets looks at some of the steps you commonly go through as a Sitecore Developer when creating components:

Create the Component Data Template
Pick an icon (we all know this takes the longest amount of time :-))
Create an Component Folder template item for the Components to be organised in
Add Standard values and Insert options on the Folder template for the Component and Component folder
Create test content organised into folders using the Component and Component Folder templates you’ve just created
Create a View Rendering
Add the View Path, Data Template and Data Source Location and cache settings to the rendering

Pretty monotonous right? So with SPE I figured I could automate most of this process, I managed to do most of it and save a whole bunch of time. Often your Component Templates and Renderings are created in the same location in Sitecore and with a standard naming convention so this ins’t too difficult.

The Functions

First up I created 3 of functions to simplify each part of the process.

Scaffold Component & Folder

Creates Component and Folder templates at the specified location and standard values and set insert options for standard values on the folder.

Create Component Datasource

Create component datasource based on component base path and template path and names.

Scaffold View Rendering

Creates a View Rendering at the specified location and adds View Path, Datasource location, Data template and cache settings.

Calling The Functions

You can then call the functions like so – using the example of creating an Hero:

Import-Function Scaffold-Component-And-Folder

Scaffold-Component-And-Folder “Hero” “/sitecore/templates/Shared/Components”

Make sure you set the component template path to where your components are created for your Site. This should create you an component and folder for your component with the insert options set etc.

Now just pick an decent icon for your component and folder, add your fields and your done.

Import-Function Create-Component-Datasource
$componentName = “Hero”;

Create-Component-Datasource -ComponentBasePath “/sitecore/content/Global Content” -TemplateBasePath “/sitecore/templates/shared/components” `
-ComponentFolderName “$($componentName)s” -ComponentName “$($componentName)” `
-ComponentFolderTemplateName “$($componentName) Folder” -ComponentTemplateName “$($componentName)”

Make sure you set the component and template base path correctly for your project and the names for the templates to use. You could modify this function to create multiple test content items if you wish also.

Import-Function Scaffold-View-Rendering
$renderingName = “Hero”;

Scaffold-View-Rendering -RenderingName $renderingName -RenderingPath “/sitecore/layout/Renderings/Shared” `
-ViewPath “/Views/Shared/$($renderingName.Replace(” “,”-“)).cshtml” `
-DataSourcePath “/sitecore/content/Global Content/$($renderingName)s” `
-DataSourceTemplate “/sitecore/templates/$($renderingName)”

Make sure you set the rendering and view path to where your views are created for your Site in Sitecore and your Project. Also ensure the Datasource Path and Template are set correctly. This should create you your view and configure it for you. Now just pick an decent icon and your done.

Once you’ve got these 3 functions and script to call them setup it’s surprisingly quick to create new components in Sitecore, allowing you to focus on the important and more complex stuff. I’ve accelerated my development quite a bit since I created these and cut down on mistakes/missed configuration.

Hopefully you will find them useful too.

I’ve gone further than this by publishing the templates, renderings, content, images etc with SPE for local testing and a few other things to speed up development but thats a post for another day.

I demo’ed some of this at the Leeds Sitecore User Group Meetup Last week also:

As usual there were are few posts out there that were really useful for creating these scripts such as the following:
https://stackoverflow.com/questions/38193871/sitecore-create-new-template-item-using-spe
https://sitecore.stackexchange.com/questions/15171/is-it-possible-to-edit-the-insertitems-of-an-item

The Business Case & Considerations for a Sitecore 9.2 Upgrade

I don’t often write Sitecore blog posts from a business perspective but I today I thought I would as I think some Sitecore customers are still on 8.x or 9.0 and are considering an upgrade to Sitecore 9.2.

With Sitecore 9.3 likely to be released later this year and mainstream support for 8.2 and below running out in December now is a good time to consider upgrading.

In this post I’m going to outline what the benefits of moving to 9.2 are and also the considerations you should make before embarking on an upgrade.

What are Benefits / Features of Sitecore 9.2?

This is usually one of the first questions that will be asked. I’m not going to keep this fairly high-level as there are many in-depth blog posts out there on Sitecore 9.1 & 9.2 features but the following should provide a succinct summary.

Sitecore 9.1 & 9.2 bring a lot of new features and there has been a big focus on splitting features and functionality out from the previous large monolithic architecture to a smaller modern micro-service based architecture:

Sitecore Cortex – Sitecore’s new Machine Learning Brain which can Suggested Personalisation and process and leverage customer data
Sitecore Identity – Single Sign On and Federated Authentication (using IdentityServer)
Sitecore Universal Tracker – Provides an central Analytics API to track interactions from any device (e.g mobile apps, IoT, AR and VR)
Sitecore JavaScript Services (JSS) – allows development of apps using front-end frameworks such as Angular, React and Vue, using Sitecore as the source for the data (including SXA & Sitecore Forms support in 9.2).
Sitecore Accelerator Framework (SXA) Accessibility Improvements – SXA has been around for a couple of years and is a package or pre-built components for Sitecore allowing you to get sites up and running quicker.
Sitecore Host – A lean common runtime for .NET Core applications (Powers: Horizon, Universal Tracker, Sitecore Identity)
Helix Configuration – 9.1 shipped with some Helix configuration already setup. Helix is Sitecore’s recommended approach to building Sitecore Sites it sets out an number of overall design principles and conventions to follow.
Sitecore Installer Assistant (SIA) – 9.2 provides a new GUI for easily installing Sitecore in a few clicks
SSL offloading – 9.2 provides an SSL offloading config to Improve security and performance by shifting SSL Processing onto separate processors
Active Personalization Dashboard – 9.2 has a new new dashboard which provides an overview of all personalization actively occurring, providing visibility of poorly/well performing tactics to act upon.
Many other improvements including: Search, Content Delivery, xDB and Analytics, Sitecore Forms, EXM, SIF(2), YAML Item Serialization, Bug Fixes and performance Improvements

But We’re on Sitecore 8.2 or below, what else do I get?

Mainstream Support

If you are yet to upgrade to Sitecore 9 then you need to consider this soon as Mainstream support for 8.2 and below expires in December 2019. https://kb.sitecore.net/articles/641167
This means that whilst Sitecore will still provide security updates and fixes and endeavour to assist with product incidents they may not provide support for the following:

Assistance with errors or unexpected behaviour during installation or development
Addressing product defects as hot-fixes or patches
Compatibility fixes for supported technology platforms.

Therefore if you are on 8.2 or below after December this year then you may need to upgrade to resolve certain issues (depending on what the issues are).

Sitecore 9.0 Features

If you are on 8.2 or below you will also benefit from all the features released in 9.0, here are the key ones:

xConnect – Provides an unified API that centralises data access
Headless CMS support and JSS – Allows web apps to be built with React, Angular, Vue using Sitecore data
Rules based configuration – Configuration is now much simpler as it can be set based on the server role (e.g Content Delivery, Content Authoring)
Sitecore Install Framework (SIF) – SIF is a framework for installing Sitecore using automated scripts. This is how Sitecore 9 and above is now installed and it means deployments can be automated easier.
Sitecore Accelerator Framework (SXA) – SXA is a pre-built set of components to allow pages to be developed quicker with less development effort
Sitecore Forms – Sitecore 9.0 has newly designed forms to replace WFFM. These are built in a modern way and are easier to configure and customise.

Upgrade Considerations

So there are clearly some significant benefits to carrying out an upgrade to Sitecore 9.2, especially if you are on 8.2 still, as some customers are.
There are some additional requirements and considerations when moving to Sitecore 9.2 and standard upgrade considerations which need to be planned for:

Additional Servers / Roles – Due to changes to the architecture to split out elements of Sitecore into smaller services Sitecore 9, 9.1 and 9.2 require some additional Servers and roles. These are for xConnect, Identity Server, Cortex and processing. When you are planning resources for your upgrade this should be considered, particularly on Azure as there are quite a few additional services required.
Module Upgrades – Most Sitecore sites will make use of a number of Modules to extend the out of the box functionality. Some popular modules are: Web Forms for Marketers (WFFM), Url Rewrite and Sitecore Powershell Extensions (SPE). It is important to ensure that each module you are using is supported in Sitecore 9.2 and to consider time for upgrading each module as part of the upgrade process.
Updated Licence – Most customers will require a new licence generating when upgrading to Sitecore 9 and above. Therefore ensure you request this from your account manager in advance and that you have all features/modules you require included on your licence.
Active Directory module – Sitecore 9.1 & 9.2 or later does not support the Active Directory module. Sitecore uses Identity server to handle logins instead of legacy methods such as AD. Therefore if you are upgrading to 9.1 or above and use the AD module you will need to implement an integration with Active Directory from Identity Server.
Search – Sitecore 9 and above no longer supports Lucene so you must use SOLR or Azure Search. Lucene did not work well in distributed search scenarios so moving to SOLR or Azure Search has been recommended for a while. SSL is also required for SOLR in 9.0.
Code & Configuration Updates – Sitecore try and reduce breaking changes where possible but sometimes they are unavoidable, so as with all Sitecore upgrades some custom code and configuration will need to be updated to be compatible with Sitecore 9.2.
To assist with this process Sitecore does provide an Express Migration Tool (to get to 9.0) and an Update Installation Wizard to update to 9.2. However these tools will likely only get you so far for highly customised Sitecore implementations and will likely need some manual upgrading too. Any code that needs upgrading will not be auto-upgraded by the tool. If you are on 8.2 then there are quite a few changes for analytics with xConnect. All references in Visual Studio will need updating to 9.2 also.
Support Patches & Hotfixes – You will likely have some hotfixes or support patches that have been applied to your solution over time. These will need analysing as part of the upgrade to understand if they are still required or not in 9.2. Many of these may have been rolled into 9.2 already.
Analytics Data upgrade – Part of the upgrade process involves migrating xDB data in the 8.x format to Sitecore 9.2 format. Sitecore have a tool for this: https://dev.sitecore.net/Downloads/Sitecore_xDB_Data_Migration_Tool/3x/xDB_Data_Migration_Tool_300.aspx
Implementation Quality – Best practice Sitecore implementations do not customise any out of the box Sitecore files and instead use patch files and extensions to customise configuration and other Sitecore functionality. Ideally the base platform should be installed ‘as is’ and the customisations layered on top to assist with upgradability. Depending on how well your implementation has been carried out will impact how easy it is to upgrade. If your implementation is not best practice then your team should take the time during the upgrade to correct this and take advantage of some of the newer and better ways of doing this.

A Note on Upgrading WFFM

Often one of the key stumbling blocks for upgrading Sitecore to 9.1 or 9.2 is Web Forms For Marketers, this is because it was deprecated in Sitecore 9.1 and is also not supported in Sitecore 9.2. Sitecore 9.0.2 is the last release where WFFM can be used. Sitecore Forms has replaced it. If customers have many forms this can be a bit daunting.

So you could just upgrade to Sitecore 9.0.2 and stop there, but you would be missing out on a lot of features and you will need to upgrade again in the near future. Thankfully there is another option, there is now a community built tool to help automate this for you and convert WFFM forms and data to Sitecore Experience Forms: https://github.com/afaniuolo/WFFM-Conversion-Tool. I have yet to use this but have heard good things about it and it is regularly updated.

I’ve tried to cover the key features of 9.2 and considerations for upgrading here. As you can probably see the longer you leave an upgrade the more complex it becomes as there are more changes to consider. Frequent upgrades of Sitecore should be the aim as this will reduce the time and investment needed to carry them out. Hopefully you’ll find this post useful for planning an upgrade to Sitecore 9.2 and leverage the investment you have made in the platform.

Changing Sitecore Item Data Templates with SPE

spe icon This week I needed to change a number of navigation items from an old navigation item data template to a new one. I didn’t want to have to do this by hand as I have quite a few items to update, so I decided that Sitecore Powershell Extensions (SPE) was the quickest and easiest way to do this. If you don’t know about SPE I’ve written more about it here.

There isn’t an function as such to do this in SPE so I put one together and thought I’d share it here.

How do I use it?

The function updates the data template of an item (and optionally it’s child items) from one template to another. It has 4 parameters:

RootItemId – Specifies an Item Id to start searching for items from
SourceTemplateId – Specifies the Id of the template to match items on (the template you wish to change)
TargetTemplateId – Specifies the Id of the template to change items to
Recurse – Specifies if all the child items below RootItemId should be included in the search.

An Example

Change-Template -RootItemId 36584658-7B62-4572-932E-8214A3CD7CE8 -SourceTemplateId 92C1C171-3ED0-4E8F-860A-FEAF14336A96 -TargetTemplateId DD68EBBB-4D82-411C-BA19-D95A65AAEF83 –Recurse $true

Change-Template Function

Hopefully this is useful for others who need to do something similar.

Potential Improvements / Alternatives

If you have an number of templates that you want to update in various locations in your Sitecore solution you could use the Get-ItemReferrer option before the | Where-Object query and this will get all items referencing the template instead of searching the entire Sitecore content tree. In my case however I didn’t want to update all items with old template, just ones under a specific path.

I could perhaps update my function at some point to accept a $UseGetItemReferer boolean option and also allow for a null $RootItemId in order to support this and make the function more flexible.

Bulk Move Items with Sitecore Powershell Extensions

Sitecore Powershell Extensions (or SPE) is a great Module for Sitecore that allows you to automate a lot of menial tasks, e.g bulk renaming, moving or deleting items and much more besides.

There is a great Git book here with more info on what you can do with it: https://sitecorepowershell.gitbooks.io/sitecore-powershell-extensions/

I needed to move about 3,000 child-items to a sub-folder in Sitecore and since there is no easy way to do this I decided SPE would be perfect for the job.

Before you do anything with SPE on a Production environment – a word of caution: please be very careful to test your scripts on a Development or Staging environment first and backup your live database before you run anything on Production.
Ok now on with the code. The script below has two variables defined at the top.

$rootOfitemsToMove – The folder/parent item where the child items you want to move currently exist.

$destinationItem – The folder/parent item where you want to move your child items to.

$templateNameToMatch – The name of the template you wish to match on. This allows you to filter out other child items you don’t want to move.

Give me the script already

$rootOfitemsToMove = Get-Item “/sitecore/content/My Site/My Items Folder”;
$destinationItem = Get-Item “/sitecore/content/My Site/My Items Folder/Sub Folder”;

$templateNameToMatch = “My Template”;

Write-Host “Moving items from: ” $rootOfitemsToMove.Paths.FullPath ” to: ” $destinationItem.Paths.FullPath ” …”;

Get-ChildItem | Where-Object { $_.TemplateName -match $templateNameToMatch } | ForEach-Object {
$name = $_.Name
if(![string]::IsNullOrEmpty($name))
{
Move-Item -Path $_.ItemPath -Destination $destinationItem.Paths.FullPath;
Write-Host “Item moved to: “$_.ItemPath;
}
else
{
Write-Host “Couldn’t move Item: ” $name;
}
}

Write-Host “Moving items complete.”;

Just open up Powershell ISE (Developer Tools > Powershell ISE from Sitecore Desktop), paste in the script, update the paths and template name and run it. One the script is complete you should see that all your child items that have the correct template have been moved to their new destination.

Note: the script above purposely doesn’t use the -Recurse argument on the Get-ChildItem method as this would keep looping through your destination sub-folder if it exists below the current paths of the item and get stuck in an infinite loop potentially. However this means it won’t loop round sub-folders, so you may want to change this if your $rootOfitemsToMove has sub-folders with items in you wish to move also. Just make sure your destination folder is elsewhere to avoid the above infinite loop issue.

Thats all there is to it. Hopefully this is useful and gives you some idea of how SPE can save you a whole lot of time and pain too!.

My thoughts on SUGCON 2016 – Day 2

badge There was an early start for Day 2 (especially after a late-ish night involving a few strong Danish Beers), but I knew there were some intriguing talks today so didn’t want to miss anything.

You can read about Day 1 here if you missed it.

The first session that caught my interest was Nick Wesselmans talk on how Active Commerce use SIM, Powershell, Octopus Deploy and Azure to automate product builds.

Using SIM, Powershell, Octopus Deploy and Azure to automate product builds.

Nick gave an overview of how they created a PowerShell wrapper for SIM to automate Sitecore instances for product builds for their Active Commerce product.

He also talked about how they use Sitecore Power Shell Extensions (SPE) to do things like automate publishing, rebuild the links database and initialise Sitecore Zip package builds. I’ve experimented with SPE but I’ve not used it in anger and this has given me ideas for how I might use it more on current or future projects.

Finally, he talked about their use of Octopus for deployment of packages and invoking PowerShell scripts and Azure IaaS and Azure Blob Storage and AzCopy which is used for quickly spinning up VMs for hosting the product build and test environments. I liked the idea of these being scripted to only run during business hours.

The Active Commerce team also use Bamboo for their build server (but are thinking of moving to Team City). Nick showed us that their build pipeline looks like this:

It was nice to see some familiar approaches here, albeit with different tools in some instances and some new ideas too.

You Me and Sitecore MVC

After a short break Kern Herskind delivered and entertaining (and Circus themed) presentation on Sitecore MVC. He even rode a unicycle at the end!

Kern gave a general overview on MVC for those not familiar with the concepts and then how Sitecore MVC works and whats available out of the box. Not much of this was new to me but it was good get a refresher anyway.

Then Kern talked through some of the downfalls of Sitecore MVC and how he has gone about solving them. Things like renderings not being able to alter any HTML that is rendered prior to them being rendered and multiple form posting issues.

We then go a sneaky peak of what coming up for Sitecore MVC, such as abstract base classes and better ServiceLocator and DI support:

Kern finished by talking about the future of Sitecore MVC and expectations for the future.

Good to see better documentation and closing feature gaps on the list of improvements.

The key message here being that Sitecore MVC is going to continue to be the preferred UI Framework.

Hedgehog then did a quick talk on their TDS product and helped to answer the question a lot of developers might have, “why should I pay for TDS instead of using Unicorn”. The answer is probably in these two slides, maybe go and show them to your Boss :-).

Essentially it does a lot more besides just syncing items between sitecore instances:

I haven’t used it but I’ve head good things about it from other Sitecore Developers.

After lunch (which was excellent by the way) I opted to attend two talks on Sitecore Habitat. One by Ruud Van Falier called Introducing Sitecore Habitat and the 2^nd by Anders Laub on Practical Habitat: Embrace the Architecture.

Introducing Sitecore Habitat

For those who don’t know what Habit is, it is an Architecture approach for Sitecore development and is designed to give best practice guidance on how to structure your Sitecore projects. I have taken a look at it a few times but not really used it and the feedback from other Sitecore developers I’d spoken to was that it was quite complicated, so I was interested in finding out more about it.

Ruud was presenting to a packed room with quite a few developers stood up at the back, obviously as keen as me to know more. He started with the basic concepts of Habitat, explaining how all modules are self-contained and that there should be no communication that goes upwards between modules.

He also explained the the 3 layers of Habitat: Foundation, Features, Projects.

Ruud then discussed examples of elements that might live in these layers and how the dependencies flows downwards.

He then showed the technology stack, which are probably familiar tools to most of you. Sitecore 8.2, MVC, Dynamic Placeholders, Unicorn, Bootstrap, JQuery, Sass and Gulp.

A run-through of the Habitat solution structure then followed and an explanation of the different build tasks used.

There was then a more in-depth explanation regarding Modules:

And then more detail on layers:

Finally, a pros and cons slide and questions:

Ruud was honest about the fact that Habitat is in the early stages and is changing every day, he also said it’s not meant to be taken as a ‘Boiler Plate’ for Sitecore solutions – more a guideline. However, I left the session will a lot of things to investigate further and will definitely be taking a closer look at Habitat and how some of It’s concepts can be applied to the projects I am working on.

Practical Habitat: Embrace the Architecture

With my appetite now whetted for Habitat I went straight to the next session on embracing the architecture.

Anders talk started with a general discussion around Architecture and then moved to Habitat and why Pentia use it as an architecture for their solution:

He then dived into a demo of their solution and explained how it differs to the default Habitat setup. I have a video of this somewhere which I’ll try and add here when I get a minute.

He then discussed a few foundation modules they have created and how it really works well for them as an approach.

Anders took some tough questions from the crowd well (such as the number of projects in Habitat – which is many) and I think by the end of the session most of the room will be taking another look at Habitat.

Ladies and gentlemen start your testing.

Testing in Sitecore can be notoriously difficult and for some Sitecore developers this means that unit and integration tests that involve the Sitecore context or items are sometimes skipped. I was interested to see if Alastair had some other ways to implement testing and I wasn’t disappointed :-).

Alastair Deneys ran us through 4 ways in which to Unit test with Sitecore. The first was an interesting one and was to essentially install Sitecore in your application and then run the tests from an asp.net web page test runner.

The 2nd and 3rd were to add a minimal or full Sitecore config files and the Sitecore dlls you need to your nunit test project and run It. This worked pretty well but as Alastair said, isn’t proper unit testing as it’s using real data.

The 4th was to use FakeDb to mock the Sitecore items you need to run your tests. I’d heard about FakeDb before but not used it so it was nice to see an example of how this is done.

Alastair also showed us how Sitecore.LiveTesting can be used to spin up an instance of Sitecore in a container in the background to test against.

It was a bit slow but seemed really cool and definitely something I’m going to experiment with.

The key message here was, whatever you do make sure you create tests and don’t get hung up on if they are real unit tests or actually integration tests.

Sadly it was now time to head to get our flight home so I missed out on the last talk of the day by Martina Welander on refactoring doc.sitecore.net, hopefully I can find it on Google Hangout.

SUGCON was a great experience and It has given me a whole lot of ideas and things to look into for current and future Sitecore projects. Thanks to the Sitecore Community and the sponsors for putting on the event.

My only regret is not having chance to chat to any of the MVPs who have been so helpful on Slack and on their blogs, but I’ll definitely be back next year so I’ll buy you a beer or two then instead.

Till next time.