Experience Sitecore !

Developers' guide to XM Cloud

•     why SaaS cloud? what is the change?
•     a brief overview of XM Cloud for developers    

•     review of the process and deployment tools available to a developer
•     local development for XM Cloud in containers
•     customizing pipelines with XM Cloud
•     leveraging SPE functions
•     Sitecore CLI becomes "The Tool"

•     using Site Builder
•     dealing with Pages & Components
•     extensions catalog
•     diversity of datasources: where can my content reside?
•     migrating content from legacy Sitecore platforms

•     Sitecore Unified Identity
•     integrating 3-rd party services

• where's my Solr?
• what are the options?
• plugging an external search technology

•     are my legacy sites still compatible with XM Cloud?
•     migrating headless site from XP to XM Cloud guidance
•     EDGE considerations
•     is my legacy module for XP compatible with XM Cloud?

•     new old Headless SXA - what's the difference
•     new old rendering variants
•     can we use headless forms on XM Cloud?
•     a bare minimum to build Headless SXA site for Next.js

•     starter kits available for you straight away
•     leveraging Headstart basic starter kit foundation built for XM Cloud
•     make your own module compatible with XM Cloud

•     are the built-in rules enough to go?
•     two ways of leveraging CDP/Personalize for a better experience

•     Single-location? Will that affect my GEO-distributed authors team?
•     Understanding terminology: deployment, project, environment
•     Understanding Build and Deployment Service (how to trigger and its lifecycle)
•     CLI along with DevEx plugins
•     GUI-powered Deploy App tool and 
•     auto deployments from connected GitHub

Infrastructure as Code (IaC) is an approach that involves describing infrastructure as code and then applying it to make the necessary changes. IaC does not dictate how exactly to write code, it just provides tools instead. A good examples are Terraform, Ansible and Kubernetes itself where you don't say what to do, rather than you dictate what state you want you infrastructure to get into.

Keep the infrastructure code readable. Your colleagues would be able to easily understand it, and, if necessary, add or test it. Looking to be an obvious point, it is quite often is forgotten, resulting in “write-only code” - the one can only be written, but cannot be read. Its author inclusive, and is unlikely to be able to understood what he wrote and figure out how it all works, even a few days afterward.

An example of a good practice is keeping all variables in a separate file. This is convenient because they do not have to be searched throughout the code. Just open the file and immediately get what you need.

Adhere to a certain style of writing code. As a good example, you may want keeping the code line length between 80-120 characters. If the lines are very long, the editor starts wrapping them. Line breaks destroy the overall view and interfere with the understanding of the code. One has to spend a lot of time just figuring out where the line starts and where it ends.

It's nice to have the coding style check automated, at least use by using the CI/CD pipeline for this. Such a pipeline could have a Lint step: a process of statistical analysis of what is written, helping to identify potential problems before the code is applied.

Utilize git repositories same way developers do. Saying that I mean developing new branches, linking branches to tasks, reviewing what has already been written, sending Pull Requests before making changes, etc.

Being a solo maintainer one may seem the listed actions to be redundant - it is a common practice when people just come and start committing. However, even if you have a small team, it could be difficult to understand who, when, and why made some corrections. As the project grows, such practices will increasingly help the understanding of what is happening and mess up the work. Therefore, it is worth investing some time into adopting some of the development practices to work with repositories.

Infrastructure as Code tools are typically associated with DevOps. As we know DevOps as specialists who not only deal with maintenance but also help developers work: set up pipelines, automate test launches, etc. - all the above also applies to IaC.

In Infrastructure as Code, automation should be applied: Lint rules, testing, automatic releases, etc. Having repositories with let's say Ansible or Terraform, but rolled out manually (by an engineer manually starting a task) is not that much good. Firstly, it is difficult to track who launched it, why, and at what moment. Secondly, it is impossible to understand how that worked out and draw conclusions.

With everything kept in the repository and controlled by an automatic CI/CD pipeline, we can always see when the pipeline was launched and how it performed. We can also control the parallel execution of pipelines, identify the causes of failures, quickly find errors, and much more.

