Saturday, 17 November 2018

Renderings static binding

Last time I had to prepare a component which behaves like a carousel of specific type of renderings. Instead of copy-pasting the Razor markup or using basic Razor partials I decided to use static binding of renderings - method I've never used before. It appeared to be extremely handy.

Basically you can specify a rendering like this:

@Html.Sitecore().Rendering("{ rendering ID }", new { Cacheable = true, Cache_VaryByData = true, DataSource = "{ DataSource ID}" })

First parameter is rendering ID, second is anonymous object where we can specify additional properties, like caching or even datasource that will be used there.

You can even add your custom properties and read them inside rendering, just like this:

@Html.Sitecore().Rendering(
    Constants.MyRendering.RenderingId.ToString("B"),
    new
    {
        Cacheable = true,
        Cache_VaryByData = true,
        DataSource = myDatasource.Id.ToString("B"),
        MyProperty = "My custom value"
 })

To be more familiar with possible properties of that anonymous object I have decompiled GetRendering method from SitecoreHelper class:


I have created and extension method to easily retrieve rendering properties:

And you can use it in view like this:

var property = Html.Sitecore().GetRenderingProperty("MyProperty");


Thursday, 4 October 2018

Sitecore PowerShell Extensions - Custom function

Last time I had to prepare a resolution for making changes on the existing content after the deployment. We were adding new components to Standard Values of the page and they had to be configured properly on the content item by setting data source. Change like this couldn’t be synchronised by Unicorn as the page content item was one-time deployment only item (NewItemOnlyEvaluator) and setting data source straight on Standard Value is a really bad idea!

We had three options there:
  1. Set data source manually after synch
  2. Create a Sitecore content package with prepared changes
  3. Prepare Sitecore PowerShell script that will automate the changes we need
As doing things manually is always error-prone and package could overwrite some content changes, we decided to go for third option – PowerShell scripting!

First of all, I needed a way for setting data source on rendering that already exists on a page content item. I found there is not such specific function in SPE core so I wrote a custom one.





To create a custom SPE function we need to have new module created. The easiest it will be by using wizard:





We will need Shared Functions integration, so we can select it just while creating the module.



It can be done after as well just by creating scripts library called Functions. Here's link to documentation: https://doc.sitecorepowershell.com/modules/integration-points/functions

After this we will have our module folder with Functions folder inside. There we will create our custom shared function.


I have named it Set-RenderingDatasource.  Body of the function should be placed inside field described as Script body - Source code written in PowerShell. That's the function I've shown earlier. 

Next thing will be create new PowerShell Script Library item, just on the same level as Functions item. I named it as After Deploy Scripts and created one new script inside - Apply-Datasources:



This script will use our custom shared function to apply datasources to items. Here is the code:



First crucial thing is to import our shared function

Import-Function -Name Set-RenderingDatasource

Then I have added a flag for rolling back changes if needed. That's a subject of decision how we should do the rollback. For this example rollback will be simply setting empty datasources to that items - as they are empty at beginning.

Under I've added variables that will contain ID of the page where we want make our updates, references to rendering items we want to set datasource and ids of datasources. All those things should be known, as we are assuming they will be deployed by, e.g. unicorn (new renderings and datasources - one time deployment) or they are in the content already for some time - the page we want to update.

Then, based on the rollback flag, I'm using our imported function to set up datasources

Set-RenderingDatasource -Page $updatedPage -Rendering $modalRendering -DatasourceId $modalDatasourceId -Device Default -Publish

 Let's roll now! Let's edit our script in ISE!

And run it to see the result:


It's good to log the things script does and say something at the end of execution.

Done! I hope that was interesting lesson of using Sitecore PowerShell to apply changes after deployments. Enjoy!

Tuesday, 11 September 2018

Sitecore Module - Dynamic Sitemap XML version 2.0

I have released updated and rewritten version of my Dynamic Sitemap XML module.Version 2.0 comes with better structure of the code and gives much more flexibility in extending it. Now it uses Sitecore Web index by default to improve the performance.

Whole code is hosted on GitHub just like before at https://github.com/ReoKzK/Sitecore.SharedSource.DynamicSitemap.


It can be added to solution by nuget package:

Install-Package Sitecore.SharedSource.DynamicSitemap -Version 2.0.0

