Experience Sitecore !

Just a cheat sheet for myself to have them here all in one place so that I bookmark this URL and don't waste time digging out all sorts of documentation in order to find the right one. Taken out from here and here.

Available tokens:

• $compatibleThemes - path to all themes
• $theme - currently used theme
• $pageDesigns - root of page designs
• $partialDesigns - root of partial designs
• $currenttemplate - name of the current template
• $tenant - path to the current tenant
• $site - path to the current site
• $home - path to the current site start item (Home)
• $templates - path to the current sitetemplates
• $siteMedia - path to Virtual Media folder located under site
• $sharedSites - for multiroot fields, resovles shared site for current tenant.

Recently I came into a weird situation. So, to start with ...

I got Sitecore 9.0 update 2, installed SXA 1.8 for 9.0 on top of it. Created a tenant and a site, also made few pages for test and some initial settings as we usually do as per documentation, so far so good. 

Then I made a solution, configuration and serialized everything I made on the previous step, then reinstalled an instance in order to test my solution, configuration and serialization deploys well on top of clean Sitecore and to confirm everything works as expected.

Build process went fine, deployment worked well, Unicorn ran and created the site with all my pages and all relevant items - all good, except for one issue. Before Sitecore reinstallation, a new page in Experience Editor looked that way:

After the deployment on top of the new clean instance, running Experience Editor brought the following layout:

Clearly, there was something missing from either my configuration or serialization. So I started troubleshooting and comparing.

In both scenarios, I had instances sites of the same version and both with SXA 1.8. Since this issue was reproducible, next time I made git init just within webroot in order to get a version diff with a post-deployment state, so that I could see all modified files and see the diff as I usually do with git tools. However, nothing suspicious found at bin and within App_config folder. Deployment went as expected so that should be something in Sitecore then.

First of all, I compared templates and standard values, but they were the same for both cases. Next, I ensured presentation details are also identical, even ensured Layout files and binary equal.  Yes, it contains body-top placeholder, but in one scenario it is presented for some reason.

Then I went to the actual page items in order to compare those, but they were also the same. View options have same parameters checked. No idea then...

Finally, after spending plenty of time I figured out that something was wrong with SXA themes. Unfortunately, did not identify what exactly causes the problem, but after re-creating it at serialization config and re-serializing items the issue has gone. So, the outcome is: if you see unexpected placeholders - please make sure your SXA theme is in the correct state and serialized properly.

I was very anticipating to upgrade my solution to recently released XP 9.1 with SXA 1.8 and all its great features, however, I got a dependency on Sitecore Commerce, which hasn't (yet) updated to 9.1. Got nothing to do with that, but just wait for a month or so until XC 9.1 is out...

But wait, why not just update at least SXA to version 1.8 meanwhile? SXA 1.8 comes for both versions for 9.1 and 9.0 which means - in two runtimes .NET 4.7.1 and .NET 4.6.2 correspondingly. Done, upgraded. SXA 1.8 works well on top of clean Sitecore 9.0 update 2 instance for me.

But when it came to updating NuGet packages in my solution, I was unable to do so because NuGet packages for my version for some reason demand .NET 4.7.1:

And that is my error:

Package Sitecore.XA.Feature.CreativeExchange 3.8.0 is not compatible with net462 (.NETFramework,Version=v4.6.2) / win-x86. Package Sitecore.XA.Feature.CreativeExchange 3.8.0 supports: net471 (.NETFramework,Version=v4.7.1)

Version 3.8.0 is the correct version of SXA 1.8 for 9.0 and it should support .NET 4.6.2, not 4.7.2. Version of SXA 1.8 for 9.1 has number 4.8.0 and that one indeed supports 4.7.1 runtime.

Since I cannot do anything about NuGet feeds, I turned back to the old lib\LocalRepository folder in my solution, simply copying all the required SXA 1.8 libraries from instance webroot (where I have SXA 1.8 working with clean 9.0 update instance) and referencing them instead from affected projects. 

That did me a job for the moment. I will either update to the NuGets once it is fixed with the correct version or upgrade the entire solution to 9.1 when XC 9.1 is out, whatever comes earlier.

Just in case you are facing the certificate error while installing Sitecore 9.0 update 2 with SIF 1.2.1 as step CreateSignedCert : NewSignedCertificate, as below:

Install-SitecoreConfiguration : Cannot process argument transformation on parameter 'Signer'. Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System.Security.Cryptography.X509Certificates.X509Certificate2".

The issue is coming from having the certificate already in a system, so you might manually delete that those from Microsoft Management Console (mmc.exe from Windows start menu).