You can often hear from maintainers that they do not test the code at all or just first run it somewhere on dev. It's not the best practice, because it does not give any guarantee that dev matches prod. In the case of Ansible or other configuration tools, standard testing could be something as:

• launched a test on dev;
• rolled on dev, but crashed with an error;
• fixed this error;
• once again, the test was not run because dev is already in the state to which they tried to bring it.

It seems that the error has been corrected, and you can roll on prod. What will happen to prod? It is always a matter of luck - hit or miss, guess or miss. If somewhere in the middle, something falls again, the error will be corrected and everything will be restarted.

But infrastructure code can and should be tested. At the same time, even if specialists know about different testing methods, they still cannot use them. The reason is that Ansible roles or Terraform files are written without the initial focus on the fact that they will need to be tested somehow.

In an ideal world, at the moment of writing a code developer is aware of what (else) needs to be tested. Accordingly, before starting to write a code, developer plans on how to test it, commonly know as TDD. Untested code is low-quality code.

The same exactly applies to infrastructure code: once written, you should be able to test it. Decent testing allows to reduce the number of errors and make it easier for colleagues who will finalize your roles on Ansible or Terraform files.

A few words about automation. A common practice when working with Ansible is that even if something could be tested, there is no automation to it. Usually, this is a case when someone creates a virtual machine, takes some role written by colleagues, and launches it. Afterward that person relizes the need to add certain new things to it - appends and launches again on the virtual machine. Then he realizes that even more changes are equired and also the current virtual machine has already been brought to some kind of state, so it needs to be killed, new virtual machine reinstantstiated and the role rolled over it. In case something does not work, this algorithm would have to be repeated until all errors are eliminated.

Usually, the human factor comes into a play, and after the N-th number of repetitions, it becomes too lazy deleting the VM and re-creating it again. Once everything seems to work exactly as it should (this time), so one seems could freeze the changes and roll into the prod environment. But reality is that errors could still occur, that is why automation is needed. When it works through automated pipelines and Pull Requests are used - it helps to identify bugs faster and prevent their re-appearance.

Explain to me as I was 5 years old.

Well, not sure that could be explained to 5 years old, but will instead explain it as you were not around the changes for lets say the past 5 years. There is a lot to go through. Before explaining the most interesting concepts like XM Cloud and Sitecore Edge, I need briefly touching some terminology they rely on.

Headless

Previously you used Sitecore to render HTML using ASP.NET MVC. All that happened server-side: Sitecore pulled up the data and your controllers built views with that content, resulted combined HTML being sent out back to a calling browser by a CD server. So that meant, would you need just raw content or data not being wrapped with HTML, then the only way would be setting up duplicating WebAPI, which could be clumsy in addressing the correct data. Or that could be too verbose, returning you much more data than you need. In any case - too exhaustive!

So it comes up logically: why not make the raw data returned universally through API? It could be then consumed by various callers like mobiles or other systems, even some content aggregators, not just browsers (that is what is called "omnichannel"). This is why the approach is called "headless" - there is no HML (or any other "head" returned along with your data).

Rendering Host

When it comes to browsers that still need HTML: it makes sense to merge the content with HTML somewhere later on a request lifecycle - after it left you the universal platform endpoint that you still have on your CD. There is still a webserver required to serve all the web requests. It will receive a request, then pull some required raw data from a universal endpoint, then render output HTML with that data. This is why such webserver is also known as a "rendering host" - now we clearly separated serving actual raw data from rendering HTML to be returned to the browser. Previously both steps were done at a single point on CD.

GraphQL

Once read above, you could think that serving all the content through WebAPI would be some sort of overkill, that is especially valid for large and complicated data. More to be considered about adequate caching. Even with a headless approach, imagine pulling a large list of books stored in some database and having a reference with authors by authorId field. 

So you either do lots of JOIN-alike operations and expose lots of custom API endpoints to fit data the way your client needs that, or take pulls of all-the-data from a database, cache it in somewhere memory, and keep "merging" books to authors on the fly (in memory JOIN per-request). None of both is a nice solution. In the case of really large data, there won't be an elegant solution.