Tuesday, 21 August 2018

HelixComponents - Gallery of frequently used website modules

I have released first part of my HelixComponents project. It's aim is to create reusable components that can be used across Helix-based projects.


Each module will be released as a separate repository, which is basically a Helix project. All of them can be taken from my repo at Github: https://github.com/ReoKzK/HelixComponents.
It is based on Helixbase and contains all of these modules.

Here are the first projects:

HelixComponents.Feature.Recommended

Contains modules used for content promotion

HelixComponents.Feature.Tabs

Tabs components - Work in progress

Soon I'm going to release more and fix any outstanding issues

Sunday, 10 June 2018

Sitecore 9 installation scripts

As Sitecore 9 installation is much different than in previous versions and we have now Sitecore Installation Framework, I would like to share with you my installation PowerShell scripts.

First of all, many thanks to George Chang for the Sitecore 9 install script which I based mine (https://blogs.perficientdigital.com/2017/10/23/how-to-install-sitecore-9-with-the-sitecore-install-framework/).

First thing you will need to do is have Solr installed. It is required from v.9.0 to have Solr running and on SSL. There is a great post by Jeremy Davis about installing Solr easily by his PS script - https://jermdavis.wordpress.com/2017/10/30/low-effort-solr-installs/.

After we have Solr installed and running on https we can start installing our Sitecore 9 instance.

We need to have Sitecore Installation Framework installed to our PowerShell. Here is the script that takes care of it:

 

And here is the Sitecore 9 installation script itself. There is a configuration object as first in the code, you can specify there Sitecore version to install, SQL Server credentials and Solr configuration.


All scripts are available on my GitHub: https://github.com/ReoKzK/Sitecore9-Installer


Saturday, 19 May 2018

SIF Sitecore 9 installation issue

A couple days ago I came across a problem while installing Sitecore 9.0.2 using SIF:

.Net SqlClient Data Provider: Msg 12809, Level 16, State 1, Line 5
You must remove all users with password before setting the containment property to NONE.

I was using MS SQL Server 2016 (13.0.4001.0). After opening Management Studio I realized that some databases were created already because at first run my script went to some point then failed. So the easy fix go go through this issue was just to remove these databases as they were only partially completed.

Saturday, 7 April 2018

Configuring Unicorn on Helix project

Setting up synchronization in Helix based solution is one of the most crucial things. With proper configuration all new projects will be easy to maintain and predictable. In this short post I will describe basics of configuring Unicorn.

Helix structure configuration

First of all we should have our Foundation.Serialization project configured. In this project we should install Unicorn - from the nuget feed.

We should have whole Helix items structure configuration here and this one should be synched as the first in the queue.


There is unicornSourceFolder variable which should be pointing /src/ folder of our app code. We can specify it for example in some patch in Project.Common project.


 

Abstract configurations

It is really good idea to have some basic configuration we can inherit from. It can be placed in for example Foundation.Serialization project.





Then we can use this abstract configuration in our projects




We do it by using extends parameter

extends="SitecoreCoffee.Base"

If our project is relying on some other, e.g. from Foundation layer, then we should specify it by dependencies parameter. Here it depends on whole Foundation layer by using asterix

dependencies="Foundation.*"

...but it could be as well list of comma-delimited configuration names

dependencies="Foundation.Search,Foundation.Extensions"

As I mentioned earlier, Foundation.Serialization configuration should be synchronized as first, so the our patch should go after that one:

patch:after="configuration[@name='Foundation.Serialization']"

Don't forget to put descriptive name and description attributes too.

Project-specific configurations

In Helix every project which requires some serialized Sitecore items, should have it's own Unicorn configuration. Above we created Feature.Search project configuration and there we put only project-specific items in the predicate

<predicate type="Unicorn.Predicates.SerializationPresetPredicate, Unicorn" singleInstance="true">
    <include name="SitecoreCoffee.Feature.Search.Templates" database="master" path="/sitecore/templates/Feature/Search" />
    <include name="SitecoreCoffee.Feature.Search.Renderings" database="master" path="/sitecore/layout/renderings/Feature/Search" />
</predicate>

Even if you're not using Helix you should consider creating several small configurations instead of one monolithic. It will be easier to synch only specific ones in Unicorn synch panel.