In my case, I had several certificates named DO_NOT_TRUST_SitecoreRootCert installed under Certificates - Current User - Trusted Root Certification Auhorities- Certificates, deleting them helped progress.

Hope this helps!

In one of my previous posts, I've explained how Install-SitecoreConfiguration works in SIF and how to use it for package installation.

As time passed, more and more functionality got natively embedded into SIF, that included some useful things such as config transformations, publishing, rebuilding indexes, and of course, packages/modules installation. I decided to inspect what actually went into the platform and extracted this functionality out of Commerce product for those who want to benefit from package installations with SIF bit does not want to bother with XC9.

So, actually, there is not a big change compared with my previous post. On the lower level, there is still a temporal folder being exposed and *.aspx page placed for actual job to be done. The good thing is that plenty of that functionality now supported out of the box

For legal reasons I cannot include downloadable ready to use package, since the code and scripts belong to Sitecore who only can share it. Instead I will tell you how you can make it on your own copy of Sitecore Commerce 9.0 update 2.

You'll need three parts - Configuration, Modules and SiteUtilityPages, all carefully from within SIF.Sitecore.Commerce.1.2.14 folder:

• Configurations (json files) taken out of Configuration\Commerce\Master_SingleServer.json and Configuration\SitecoreUtilities\InstallModule.json
• Then you'll need three modules from Modules folder: InstallSitecoreConfiguration, ManageCommerceService, SitecoreUtilityTasks
• Also you need SiteUtilityPages folder with InstallModules.aspx file within