So there was a clear need for some sort of flexibility, and that flexibility should be requested by a client application, addressing its immediate need for data. Moreover, often clients want to return a specific set of data and nothing else above what is being requested - mobile apps typically operate expensive and potentially slow mobile lines, compared to inter-data center superfast networks between CD and Rendering Hosts. Also, headless CDs always return meaningful and structured data of certain type(s), which means it could be strongly typed. And where there are several types, those could relate. We clearly need a schema for data.

That is how GraphQL was invented to address all the above. Instead of having lots of API endpoints we now got a universal endpoint to serve all our data needs in a single request. It provides a schema of all the data types it could return. So now it is the client who defines what type(s) of data to request, defines how those relate together, and the amount of data it needs - not more than it should consume. Another benefit of predefined Shema is that now knowing it in advance, writing a code for clients' apps is quicker thanks to autocompleting, likely provided by your IDE. It also respects primitive types supporting all the relevant operations (comparison, orderBy, etc.)

Sitecore Edge

Previously with XP, you had a complex setup most important of which were CM and CD instances fed by corresponding databases - commonly known as master and web. Editors logged into CM, created some content, and published it from master to the web database to be used by CD.

Now imagine you only got a CM part from the above example. When you do publish, it publishes "into a cloud". By "cloud", it meant a globally distributed database with CDN for media along with some API (GraphQL) to expose content for your front-end.

In fact, not only from CM content could reach Edge and be served from it - Content Hub could be another tool, performing like XM does.

Previously you had a CD instance with a site deployed there that consumes data from a web database, but no you neither have those nor Sitecore provide it for you. That means you should build a front-end site that consumes data from a given GraphQL. That is what is called headless, so you could use JSS with or without Next, or ASP.NET Core renderings. Or anything else - any front-end of your choice, however with more effort. Or it could be not a website at all, but a smart device consuming your data - the choice is unlimited. Effectively, we've got something as CD data as a service provided, maintained, and geo-scaled by Sitecore.

XM Cloud

From the previous explanation you've learned that Experience Edge is "when we remove CD instance and replace Web databases with a cloud service". Now we want to do exactly the same with XM. Provided as a service, it always has the latest error-prone version, maintained and scaled by the vendor. Please welcome XM Cloud and let's decouple all-the-things!

Before going ahead, let's answer what was a typical XM in Sitecore as we knew it, and what it expect to do?

• create, edit and store content
• set up layout and presentation for a page
• apply personalization
• publishing to CD
• lots of other minor things

Publishing has been already optionally decoupled from XM in for of Sitecore Publishing Service. That works as a standalone web app or an individual container. Its only duty is copying required content from CM to CD and doing it perfectly well and fast.

Another thing that could be decoupled is the content itself. Previously it was stored in the CM database in a form of Sitecore item abstraction. What if we could have something like Content-as-a-Service, where a data source could be supplied from any source at all that supplies it through GraphQL - any other headless CMS or professional platforms, such as Content Hub? That is very much a "composable" look and feel to me! Then it comes to total flexibility, after setting up the data endpoint, authors could benefit from autocomplete suggestions coming from GraphQL schema when wiring up their components.

Personalization also comes as a composable SaaS service - Personalize. Without using one XM Cloud will also offer you some basic personalization options.

Speaking about a layout, it also could be decoupled. We already have Horizon as a standalone webapp/container, so whatever its cloud reincarnation appears to be (ie. Symphony-?) - it gets decoupled from XM engine. There will be an old good Content Editor anyway, but its ability to edit content is limited to Sitecore items from the master database, unlike Symphony being universal.

Sitecore Managed Cloud

Question: so is XM Cloud something similar to Managed Cloud, and what is the difference between those?

No, not at all. Sitecore Managed Cloud hosts, monitors, manages, and maintains your installation of the platform, on your behalf. They provide infrastructure and the default technology stack that suits it in the best way. Previously you had to care for an infrastructure yourself, which took lots of effort, and that is the main thing that changes with Managed Cloud. Managed cloud supports XM, XP and XC (however on premium tier).

