In the previous post I talked about how to wire up Sitecore Pages to use your local Content SDK editing host. This post will describe how to switch it in your deployed XM Cloud environment.
If you created your XM Cloud project using the auto-generated repository, you got a clone of the XM Cloud starter kit. That project, currently, includes 2 head apps: Next.js and Angular. By default, when you deploy your project, the Next.js app is set up as the editing host. You’ve now brought in a Content SDK app and want to switch the editing host to that one. So, how do you do it?
Turns out, it’s actually pretty simple. In your project root, look for xmcloud.build.json. Open that file, and add this to the renderingHosts section:
The path should be the path to the folder containing the Content SDK app. You’ll also want to set enabled to true, and set it to false for the other rendering hosts (or just remove those other hosts from this file altogether).
Shout out to Dan Solovay for the assist on this one!
The Sitecore XM Cloud Content SDK was recently released, and it offers a trimmed down, focused kit to build websites with XM Cloud. However, this new SDK hasn’t been put into the default starter kit codebase that gets created when you start a new project. This post will show you how to get your local development environment up and running with the Content SDK, and how to connect it to the Pages editor.
Create your project in XM Cloud Deploy
This step is straightforward. Use XM Cloud deploy to create your project, environment, and codebase. This will create you a repository from the xmcloud-foundation-head repository that Sitecore provides. You can also use the code-first approach if you so choose, but for the sake of simplicity this post assumes you let Sitecore create your project.
When the initial deployment is created, go ahead and create your site in the Sitecore Cloud portal. Choose the blank site starter template.
Once that process completes, go to the Desktop (you can find the Desktop from the Settings screen in the portal) and package up your site. You’ll want this to install to your local environments soon. You should also consider adding a Page Content component to the page to see something other than a blank screen when you load the site.
These are the paths you’ll need to package:
/sitecore/templates/Project/<Your Site Collection>
/sitecore/templates/Branches/Project/<Your Site Collection>
/sitecore/system/Settings/Project/<Your Site Collection>
/sitecore/media library/Project/<Your Site Collection>
/sitecore/layout/Placeholder Settings/Project/<Your Site Collection>
/sitecore/layout/Renderings/Project/<Your Site Collection>
/sitecore/layout/Placeholder Settings/Project/<Your Site Collection>
Once your environment is up and running, install the package you just created to your local CM, located at: https://xmcloudcm.localhost/sitecore/
You’ll need to get some environment variables from your local rendering host. Some of these are created when you run init.ps1 to scaffold your containers environment. You can get these from the Docker container, or from the .env file in the /local-containers folder in your project root.
Copy the JSS_EDITING_SECRET and SITECORE_API_KEY values.
To connect to a local CM running in Docker, the steps are similar. Create a .env.local file in the root of your Content SDK project. Add the follwing environment variables:
NEXT_PUBLIC_SITECORE_SITE_NAME=<your Site name from the package> NEXT_PUBLIC_SITECORE_API_HOST=https://xmcloudcm.localhost NEXT_PUBLIC_SITECORE_API_KEY=<your API key copied from the Docker container> JSS_EDITING_SECRET=<your JSS Editing Secret copied from the Docker container> DISABLE_SSG_FETCH=true
Then, in the terminal, run: npm install npm run start:connected
Test your app in your browser at http://localhost:3000. If you did it correctly you should see a white page with the Page Content component you created and packaged previously.
Connect the Pages Editor to your local environment
Finally, we want to be able to edit our content and test our components in our local environment before we push and deploy anything. To do that, we need to set up Pages to use our local editing host.
Go to https://pages.sitecorecloud.io/ and log in, then select your site. By default, you’re editing in your XM Cloud environment. Click the Default Editing Host dropdown and change it to localhost:
Afterward, you will see an error like this:
There’s one more step. We need to tell Pages to use our local CM as well. Open your browser tools (F12) and in the Application tab, add this key to local storage: Sitecore.Pages.LocalXmCloudUrl : https://xmcloudcm.localhost
After you do this, you should see your content rendering with the Content SDK and be able to edit the page.
Content SDK in Docker
This post does not cover is getting the Content SDK host running in a docker container. That isn’t strictly necessary to work locally with the Content SDK. However, if you’d prefer to replace the JSS rendering host with the Content SDK one, that will be covered in a later post.
TLDR: Don’t put spaces in your field names for Sitecore headless builds.
Quick post about a bug I uncovered today working on an XM Cloud project with a .NET rendering host.
We’re seeing inconsistent behavior when mapping layout service field data to types in .NET. In short, fields with spaces in the name sometimes do not deserialize into .NET types when you attempt to do so with the SDK.
Consider a page with 2 fields: Topic and Content Type. In our code, we have a class that looks like this:
namespace MySite.Models.Foundation.Base
{
public class PageBase
{
[SitecoreComponentField(Name = "Content Type")]
public ItemLinkField<Enumeration>? ContentType { get; set; }
[SitecoreComponentField(Name = "Topic")]
public ContentListField<Enumeration>? Topic { get; set; }
}
}
When I create a component as a ModelBoundView, .AddModelBoundView<PageBase>("PageHeader") the fields map properly, and I get data in ContentType and Topic properties of my model.
When I try to map it from a service, like so:
namespace MySite.Services.SEO
{
public class MetadataService
{
private SitecoreLayoutResponse? _response;
public PageMetadata GetPageMetadata(SitecoreLayoutResponse? response)
{
_response = response;
PageBase pageBase= new PageBase ();
var sitecoreData = _response.Content.Sitecore;
sitecoreData.Route?.TryReadFields<PageBase>(out pageBase);
return pageMetadata;
}
}
}
I get no data in the Content Type field but I do in the Topic field. If I rename Content Type to ContentType, the field data is bound to the ContentType property as expected.
I dug into the code a little bit and it seems that the HandleReadFields method on the Sitecore.LayoutService.Client.Response.Model.FieldsReader is ignoring the property attributes: [SitecoreComponentField(Name = "Content Type")] Instead it is just using the property name, which of course has no spaces in it because it’s a C# identifier.
Until this bug is corrected, the workaround is to rename your fields to not have spaces in them.