If you do not keep a structure as from Commerce Installer (as didn't I) - please make adjust paths of dependencies correspondingly.

Last but not the least, you need to modify main Deploy-Sitecore-Commerce.ps1 PowerShell script, removing everything apart from package installation out of it. I renamed it into Install.ps1 and here is what I end up with:

param(
		[string]$SiteName = "habitat91.dev.local",	           # your sitecore instance name
		[string]$ModulePath = "p:\PowerShell Extensions-5.0.zip"   # path to the module to be installed
)

$global:DEPLOYMENT_DIRECTORY=Split-Path $MyInvocation.MyCommand.Path
$modulesPath=( Join-Path -Path $DEPLOYMENT_DIRECTORY -ChildPath "Modules" )
if ($env:PSModulePath -notlike "*$modulesPath*")
{
    $p = $env:PSModulePath + ";" + $modulesPath
    [Environment]::SetEnvironmentVariable("PSModulePath",$p)
}

$params = @{
		Path = Resolve-Path '.\Configuration\Master.json'	
		SiteName = $SiteName
		InstallDir = "$($Env:SYSTEMDRIVE)\inetpub\wwwroot\$SiteName"		
		SiteUtilitiesSrc = ( Join-Path -Path $DEPLOYMENT_DIRECTORY -ChildPath "SiteUtilityPages" )	

		ModuleFullPath = Resolve-Path -Path  $ModulePath
    }

Install-SitecoreConfiguration @params

and below there is my tree structure:

In case you are working outside of inetpub\wwwroot folder, please also adjust the path for InstallDir variable.

Hope this helps your DevOps!

Today I am proud to be one of the first folks globally who managed to pass Sitecore Commerce 9 exam after the eLearning course.

There are 50 questions in total anв you need to get 80% of correct answers (I managed to get 88%) in order to pass. All these questions are split into these categories (but not only):

• Sales
• BusinessTools
• Sitecore Commerce
• Features
• Catalog
• Pricing
• App-Price-Cards
• Inventory
• Modify-Sellable
• Customers
• Profiles
• Conv-Cart
• Mang-Order
• App-Coup
• Conf-Coup
• Create-Coup
• Commerce EngRole
• CommerceEngine
• CommerceEngPlugin
• Security
• SDK
• Nuget
• SXA
• Search
• Navigation
• Cart
• Entitlement
• Fulfilment
• Payment
• Orders
• Plugins
• RulesI

For preparation, I was guided by the materials from this StackExchange answer: https://sitecore.stackexchange.com/questions/12771/how-to-start-development-with-sitecore-commerce-9-sitecore-commerce-9-learning.

Happy learning!

1. SIF
2. Business Tools
3. Storefront
   

1. You are getting 500.19 error during SIF. Other people who came across advice that you are to install ASP.NET Core 2. That's correct, as Commerce micro-services utilize .NET core, but not everything. There was a strong assumption of something missing from IIS or being mis-configured, so in my case it was this component unchecked:

Also, keep in mind you must have URL-Rewrite module installed (the easiest way is: choco install urlrewrite).

Another non-critical error I am getting from time to time is "The service cannot accept control messages at this time". IIS does respond at the moment - you may run iisreset and try warm it up by hitting URL manually in browser. Then repeat SIF deploy.

If SIF is complaining about duplicate certificates, you may need to delete those from Microsoft Management Console (MMC). In order to do that, click Start button, then type in mmc and hit enter. Once there, File - Add/Remove Snap-ins and select Certificates, as on screenshot below:

One more error from SIF: "Error: Unable to add user SITECOREDEV\WindowsUserName. Details: Database 'sc902com_Core' does not exist. Make sure that the name is entered correctly." In that case, ensure you're referencing correct database name for SitecoreCoreDbName variable (line 29 of default deploy script)

2. Running Business Tools may bring an error. In some previous versions Business Tools desktop icon was referencing invalid port, so make sure it is 4200 (by default). You can do that by changing Link field for Business Tools launchpad icon, as you usually do in corу database (item path: /sitecore/client/Applications/Launchpad/PageSettings/Buttons/Commerce/BusinessTools)

While running Business Tools, if you may see to following error:

The error means your browser needs a security exception for self-signed certificate, no worries - that's only for localhost and needs to be done once. Just open a new browser tab and follow to localhost:5000, confirming security exception, as prompted.

3. Once you have successfully installed Sitecore Commerce, you try to access storefront. So you hit URL in browser (sxa.storefront.com) and ... see default Sitecore home page. Why?

The first assumption coming into one's mind is that since storefront is running on top of SXA - you should configure the hostname at HostName field of /sitecore/content/Sitecore/Storefront/Settings/Site Grouping/Storefront item. But wait! sxa.storefront.com is the default value and already presents there. Does it work now? Nope ...

Firstly, try open storefront in Experience Editor (from master database). If you see the right storefront - just re-publish site, and update indexes - it will work from web database then. But if not - the answer is different: it appeared that my current partner's license does not include SXA. Not obvious, but when you're out of license - storefront default to Home page rather than notify you re. that error.

Remember, that you may apply for a developer trial license valid for two month that will include all the features of Sitecore, including SXA and JSS.

It is 2.5 years already since I launched Sitecore.Link project and it made a great input to the community in terms of accumulating and finding technical information. It served well as a starting point for those willing quickly to obtain all available knowledge about some specific aspects of Sitecore as all the links are split into 150+ categories from 15+ top-level areas (ie. SXA, Helix, Security, Media etc.)

From the back-end prospective Sitecore.Link is one of the greatest things I've ever done, with all automation, crawlers and bit of artificial intelligence and machine learning, finding the new materials and taking off all the monotonous work from me, except the one and only thing I should do - taking the decision (on adding that particular link to the collection after reading it).

Speaking about front-end and UX I can now say that things were also great 2 years ago when the project gained 1-2K of links, not 16K+ as for today. It offered real-time predictive input, powerful filtering and few more. But many of these features came out of PoC (as well as the project itself entirely) and have been added more or less spontaneously in the limited timeframes (yes, I have a full-time job plus 3 hours of commute each day), that's why front-end and UX did not expect such a growth of data. I bravely optimized everything as much as could until hitting the performance ceiling of rendering. So it was just a matter of time when to perform reUX and rewrite, rather than whether to.

Finally, the time has come! I am doing the entire rework of Sitecore.Link project.

When attending SUGCON 2018 I was very enthusiastic to find out how perfectly GraphQL stands for querying the data. Since front-end of Sitecore.Link is, in fact, a single page application - JSS would suit the best, while the data itself becomes bucketable implementing new taxonomy. So, as for the moment, I came to the following changes:

Most of back-end and crawlers will remain as they are. From the new features, apart from changing data storage, I plan to add a page where blog authors will be easily able to test and adjust their resources for Sitecore.Link parser them further automatically, and even see how crawlers process their blogs in real-time.

Front-end will entirely rework UI to fit visitors' day-to-day needs to be as quick as possible. UI will be re-written to Vue.js backed by Sitecore Javascript Services (JSS)

At the moment, only blog names are searchable, but after changes will take place all articles' content also becomes tokenized for relevancy in order to provide more precise results and order. Such a nice Sitecore Google will be born, lol)

Once completed, the project will be delivered to Azure PaaS for hosting.

Outcomes

One of the most important things - when done, the source code becomes opensource (MIT) on GitHub - this will bring to the community a real-world example of JSS-running website (but not only - plenty of Sitecore features will be there as implementation example for others). Since the project is community-based and is fed by the community-driven data, it will serve the community in full, including the source code to be hared and ideally pull-requested with new features or fixes.

Another community support back to the project will become a browser extension for submitting currently open URL (of a blog post) into the links database by specifying relevant categories as well as other information, after a quick moderation of course.

Numerous blog posts from myself, describing the changes implemented and sharing the experience of JSS and other features done will accompany this transformation.

In order to make all mentioned above happen, I finish my current contract and do not pick anything next in the following 2 months, to be able fully to concentrate on this amazing challenges. I am also looking for any support from Sitecore Technical Marketing team on technical issues

Introduction. Most of you are already familiar with Sitecore PowerShell Extensions (SPE). This is a genius module written by Adam Najmanowicz and Michael West, that not just brings the power of console into Sitecore, allowing to maintain and automate almost everything, but also integrates that into Sitecore UI so that one may have pretty nice reports on virtually anything in their system. But today I am going to tell you about one underestimated part of SPE - Remoting,

What is Remoting? Old school developers remember this term from the first version of .NET where it used to name the technology of building distributed applications with purely means of the framework in pre-RESTful years. Not a nice term for not the best technology! But in SPE Remoting got more adequate meaning - executing scripts remotely. The idea is to allow running SPE script from the standarв Windows PowerShell console - in that case, a script is serialized and send for the remote execution to Sitecore server. That means it will be executed in the standard Sitecore context, same as normal SPE script you run in Sitecore PowerShell Console within your Sitecore instance. Then the results will be returned back to original you original system PowerShell window as if you ran them locally.

Why do I need that? Well, you may not realise you need that straight away, but being able to expose the power of SPE outside gives you an ultimate power of maintaining your instances internally. What firstly comes into my head is Continuous Integration - now you have the tool for managing content and precise fine-tuning everything within your instances. Not limited to - you also have access to servers filesystem, can download and upload files, same for media library, manipulate users and permissions. For example, you may automate regular downloading logs from all of your servers or whatever you may decide.

Great, I'm interested. How do I make it work? This article is all about setting up SPE Remoting for your instance and getting first results. So, here we go.

Firstly download Sitecore Powershell Extensions module itself (if you don't yet have) and install as you normally install the packages. The module is relatively large and it may take a while until it gets done. Then SPE becomes present in your Sitecore start menu:

SPE module comes already with remoting built-in however it requires few more steps to enable and configure it.

There is a new security role that becomes available upon SPE installation: sitecore\PowerShell Extensions Remoting. You must make your credentials user for external remoting connection (applies to users and/or other roles) to be a member of this role, even (and especially) if that is sitecore\admin. If you don't do that you will see following error:

Secondly, download SPE Remoting module for the same version you may find it there along with regular SPE on Marketplace:

Note - that is not a Sitecore module and it's not for Package Installer. The term "module" is too meaningful here and in current context it deals with PowerShell module. Instead, extract archive content into you PowerShell modules root folder - for example <YOUR_USER_FOLDER>\Documents\WindowsPowerShell\Modules\SPE folder

You may need to import that module first in order to use it from within Windows PowerShell console. Make sure you set the execution policy to:

Set-ExecutionPolicy RemoteSigned

and the import command:

Import-Module -Name SPE

Before writing a basic actual script, we also need to adjust configuration - module authors treat security seriously. The configuration file is located at: <INSTANCE_ROOT>\App_Config\Include\Cognifide.PowerShell.config and the article on how-to can be found here.

Since you are likely experimenting on your local machine and are more relaxed regarding security - you may get things sorted easier by applying a patch file to weaken security. Make sure you use if only for local dev and never in higher environments. As a bonus - the patch won't be overwritten when reinstalling the SPE module.

Finally, we can create and execute the script. As the very bare minimum, I suggest the very simple script for you to test. Create PS.ps1 and copy the below content into it:

Set-ExecutionPolicy RemoteSigned
Import-Module -Name SPE

$session = New-ScriptSession -Username admin -Password b -ConnectionUri https://platform.dev.local

Invoke-RemoteScript -ScriptBlock {
    Get-Item -Path "master:\content\Home"
} -Session $session 

Now execute that:

And voila! Although visually it is not as impressive, what actually happens on this screenshot is getting a simple query sent to Sitecore instance, executed remotely with the results returned back to Windows PowerShell, all transparently for the caller.

The reason for me to write the article was the number of efforts I spent on getting things understood, downloaded and setup, configured and executed. Some pieces of documentation are not available, while others not a descriptive. Once again, thanks to Michael West for his support, and hope this article will encourage you at least to try that!