XM Cloud as the opposite - is a totally SaaS offering. It will be an important part of Sitecore Composable DXP where you will architect and "compose" an analog of what was XP from various other Sitecore products (mostly SaaS, but not mandatory).

That is what XM Cloud expected to be in a composable spirit of modern DXP for 2022. Hope we all enjoy it!

Finally, I am happy to complete Sitecore learning and certification by successfully passing the OrderCloud Certification exam. In this post, I will try to share some thoughts and insights on how you could also progress with it.

This exam was relatively easy, especially compared with other Sitecore certifications. Have to note that I've read almost the whole documentation available, took the eLearning course, and did the notes for every minor important point - so did not find it tough.

I managed to score 90% being hesitative on 6 questions of a total of 30 which gives the exact 20% above the required 80% for a successful "pass" result. Basically, in that case, gambling out at least one question takes the score above the pass level. I want to admit that test questions seem to be very reasonable chosen and mature, as the product itself is.

In order to succeed, you'll definitely need to progress through the following materials:

• Official Study Guide
• API Reference
• Knowledge Base
• eLearning: Sitecore OrderCloud Fundamentals
• PostMan collection and extremely valuable training exercise over it

Please note: eLearning is really good but does not cover all the competencies. It covers the Security and Product areas really well but has nothing about Order and Fulfillment (at the moment of writing this blog - there is a 'coming soon' promise, however). That means you must get on your own learning path.

I created a Sitecore OrderCloud Telegram channel where I am sharing everything related to this platform. If you're using Telegram messenger - you'll definitely want to join by following this link. Otherwise, it is still possible to read it in a Twitter-like format in the browser using another link.

I am proud to be chosen as a presenter at SUGCON 2022 which took place in Budapest. 

This blog post contains the supporting material for my topic "The Mastery of Sitecore Upgrades".

Content

• Why upgrade?
• Planning the upgrade
• Recap legacy tools
  • Express Migration Tool
  • The Update Center
• Upgrade tactics
  • Affixing the state
  • Hyper-V
  • PowerShell
  • Quick Proof-of-Concept
  • Get recent master DB
  • Newer Sitecore released meanwhile?
  • Take comprehensive notes
• Content migration
  • Content maintenance
  • Content migration options
  • Content security
  • Dynamic placeholders
• Upgrading codebase
  • Identify customization
  • Find customization with ShowConfig
  • Incorrect DLL(s) coming from the deployment
  • Assembly bindings
  • NoReference packages
  • Migrate from packages.config to PackageReference
  • Update Target Framework
  • Update Visual Studio
  • Unsupported third-party libraries
  • Dependency injection
  • Glass Mapper 4.x to 5.x
  • Custom pipelines
  • Link Manager
  • Caching changes
  • Forms
  • Support Patches & Hotfixes
  • SXA
  • Sitecore Search
  • Custom content database
  • Upgrading xDB and analytics
• Changes in Sitecore 10.X
  • Containers
  • Upgrade databases
  • Items as Resources
  • Sitecore UpdateApp
  • Asset images
• Testing and going live
  • Testing
  • Monitoring
  • Security Hardening
  • Switching DNS record

Why upgrade?

Why do we upgrade Sitecore given it is not that quick and easy? The answer is simple – a carrot and a stick motivation!

The Stick: every New Year Mainstream support expires for one or a few versions. This means Sitecore still provides security updates and fixes, they do not support development and compatibility queries. Read more details about it at Sitecore Product Support Lifecycle.

Now, the Carrot: companies update due to the new features or new experiences. For example, you may read a detailed article I wrote about those in the latest version - New features in 10.2 you must be aware of.

Also, having the latest version is especially valuable in front of Composable DXP, which already takes place:

Planning the upgrade

Propper planning is the key to success. How do we perform the planning and what should be considered?

1. Upgrading vanilla Sitecore would cost you minimal effort, but with the more custom code you have - the more labor is expected to commit. How much is it customized? These will affect your timescale and impose additional risks which is better to know in advance.

2. If you get access to any of the existing documentation - that would be a perfect place to start. And it will likely give some answers to the previous point.

