Monday, September 26, 2022
We've recently been working on a migration project, moving, and rebuilding a series of sites to run against Sitecore XM Cloud. One of the key requirements was to ensure that all the sites could be edited in both Sitecore Experience Editor, and the next-generation editing interface included with XM Cloud - Sitecore Pages. This blog post will cover the steps we took to get this working.
The project we’re working on is Open Source and you can follow our progress here: https://github.com/Sitecore/XM-Cloud-Introduction
xmcloud.build.json and the automated processes built into XM Cloud would have created and configured a RH instance for us. However, the site we were migrating over was the Sitecore MVP site which isn’t built with JS, it’s built using the Sitecore ASP.NET Rendering SDK, so we couldn’t use this automated process and had to configure both the Experience Editor and Pages to pull in a RH we hosted ourselves externally to XM Cloud.
We’re hosting the RH for the MVP site in a WebApp instance in Azure. So, the first task was to configure the RH run there. To do this we followed the same process we used to run the RH locally against Edge. If you look at the docker-compose.edge.yml in the repo you can see that we needed to set the following Environment Variables in the Azure portal for the WebApp we created
This gave us a running instance of the RH in Azure, but how did get Experience Editor and Pages to reference this instance? Well, the first thing was to enable the Experience Editor middleware for the RH. This is controlled by an app setting called
Sitecore__EnableExperienceEditor which is a Boolean that needs to be set to
true, that was only the first step in the process though…
Now the MVP site isn’t built with SXA so it doesn’t leverage the SXA Site Manager, instead, we use a manual site definition which you can see in our Project.MvpSite.config. If you look at the
When running locally the
serverSideRenderingEngineEndpointUrl parameter points to the internal container name for the RH and the
serverSideRenderingEngineApplicationUrl is the public URL. When running in XM Cloud with an externally hosted RH there is no internal name, so both params are set to the public URL for the rendering host. We do this by setting Environment Variables in XM Cloud for both values listed in the config above. This also means we can set different RH’s to be used for different Production and Non-Production XM Cloud environments which is nice:
We set those values, deployed our XM Cloud instance, and fired up the Experience Editor and were hit with the following error:
Connection to your rendering host failed with an Unauthorized error. Ensure the JSS Editing Secret is configured.
I went and checked the logs for the RH in the Log Stream in Azure and saw a matching error message there confirming the request was being denied:
The JSS_EDITING_SECRET environment variable is missing or invalid.
Now you can manually set the JSS Editing Secret for the XM Cloud using a configuration patch, but we hadn’t done that for our instance, so what was our JSS Editing Secret set to? I fired up the
ShowConfig.aspx administration page for our XM Cloud instance and looked for the setting named
I took this back over to the configuration settings in Azure and created a new setting. Our RH is configured to use the setting named
Sitecore__JssEditingSecret for its editing secret, so we created a setting with that name and value we pulled from XM Cloud and then everything fell into place.
Once all the settings were there, I headed back to XM Cloud and fired up the Experience Editor and everything loaded up correctly
But what about Sitecore Pages? I wanted to try the latest editing interface that has been released with XM Cloud as well. It turns out no other configuration was required to enable it as Sitecore Pages works from exactly the same settings as the Experience Editor, so when we loaded up Pages everything worked just as expected!