Find the details about all environments, code branches, and which code branch is deployed to which environment. Also, you will be interested in the details about existing CI/CD pipelines.

3. Find the custom configurations made into the Sitecore.

4. Finally, talk to stakeholders! Who if not they know the details and are the most interested in the success!

5. It sounds logical that the more versions you jump through – the more complicated the upgrade process will be.

9. Every solution is unique, and the same unique the teams are. Estimates must consider these factors, along with previous relevant experience of your team. Make sure you will have the resources for the whole duration of the upgrade also care about the fallback plan if someone gets ill or leaves (also known as "bus factor").

10. Also take a look at Sitecore compatibility guide to ensure all your planned tech spec stays valid.

Recap legacy tools

Before heading to the upgrade tactics, let’s quickly recap some upgrade tools we did have over time and how they performed.

1. Express Migration Tool

You can use Sitecore's Express Migration Tool to move over data from your old instance to your new one. It supports migrating from previous old versions to Sitecore 9 initial version. Express Migration Tool copies items and files from one Sitecore instance at a time.

The Sitecore Express Migration Tool copies items and files from one Sitecore instance at a time. The tool supports the migration of remote servers.

2. The update Center

Update Centre was introduced in Sitecore 9.0 Update 2 and is valid up to Sitecore 10.1.

You can find, download, install, and manage updates and hotfixes for the Sitecore platform and Sitecore modules. The Update Center accesses a package management service provided by Sitecore, or you can install and provide a service yourself.

The Sitecore Update Center uses this URL of the Package Management Service to check for the Sitecore updates:

<add name="PackageManagementServiceUrl" connectionString="https://updatecenter.cloud.sitecore.net/" />

Upgrade tactics

Next, let’s talk through some upgrade tactics that can significantly help your upgrade process.

1. Affixing the states and being able to switch between them as quickly as possible is crucial for productivity when working on instance upgrades. Small mistakes are inevitable and we actually need some sort of Undo button for the whole process.

We already have this for the codebase – git, with its ability to switсh between the branches.

But what about the published sites, indexes, certificates, and the rest of the minors that matter? Even database backups are not that fast and straightforward.

The one and only solution that comes into mind is fixing the whole state of a working machine. Something that one could have with a Virtual machine. Luckily, we have at least one suitable technology:

2. Hyper-V

aspnet_Membership
aspnet_Profile
aspnet_Roles
aspnet_Users
aspnet_UsersInRoles
RolesInRoles

<add namespace="Sitecore.Mvc"/>
<add namespace="Sitecore.Mvc.Presentation"/> 

<!-- instead of of GlassView -->
@inherits GlassView<ModelClass>

<!-- it becomes -->
@model ModelClass

public class FeatureController : Controller
{
    private readonly IMvcContext _mvcContext;
    public FeatureController()
    {
        _mvcContext = new MvcContext();
    }
    var parameters = _mvcContext.GetRenderingParameters();
    var dataFromItem = _mvcContext.GetDataSourceItem();
}

[SitecoreChildren(InferType = true)]
public virtual IEnumerable<Model> InnerChildren { get; set; }

gci -r -include "*.cs" | foreach-object {$a = $_.fullname; (Get-Content -Raw $a -Encoding UTF8) | `
foreach-object {$_ -replace 'args\.Context\.','args.HttpContext.' } | `
set-content -NoNewLine $a -Encoding UTF8}

<CustomPipeline>
    <processor type="ProcessorType, Library.DLL" 
        patch:instead="processor[@type='Sitecore.Mvc.Pipelines.Response.RenderRendering.GenerateCacheKey, Sitecore.Mvc']" 
        resolve="true" />
</CustomPipeline>

var options = LinkManager.GetDefaultUrlBuilderOptions();
var url = LinkManager.GetItemUrl(item, options);

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <linkManager defaultProvider="sitecore">
      <providers>
        <add name="sitecore">
          <patch:attribute name="languageEmbedding">never</patch:attribute>
          <patch:attribute name="lowercaseUrls">true</patch:attribute>
      </add>
      </providers>
    </linkManager>
  </sitecore>
</configuration>

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <links>
      <urlBuilder>
        <languageEmbedding>never</languageEmbedding>
        <lowercaseUrls>true</lowercaseUrls>
      </urlBuilder>
    </links>
  </sitecore>
</configuration>

<events>
  <event name="publish:end">
    <handler type="Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel" method="ClearCache">
      <sites hint="list">
        <site hint="apple">apple</site>
      </sites>
    </handler>
  </event>
  <event name="publish:end:remote">
    <handler type="Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel" method="ClearCache">
      <sites hint="list">
        <site hint="apple">apple</site>
      </sites>
    </handler>
  </event>
</events>

<site name="apple" cacheHtml="true" preventHtmlCacheClear="true" … />

<configuration>
  <indexes>
    <index id="sitecore_testing_index">
      <param desc="core">$(id)</param>
    </index>
  </indexes>
</configuration>

<defaultSolrIndexConfiguration>
  <documentOptions type="Sitecore.ContentSearch.SolrProvider.SolrDocumentBuilderOptions, Sitecore.ContentSearch.SolrProvider">
    <indexAllFields>true</indexAllFields>
  </documentOptions>
</defaultSolrIndexConfiguration>

To start with, I am happy to complete learning and successfully pass both Content Hub Administrator and Developer Certification exams. In this post, I will try to share some thoughts and insights on how you could also progress with those two.

Everything started for me from this twit from the official Sitecore account:

With more and more large clients choosing Content Hub, I thought that would be a great time investment learning how to deal with it. To start with, one could start with the Content Hub sandbox which is intentionally done for acknowledgment and playing it over.

Documentation is free and available here: Sitecore Content Hub's Functional documentation.

There is an official learning collection for Content Hub 4 which comes as a 12-month on-demand digital learning subscription, however costly ($2k, unless you're a partner). Instead, I referred to the one for version 3 which became free at some point as well as lots of third-party resources and blogs. 

Since Content Hub is a SaaS solution, one cannot install that in order to familiarize with it. Instead, you may need to spin up your own Sandbox Environment in order to practice. You may read what are the options by this link (also Sitecore MVPs get $50 off the bill).

If you're lucky to me Sitecore MVP (as I am), you'll get a generous discount of 75% off the price. Yes, you pay only a quarter:

You will have to answer 50 and 60 59 questions for the Administrator and Developer exam, correspondingly with a pass rate of 80%. This is a "closed book" proctored exam, which means during the course of the whole exam one cannot refer to any of the materials, notes, browser tabs, etc. A built-in laptop internal camera would be enough, but the proctor will be monitoring you all the time. They are ofter alerted when test-takers move their sight outside of the monitor and can put an exam on pause asking to turn the camera and show the whole environment to ensure no cheating takes place. Another cautious wearable is glasses (especially tinted) - those could be smart glasses and the proctor must ensure they aren't.

The Sitecore Content Hub Administrator Certification Study Guide talks about the competencies and the expectation on each area for the exam. If you follow this guide and cover all the areas mentioned you should be able to pass the exam.

• Schema Design
• UI Configuration: Search Component and Mass Edit
• Branding and Theme, Custom Home Pages
• Media Processing
• Digital Rights Management
• Data Import and Export
• Security: Basic and Advanced
• Reporting
• Enterprise Domain Model: Schema and Metadata Management
• UI and Advanced Pages
• Entity Printing
• Create and Configure a New Workflow

In addition to the above, there are Developer competencies added at Sitecore Content Hub Developer Certification Study Guide:

• Metadata Processing Scripts
• Develop External Page Components
• Develop Web-enabled Action Scripts
• Develop Triggers, Actions, and Action Scripts to Implement Custom Business Logic in Response to Entity Changes
• Implement User Sign-in Scripts 
• Develop LINQ Queries in Combination with Action Scripts that Run In-Process and Out-of-Process

Outside of official guidance, there are lots of third party helpful resources:

• High-level overview walkthrough (by Rick Bauer)
• Asset Management Admin Overview and Metadata Setup (by Rick Bauer)
• Content Hub Handbook (v2.2 is available as of now)
• Image processing use case - Focal Point Cropping (by Rob Habraken)

Finally, last but not the least, I'll share my own ideas and some interesting facts.

Firstly, both exams share the vast proportion of the same competencies up to 70% and at some moment it looks like the Administrator test is a subset of Developers one. Personally, I have met a certain amount of the same questions as a part of both exams. That means if you want to cover them both, it would be highly beneficial to start with the Administrator exam and once complete switch to Developers. But you don't have to - just choose the one that suits you best.

Next, the topics and competencies. Learn and understand the schema! The questions about it were widespread along with both tests. Without a bright and clear understanding of it, it becomes impossible passing these exams. 

You must also know:

• how to define relation types and cardinality for the desired use case
• work with metadata and add new metadata properties
• option lists and how to use them with M.Asset
• taxonomies and all about them
• Search relevance and boosting
• full-text search and to configure new metadata for it
• how to set up security for the properties
• rules and conditional display fields to display, and understand scopes (ie. for Apply All vs Apply Any)
• exporting and importing (from Excel)
• what are DRM contracts and right profiles, how to apply those to assets
• anything related to workflows: state flow manager, etc.
• how to work with media: converting, streaming, or download, how to work with renditions
• how to implement custom logic triggered by entity changes
• context and getting data out of it 
• the difference between action scripts that run in-process and out of the process
• how to implement authentication-related code (ie. checking the way user got authenticated, local or external)

Hope this helps and wish you all best, for both passing exams and working with this powerful SaaS solution!

Supports Sitecore 10.2. Supports Windows 11
SUPPORTS 10.2 ON Windows 11

It took me a month longer to conduct all the required testings for software and plugins supplied by me (in fact I was also stuck in Africa on the festive break), but finally, the new version of Sifon is available!

You can download it from Sifon.UK website, but the easier option would be using Chocolatey package manager:

cinst sifon

For the moment it is the only software that can install Sitecore on Windows 11. Let's take a look at Release Notes for this version:

• supports Sitecore 10.2, supports Windows 11. Supports Sitecore 10.2 ON Windows 11!
• comprehensive testing has been done - many bugs fixed or refactored
• plugins were updated, consolidated with main functionality and each other
• it is now possible to mark a plugin with ### Requires Profile: false to make it run even without an active profile
• few features were temporarily suspended until got improved
• lots of new plugins including installers for the latest Horizon, SXA, Publishing Service 6.0 etc
• added support for Solr 8.8.2 and fixed a minor bug in Solr (un)installation script, making it genuinely universal
• added syntax to present (double)clickable URLs right in the output to help users with supporting info
• added Get-SitecoreVersion function that returns either object or string with current XP or XM release version
• added Verify-NetCoreHosting function to ensure minimum required .NET Core version (passed as param) presents on a target system
• since all the SQL Server activity goes through SqlServer PowerShell module (opposed to SQLPS) - it is now added to Sifon prerequisites
• and much more minor issues got tested and fixed

I also recorded a video showing how easy one could install Sitecore without having anything installed at the target machine (except SQL server which could of course be accessible over the network):

Hope you find it useful!

This advice was originally proposed by Peter Nazarov (Twitter, LinkedIn), who kindly asked me to give it a bigger spread.

The biggest question for the day is if the fix was already applied to all official Sitecore container images so that now we can just pull new Sitecore containers and rebuild to rebuild our own container images to apply the patch?

The KB article offers WDP and ZIP packages fixes but says noting about containers, just like containers are not supported by Sitecore:

Critical vulnerability applicable to all Sitecore versions related to XSS. 

This issue is related to a Cross Site Scripting (XSS) vulnerability which might allow authenticated Sitecore users to execute custom JS code within Sitecore Experience Platform (XP) and Sitecore Managed Cloud.

We encourage Sitecore customers and partners to familiarize themselves with the information below and apply the Solution to all affected Sitecore instances. We also recommend that customers maintain their environments in security-supported versions and apply all available security fixes without delay.

So below are some findings:

• There is no fix in the current Docker containers images - checked it for Sitecore XM 10.2.0
• Sitecore provides the patch XM and XP 10.2.0 by this link.
• It contains Sitecore XP 10.2 / Sitecore 10.2.1 rev. 007064 PRE / Documentation folder where you can find the Sitecore.Platform.Releasenotes 10.2.1 rev. 007064 PRE.md file which has no instructions at all and Released-images-sxp-pre-10.2.1-007064-21122021-115253.json file which contains Docker "assets" images that contain patch files which you need to copy manually using your own dockerfiles.

So to apply the fix for your Docker images you need to copy the patch files from the following Sitecore Docker assets images:

• for XM1: scr.sitecore.com/sxp-pre/sitecore-xm1-assets:10.2.1.007064.169-10.0.17763.2366-1809
• for XP0: scr.sitecore.com/sxp-pre/sitecore-xp0-assets:10.2.1.007064.169-10.0.17763.2366-1809
• for XP1: scr.sitecore.com/sxp-pre/sitecore-xp1-assets:10.2.1.007064.169-10.0.17763.2366-1809

For example, if using XM1: scr.sitecore.com/sxp-pre/sitecore-xm1-assets:10.2.1.007064.169-10.0.17763.2366-1809 for XM 10.2.0.

Inside this Sitecore Docker assets image you find C:\platform\ directory which contains the directories for the corresponding Docker images that you need to patch:

• \platform\cd
• \platform\cm
• \platform\id (it is empty and can be ignored)

...
FROM scr.sitecore.com/sxp-pre/sitecore-xm1-assets:10.2.1.007064.169-10.0.17763.2366-1809 as kb1001489
...

FROM ${BASE_IMAGE}
...
WORKDIR C:\
COPY --from=kb1001489 /platform/cm/ ./

...
COPY --from=kb1001489 /platform/cd/ ./

Note: this patch changes the version of your Sitecore 10.2.0 instance to 10.2.1: Sitecore.NET 10.2.1 (rev. 007064 PRE) (see the screenshot below). Seeing this happening it feels that, sadly, Sitecore is unlikely to release 10.2.0 Docker that includes this patch - it would cause versioning issues:

The example above is good to learn how you apply a patch with Docker assets image-based patch to your containers.

However, this Cumulative fix for Sitecore XP 10.2 patch changes a lot of DLLs to the new version which are not exposed via NuGet feed, and changes your Sitecore version to a pre-release version (which does not exist). This would give you several challenges. Therefore, I would prefer in this specific case to apply just a standard .zip file-based fix as per Notes section on the page:

For Sitecore XP 10.1 and later, if it is not possible to apply the cumulative fix (pre-release update), the following patch can be applied alternatively: Sitecore.Support.500712.zip.

• Changes multiple DLL versions (they are not available in NuGet feed)
• Changes Sitecore version to a pre-release version (next version that is not released yet)

Sitecore.Support.500712.zip

• Deploys new Sitecore.Support.500712.dll
• Overwrites vulnerable \sitecore\shell\Applications\Content Manager\Execute.aspx page file so that it runs from Sitecore.Support.500712.dll which contains the fix.

Every year I create a special Christmas postcard to congratulate my readers on a new oncoming year, full of changes and opportunities. Wish you all the best in 2022!

The problem

When installing Sitecore XP 10.2 for IIS 10.0.2*** like the one supplied for Windows 11, you will likely hit an error of Marketing Automation service unable to start. The SIF error starts with:

Install-SitecoreConfiguration : Failed to start service 'Sitecore Marketing Automation Engine'

That occurs due to a failure caused by TLS 1.3 so that the service fails to communicate with XConnect.

The solution

Just download and run this script prior to executing XP0-SingleDeveloper.ps1 main installation script. It will disable TLS 1.3 over TCP for the local IIS (beware as it may affect other non-Sitecore sites).

Alternatively, here's the code:

New-Item `
   'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' `
   -Force | Out-Null
    
New-ItemProperty `
   -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' `
   -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null
    
New-ItemProperty `
   -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' `
   -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null

Hope that helps!