DEV Community: Rob Earlam

I upgraded the SUGCON sites to Content SDK v2 in under 1hr

Rob Earlam — Thu, 02 Apr 2026 00:00:00 +0000

Just a quick blog post about a win I just had. I blogged last month about the process of upgrading the SUGCON sites from JSS to the Content SDK, and how the sites had been a bit neglected and were running a super old version. I finished the post by promising not to let that happen, and how we were going to ensure we kept up to date with future releases of the Content SDK. Well shortly after v2 of the SDK was released, so I knew I had to get onboard and update the sites to the latest version.

I decided to see how far AI could get me in the process... and it turns out it basically did it all for me first time. All in all the upgrade took me less than an to go from nothing to an open PR ready for my colleagues to review.

I did this by leveraging Copilot CLI and the Adversarial Testing feature that it supports. All I did was to create a new branch on my machine, open the root of the repo using the Copilot CLI and give it the following prompt.

Please upgrade the SUGCON Site located in this repo to Content SDK v2. You can find the upgrade guide here: https://doc.sitecore.com/sai/en/developers/content-sdk/20/upgrade-content-sdk-1-5-1-next-js-apps-to-version-2-0.html.

Do not make any changes to git, I will do that once I'm happy with the work at the end.

Once you can finished, please run an adversarial test of the changes using both Opus 4.6 and GPT 5.4

This went away thinking and making changes for a while and came back with the following response.

 Upgrade Complete — Sugcon2024 → Content SDK v2

  All files changed

  ┌──────────────────────────────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ File │ What changed │
  ├──────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ package.json │ Removed @sitecore-cloudsdk/*; added analytics-core, events, personalize at ^2.0.0; bumped SDK + CLI to ^2.0.0; next → ^16.1.1; @types/node → ^24.10.4 │
  ├──────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ src/Bootstrap.tsx │ CloudSDK().addEvents().initialize() → initContentSdk({config, plugins}) with analyticsPlugin + eventsPlugin │
  ├──────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ src/middleware.ts │ Deleted │
  ├──────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ src/proxy.ts │ Created — Next.js 16 proxy format; *Middleware → *Proxy class names; defineProxy; default export │
  ├──────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ src/components/content-sdk/CdpPageView.tsx │ pageView import: @sitecore-cloudsdk/events/browser → @sitecore-content-sdk/events │
  ├──────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ src/byoc/index.tsx │ Events namespace import: @sitecore-cloudsdk/events/browser → @sitecore-content-sdk/events │
  ├──────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ sitecore.config.ts.example │ SITECORE_EDGE_URL → NEXT_PUBLIC_SITECORE_EDGE_PLATFORM_HOSTNAME; PERSONALIZE_MIDDLEWARE_* → PERSONALIZE_PROXY_* │
  ├──────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ .env.remote.example │ Added NEXT_PUBLIC_SITECORE_EDGE_PLATFORM_HOSTNAME, SITECORE_EXPERIENCE_EDGE_HOSTNAME, SITECORE_RENDERINGHOST_NAME; renamed PERSONALIZE_MIDDLEWARE_* → PERSONALIZE_PROXY_* │
  └──────────────────────────────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

  Bugs caught by adversarial review

   - Opus
    4.6 caught: BotTrackingProxy imported from the dev branch template but not yet in published v2.0.1 — removed
   - GPT
    5.4 confirmed the above, and also caught: PERSONALIZE_MIDDLEWARE_* env var names in .env.remote.example were misaligned with the updated PERSONALIZE_PROXY_* names in sitecore.config.ts.example — fixed

Now this was the first time I'd upgraded a site to v2 of the Content SDK, so I followed the upgrade guide myself afterwards to double check the changes it had made to ensure nothing had been missed. Turns out, it nailed it first time!

The thing I really liked about this was the text output at the bottom above, covering the result of the Adversarial Testing I asked it to complete. It used both Opus 4.5 and also GPT 5.4 to validate the changes it had made, and each model found different issues that needed to be fixed. This is a a super powerful trick as it means you can play models off against each other leveraging the benefits of both to get you where you need to go faster, how cool is that!

An Introduction to Harness Engineering

Rob Earlam — Wed, 01 Apr 2026 00:00:00 +0000

So for a decent amount of time now I've been on the Vibe Coding bandwagon, like a large portion of the development community. When it works it really can seem like magic. Too often though it does seem to go off on a tangent, editing unrelated parts of the codebase, or implementing a something in a way that I just wasn't happy with. I felt that it was making me more productive, but I also felt like I spent a good amount of my time chasing the LLM, going back and forth on the same problem and repeatedly prodding it to get to the outcome that I wanted.

It felt like one of the big problems with this approach was repeatability, now rules files can help here to try and enforce some guidelines for how LLM's interact in certain scenarios, but I was getting sick of constantly having to type prompts like "You are a senior developer with 10yrs of experience yadda yadda". I had played around with some Agents, and they were a step in the right direction, but the whole thing was still feeling very manual, in that I had to hand-hold the AI at each step.

Then last month I read a blog post published by Ryan Lopopolo from the OpenAI Tech Team about Harness Engineering and this got me interested. I had heard of people creating teams of Agents, so I decided it was time to jump in. I ended up rebuilding the site you're reading this blog on now using this approach and I wanted to document how I ended up putting it together for anyone else looking to build software this way.

Harness Engineering 101

As I said in my previous blog post the name is pretty apt. The basic concept is that you think of AI like a horse, it's fast and it's powerful, but for the vast amount of people, if you try an ride it bareback then you're going to have a bad time. That's why you need to develop a Harness for the horse, allowing you to make use of the power and speed it provides while being much more in control of where the final destination is.

The harness also means you can repeatedly ride the horse to different destinations, but with the same ease. Now from time to time you might have to tighten the harness when you realise there's something you're not happy with. You might also make some slight adjustments depending on the journey your taking or the destination. Overall though, the harness remains pretty much the same for each trip. The same is true for Harness Engineering as well. In this case the harness is a series of agents , roles , artifacts , and workflow standards that let you guide execution instead of hoping for a good result.

The workflow standards define how everything should function. In my case this covers everything from Next.JS best practices, and testing standards, through to how the agents communicate with each other, and how the current state of the repo is tracked during execution.

The agents are autonomous workers, each with a very specific purpose to execute within the system. I keep the actual definition here very light, instead storing most of the definition in the roles. I have the following agents defined currently though:

Orchestrator — Controls the workflow end to end, decides which stage should run next, invokes subagents, validates handoffs, keeps execution moving in the right order, and bails out if one of the subagents fails.
PO-Spec — Turns the original idea or request into a clear feature specification with scope, intent, and acceptance criteria.
Feature Design — Translates the feature requirements into a design direction, interaction model, and structural approach for the features being built.
Tech Lead — Converts the spec and design into an implementation plan with technical decisions, architecture guidance, and delivery steps.
Build — Actually does the coding work - it carries out the implementation work by creating or updating the code and assets needed to deliver the feature.
QA — Reviews the output against the specification and expected behaviour, identifies gaps or defects, and decides whether the work is ready or needs to return to Build.

The artifacts are what is delivered by each if of the agents above, so for the PO-Spec agent, the artifact is the actual spec that it is created. For the Build agent however the artifact would be the code changes themselves.

The roles are where the vast majority of the agent logic is maintained and there is a 1-1 relationship from agents to roles meaning all of the agents listed above have a corresponding role definition. These each define things like the responsibilities of the agent, what pre-requisites need to exist before it can run, what areas of the codebase it can look at to perform it's actions, whether it can iterate on itself, which it can says its completed, and a detailed walkthrough of the process it should follow. One of the main benefits with keeping the definitions in role files with skinny agent files that reference them is that it helps to keep my harness IDE agnostic - I can have skinny definitions for agents in Claude, Cursor or VS-Code, but the logic is in the shared role file avoiding repetition.

Advantages of Harness Engineering

So you might be reading through the items above and wondering why someone would go to the effort of configuring all of this, when you could just start directly talking with your LLM and creating the code for the feature you require. There's a few really nice things you get by following this approach that I want to cover.

The shift from prompting to orchestration

One of the main ones for me is the change from having to repeatedly craft prompts to defining a lot of this in advance in the harness. This allows the LLM to take the actual work request and break it down into discrete tasks, and hand them off to tightly bound agents with specific roles and outputs. It means that each agent has a narrow purpose, clear responsibilities, and explicit limits. Defining all of this up front reduces role leakage, keeps outputs focused, and makes the system easier to reason about and improve. If you find the Tech Lead Agent isn't creating a proper plan from the specs for the build agent, then it becomes very easy to tweak that agents role to get the result you want.

Artifacts, tasks & the backlog

How I run the delivery process using the harness is that I have a backlog of desired features with a very basic high level description. When I want to implement one I have a conversation with an LLM to generate a much more detailed Task Definition with a unique id, which would describe in more detail the feature I want and any guidance for how I think it should and shouldn't work. This task is then passed through all of the agents to generate their artifacts. The nice thing here is that every artifact generated is created keyed with the task id, and stored in the artifacts folder.

This means that if I want to look back in the future at how the blog feature was implemented, I can refer back to all of the artifacts that were generated by each of the agents to see why it was implemented the way it was. This can also be used as memory for future feature implementations, you can including instructions like "following the same pagination pattern implemented in the blog features" and the LLM will know how to do that and where to look for the information.

Repetition, Repetition, Repetition

I keep mentioning the benefit of repetition with the project for future features, but this concept of repetition is actual broader than that. If I want to start a different project tomorrow on a different technology stack, then my existing harness can still help. Lets say I want to build an IOS application tomorrow, now coding standards will obviously need a large rewrite, but the concepts I described above about agents , roles , artifacts , and workflow standards will be largely transferable. I would move them over to the new project and tweak them to get the output tailored to that project. Coming back to the horse analogy, I'm once more tailoring the harness I'm going to be riding with to better suit the journey I'm on and the destination I want to get to.

Conclusion

As I built out this harness, I released I was actually recreating a structure that I had seen and worked in at many different companies before when working on software projects. You have each role within the company responsible for producing the artifacts that the next team would use. Now the difference is that all of this is created by AI, and in a fraction of the time!

Hopefully this has been a good introduction to some of the key elements to Harness Engineering and how it all comes together. As I continue this series I want to deep dive in to each of the topics I've covered above. I want to talk about how you can craft a tightly defined agent and role, how you can enforce contractual boundaries to minimise agentic scope creep, and ensure the orchestrator can validate completion before continuing the execution pipeline. There's going to be lots to cover, so keep an eye out for future articles on this topic coming soon!

New Site, Who Dis?

Rob Earlam — Mon, 30 Mar 2026 00:00:00 +0000

For anyone who's read my blog posts before, you wont have seen much (if any) content on here about horses, but turns out there's a first for everything. Bear with me though as it looks like I saved my "horse content" for just the right time.

Like the majority of the rest of the development community, I've spent the past couple of years both amazed and a little bit terrified about how AI powered development has taken over the industry. I've always been a developer who's excited about learning new things though, and this was a big one I could sink my teeth into.

Every few years a new technology comes along that I want to learn, and in those cases I have generally rebuilt my personal site that you're on now as a way to put the technology into play. I knew that I wanted to follow the same process for AI based development, but with the rapid pace of advancement in the technology, I was never really sure about when to attack this, until last month when I read a blog post published by Ryan Lopopolo from the OpenAI Tech Team about Harness Engineering and I knew now was the time to bite the bullet.

I'm planning to write much more on this subject as it has been a decent learning curve for me, but it's been some of the most fun I've have writting code (or not writing it as the case maybe), in a very long time!

The basic concept is that you think of AI like a horse, it's fast and it's powerful, but for the vast amount of people, if you try an ride it bareback then you're going to have a bad time. Thats why you need to develop a Harness for the horse, allowing you to make use of the power and speed it provides while being much more in control of where the final destination is.

In reality the what you end up building is a team of agents, each with a tightly bound function. They can't stray outside of their designated function, and there is an orchestrator agent who is repsonsible for invoking each of them. The orchestrator is repsonsible for invoking them in the correct order, and also ensuring that they complete succesfully before invoking the next one.

All of this comes together through a series of markdown files that are used to define how this system comes together. This covers everthing from how the agents themselves function, the different actions they can perform, the files in the repo they have access to in order to perform their job, and how communication and state management is handled throughout all of this.

I'm planning to write all of this up in the coming weeks, as it's been an amazingly enjoyable learning journey for me to pull it all together and I'm hoping this series will help others looking to build software in the same way. It took a few attempts to get the Harness into a state where I was happy with it, and it is now churning out features for this Next.js site with ease. I do think that when I complete this the next time the process will be much faster with everything I've learned.

So my aim is write content covering how I built my setup, what actions worked well, and crucially what didn't. We're going to go over the different agents and their roles, artifact generation, human-in-the-loop review process, execution boundaries, the process I went through pulling all of this together and crucially where I want to take it next.

So I hope you come back for the next post when we start to dig into this exciting topic for real!

Sitecore Search - Debugging Crawling Errors

Rob Earlam — Tue, 27 Feb 2024 21:45:06 +0000

The latest video in my series on #Sitecore #Search was published this week, discussing how you can debug crawling errors.

Sitecore Search SDK - Breaking Change

Rob Earlam — Fri, 02 Feb 2024 00:00:00 +0000

Updating packages in Sitecore’s Developer Portal

Recently my colleague Mark van Aalst was updating the package versions for the Sitecore Developer Portal. This also included updating the version of the Sitecore Search React SDK from v2.0.0 to v2.2.2, among other packages that were updated at the same time. Once this had been deployed, we got reports that faceting was no longer working on the search results page. We quickly rolled back and started to look into what had happened.

Breaking changes in the Faceting UI component

I reached out to the team that owns the SDK and apparently there was a breaking change introduced in a previous version and we needed to update how we were leveraging the UI components being used to render the Search Results page.

Previously we were wrapping out Facets in the AccordionFacets.Root component, like so

<AccordionFacets.Root defaultFacetTypesExpandedList={facets.map((x) => x.name)} onFacetValueClick={onFacetClick}>
    ….
</AccordionFacets.Root>

However, this approach is no longer valid, we should now be using SearchResultsAccordionFacets component instead. As follows:

<SearchResultsAccordionFacets defaultFacetTypesExpandedList={facets.map((x) => x.name)} onFacetValueClick={onFacetClick}>
    …
</SearchResultsAccordionFacets>

This was a fairly straightforward change, which meant we could bump the Developer Portal up to be running on the latest version of the Search SDK 🎉.

To see the complete set of changes we had to make for the Developer Portal, you can view the PR that was opened for this fix here.

SUGCON India 2023 goes off with a bang 💥

Rob Earlam — Thu, 31 Aug 2023 00:00:00 +0000

Last week I had the pleasure of attending SUGCON India 2023 in Delhi, India. This was the first time we’d run a SUGCON in India since 2019 and it was great to be back once more, interacting with the local Sitecore community. There was a lot of effort in involved in pulling the event off, and I do want to start by thanking all of the organisers for the time they invested in making this event the success that it was.

I was privileged to be chosen to deliver one of the keynote sessions this year, where I talked about a recent project I worked on where we integrated Sitecore Search into our Developer Portal. This was very well received and led to many questions afterwards, and many further conversations throughout the event. It was great to see the amount of interest there is in Sitecore Search from the attendees!

The quality of the sessions that were delivered at the event was of a very high standard. They ranged from high-level sessions covering Composable DXP’s in general and the power they can bring to customers, all the way down to technical deep dives on specific features and use-cases. Some of my highlights were:

The session by Pieter Brinkman titled Digital Experience is a team sport, where he talked about the different roles that play a part in successful Composable DXP implementation – it’s not just all about the developer!
George Smith & Sheetal Jain delivered an awesome session called Beyond Buzzwords: Composable Tech and Generative AI for Real. Here they showed how OrderCloud, Sitecore Content Hub & Dall-E can be combined to allow customers to generate art on the fly and have it printed on a t-shirt for sale in an online store, cool stuff!
Exploring the Experience Edge GraphQL Schema was a really interesting session delivered by Alistair Deneys. Here he gave a true deep-dive into the schema implemented for Edge and how you can leverage it in some really interesting ways. There’s also a cool surprise at the end of the session that I won’t give away here, but be sure to check it out if you get the chance.
Women in contemplating Darwin's Theory - To Break the Conventional Wheel was a great session by Varalakshmi M D & Raveena Mathur where they talked about the important role women have in ensuring successful outcomes for customers.
Andy Cohen delivered a great session titled Build for XM Cloud according to the Architect of XM Cloud. Here he talked about the best practices for building with XM Cloud... he might have ruffled some feathers with some of the recommendations, but it was great to see it all layed out!

The closing keynote was also a highly enjoyable part of the event. Each of the representatives from Sitecore (Pieter, Nicole, Andy, Alistair and myself) held a panel discussion and open Q&A session. This gave the attendees the chance to ask any lingering questions that they hadn’t had the chance to ask already. The topics were very wide from specific feature questions on the products through to general questions about the best way that Sitecore can support the local Indian community… and of course the age-old question of Sandboxes and how people can get access to Sitecore’s newer SaaS products – we hear you and are working on a solution!

As much as I enjoyed everything I mentioned above, as with every event I seem to attend nowadays, the true highlight was getting to interact with the local community we have on the ground. It’s amazing to see the passion they have for Sitecore and our products. It was great to see so many familiar faces from the events back in 2018 & 2019, but it was also great to see so many new faces as well, a good balance that shows how healthy the Sitecore community in India is.

I just want to finish off by saying that of course trips like this aren’t always about work though, we always try to make sure that we get out and see some of the places we visit and India is no different. On this trip, we made the journey down to see the Taj Mahal after the event had finished, and it truly is an amazing site to see. Really all of the descriptions of it you hear just cannot do it justice, and it was great to experience it with the awesome team we had on-site.

So, whether it’s the always friendly people, the amazing effort from the organisers & speakers, the food, the noise or the general sights you see around the city – India is one of my favourite places to visit and certainly one of my favourite SUGCON events.

Here’s looking forward to doing it all again in 2024!

Migrating the XM Cloud Introduction Repo to a new Nuget feed.

Rob Earlam — Thu, 27 Jul 2023 00:00:00 +0000

Today I had to go through the process of migrating the XM Cloud Introduction repository to a new Nuget feed. This was required as the old feed was no longer available, and we needed to move to a new one on short notice. This post will cover the steps I needed to complete to migrate the solution to the new feed.

Machine Tidy Up

Now for anyone who hasn't run a Sitecore site before you can most likely skip this step. However, for anyone who has you should tidy up any references to the old feed that have been configured on your machine. In my case, this was the PowerShell Repository used to restore the SitecoreDockerTools module used by this, and other Sitecore repositories.

Remove PS Repository

The first thing to check is whether you have the old Sitecore Feed registered as a PowerShell Repository, you can do this by running the following command Get-PSRepository and checking where there is a record named SitecoreGallery. If you have one registered, then you can remove it by running Unregister-PSRepository -Name SitecoreGallery.

Remove PS Modules

Next, I tidied up any previous versions of the SitecoreDockerTools module installed from the old feed. You can test whether you have any versions of that module installed by running the Get-Module -ListAvailable and look for any named SitecoreDockerTools. If you have those installed, you can quickly remove all installed versions of that package by running Uninstall-Module -Name SitecoreDockerTools -AllVersions.

Update the Repository

So now we’ve tidied our developer machine, we can update the repository to reference the new feed. This involved making two changes, an update to the init.ps1 script used to initialise the repository, and then an update to the nuget.config to define the new location for the NuGet packages in use by the solution.

Updating the init.ps1 script

The first thing the script does is install the SitecoreDockerTools PowerShell module, so we need to update the location that it is installed from, in our case, we needed to use v2 of the Nuget feed to get it to work, so we needed to change it to https://nuget.sitecore.com/resources/v2/. After making this change the init script ran successfully and installed the module from the new feed.

Updating the nuget.config

The final change we need to make is to update the nuget.config file in the root of the repository that controls where custom NuGet packages are installed from. We had a couple of older references in there that we removed and condensed down to the single new feed reference. This resulted in us having the following line in our config:

<add key="Sitecore" value="https://nuget.sitecore.com/resources/v3/index.json" />

Conclusion

Updating the XM Cloud Introduction repository to the new feed location was straight forward in the end. I would recommend any developers who have been running existing Sitecore solutions before follow the tidy-up steps at the start to ensure they remove any legacy references they have to the old feed. You can see the changes we had to make in the following commit. There may be other changes that you will need to complete to bring your codebase in line, but hopefully, this will help to get you started with what tasks are required for you.

Sitecore Search - Filtering vs Faceting

Rob Earlam — Tue, 25 Jul 2023 23:28:45 +0000

The latest video in my series on #Sitecore #Search was published this week, discussing Filtering vs Faceting.

Sitecore Search – Configuring your Domain

Rob Earlam — Mon, 10 Jul 2023 00:51:26 +0000

The second video in my series on #Sitecore #Search was published last week, showing how you can do the initial domain configuration

Introducing the Sitecore Discover JavaScript SDK - Part 2 Components

Rob Earlam — Thu, 11 May 2023 00:00:00 +0000

Introducing the Sitecore Discover JavaScript SDK - Part 2 Components

This post is the second in a two-part blog series, introducing a brand-new JavaScript SDK for Sitecore Discover. You can read the first part here. In this second part, we'll dive into the component model provided by the SDK and show the different ways you can leverage Discover data in your React application. This blog is the accompaniment for the YouTube video highlighting the same features. You can watch the video below:

Adding Components to a Page

There are three different ways to add a component in to your React application:

Static components : Created in the CEC (Customer Engagement Console) and dropped into the page by a developer. This is developer-centric and means the developer specifies that a specific widget will always appear in a specific area in the DOM. The merchandiser can configure the widget afterwards, but they cannot change it out for a different one.
Dynamic widgets : The developer leverages a widget tag, similar to a placeholder in XM Cloud, allowing the merchandiser to dynamically insert widgets configured and created in the CEC. This means the developer can specify an area in the DOM, and the merchandiser can add and remove widgets from that area without the developer's involvement.
Global components : These are components that appear on every page, such as the search bar in a header. They remain the same across different pages and routes of your site.

Configuring Widgets in the CEC

Before adding any components to our application, they’ll need to be configured within the CEC. There are two different types of widgets when it comes to working with the SDK:

HTML widgets : The layout is owned by the CEC, and the SDK can render them without any additional configuration.
Catalog widgets : The layout and functionality are owned by your application. We need to tell the SDK which components in our app to use to render them by calling the setWidgetType function, you can find details on that function in our documentation site.

An rfk_id is also assigned to each of your widgets allowing you to refer to them specifically.

Where to find a Widget examples?

So, you might be asking where you find examples of the widgets you can create? Well you have a few supporting elements that can help you here.

We have the documentation site which will show you walkthroughs of how to complete common activities with the SDK.
We also have a StoryBook instance which will give you examples of the different components included in the SDK’s UI package.

Adding Static & Dynamic Widgets to Our Site

In the video, we begin by adding some widgets to our site. In the index.tsx page of our Next.js application, we will use the useEffect hook to tie our application's route to the specific page definition in the CEC. We will then use the usePageWidgets function to get the widget data for rendering. We can then begin to replace parts of our site with dynamic or static components, as shown in the examples below:

Dynamic Components : We can render a div with a loading message, and when the loading is finished, we map through the widgets returned by the usePageWidgets to render the appropriate widget component.

<div>
  {isLoading && <div>Loading...</div>}
  {!isLoading && widgets.map((w) => <Widget rfkId={w} key={w} />)}
</div>

Static Components : We can use a different component tied to a specific widget in the CEC using the widgetID to always render that widget at that location in the DOM.

<RecommendationGallery rfkId="rfkid_92" productsToDisplay={6} />

Implementing Global Widgets

In the video we replace the existing search bar in our Next.js Commerce site with a preview search from Discover, using the code samples provided in StoryBook. The samples there will give you a styled, working interactive React component ready to be inserted directly into your application.

Conclusion

Discover can be used as much or as little as desired in your implementations. You can use Discover for every piece of catalog data in your channels or just for individual pieces of catalog data sprinkled throughout your channels. The other fact I liked about the platform is that it is just as easy to implement Discover in an existing storefront as it is a new greenfield project.

Finally, when using the JavaScript SDK, be sure to take advantage of all the supporting features provided, such as Storybook, and the documentation site to help you build your app as quickly as possible.

Introducing the Sitecore Discover JavaScript SDK - Part 1 Events

Rob Earlam — Thu, 04 May 2023 00:00:00 +0000

Introducing the Sitecore Discover JavaScript SDK - Part 1 Events

In this two-part blog series, I'll be introducing you to a brand-new JavaScript SDK for Sitecore Discover. In this first part, we'll dive into the different implementation options for Sitecore Discover, explore the JavaScript SDK, and discuss its eventing model. This blog is the accompaniment for the YouTube video highlighting the same features. You can watch the video below:

Implementation Options

When working with Sitecore Discover there are three main integration options:

Hosted Pages: Low developer effort but limited feature set; best for simple implementations where a merchandiser can configure everything from the Sitecore Discover Customer Engagement Center (CEC). Requires a reverse proxy or subdomain to serve pages directly from Discover.
Direct API Integration: High developer effort but full feature set; best for more complex requirements where developers manually call APIs to create custom commerce experiences.
JavaScript SDK (our focus in this seres): Moderate developer effort with full feature set; best for React-based applications and designed for a faster development process with boilerplate code and API calls automated for you. The SDK comprises two main elements, the eventing elements from the React NPM package, and the component elements from the UI NPM package.

JavaScript SDK Overview

The JavaScript SDK for Sitecore Discover is a React library, making it suitable for React-based applications and frameworks like Next.js. Don't worry if you're using another JavaScript library or language, though – you can still choose from the other integration options mentioned earlier.

Some key features of the SDK:

Complete control over catalog experience design
Flexibility in distribution of responsibilities between developers and merchandisers
Eventing & Custom Component models

Eventing Model

To start with, we'll focus on the Eventing Model. Eventing is crucial for collecting valuable information about user interactions on your site, such as page views, product details, and cart actions. This data is then used by Sitecore Discover's AI to provide personalized product experiences for users.

Several events are pre-wired in the SDK, but others require manual wiring. The good news is that once you've integrated the SDK and wired up your events, Sitecore Discover automatically begins collecting data for use in its AI-powered recommendations.

In the second part of this series, we'll explore the Component Model, which allows you to connect your event data with personalized product experiences.

Wiring up Events for Sitecore Discover

To use the SDK, you'll need to wrap your application in a WidgetProvider, which serves as the main entry point. After doing so you can begin to connect the events, some of which are automatically wired up by the SDK, while others require manual configuration. Here's a breakdown of which events fall into each category:

Automatically Wired:

trackAppearEvent
trackSearchResultsClickEvent
trackSearchResultsFacetClickEvent
trackRecommendationClick
trackPreviewSearchClick
trackPageViewEvent

Manually Wired:

trackAddToCartEvent
trackOrderConfirmEvent
trackPDPViewEvent
trackStatusCartEvent
trackUserLoginEvent

For the manual events, you'll need to call the corresponding event function provided by the SDK and pass in any required event data (for example, the product SKU).

Customizing Event Tracking

Below you can see a couple of examples of how to wire up the manual events, we’re going to use the Product Details Page View and Add to cart events as examples…

Product Detail Page View

To wire up the Product Details Page View event you need to follow a couple of steps:

Import the useEffect() hook from React and the trackPDPView function from the Discover SDK.
Call the trackPDPView function with the product's SKU inside the useEffect hook. An example of this is

useEffect(() => {
    trackPDPViewEvent(product.id)
}, [product.id])

Add-to-cart Action

To wire up the Add to cart Action you need to follow a couple of steps:

Import the useRouter() hook from Next.js and the trackCartEvent function from the SDK.
Modify the function responsible for handling the add-to-cart action in your application by calling the trackCartEvent() function with the product's SKU, price, and quantity after the original add-to-cart code executes.

const { asPath } = useRouter()
const eventModel: ProductEventModel[] = [
    {
        sku: product.id,
        quantity: 1,
        price: product.price.value,
    },
]
trackAddToCartEvent(eventModel, asPath)

By wiring these events, you'll start collecting valuable user interaction data that Sitecore Discover can use to generate personalized product recommendations.

Conclusion

That brings us to the end of part one of this series. Be sure to check out part two where we'll look into the component model, and how you can use the event data we've collected to create contextual product interactions in your storefront. Thanks for reading!

Upgrading the XM Cloud Introduction repository to Docker Compose v2

Rob Earlam — Wed, 19 Apr 2023 00:00:00 +0000

In case you haven’t heard, Docker has slowly been pushing people to migrate the latest version of Docker Compose, which is v2. This has culminated in the end of life for v1, which means that the functionality will be removed from all Docker Desktop versions as of Jun 2023.

Our team at Sitecore is responsible for the XM Cloud Introduction project, which currently uses Docker Compose for its local developer experience, so we needed to update to the latest version to ensure we could continue to work in this way. This post will cover the steps we needed to complete to migrate the solution to v2.

Overall, the process was fairly simple, with most of the time being taken up by testing. In the end, it boiled down to a couple of tasks that I needed to complete:

Updating our YAML definitions.
Updated our PowerShell scripts.

I also used this as an opportunity to tidy up a few things with the docker-related files to clean up a few warnings that were being thrown after we move to v2.

I’ll talk through the different changes we needed to make below, but you can see the pull request that contained the changes that were required here.

Updating the YAML definitions

The first thing we needed to do was to remove the top-level version parameter from our main docker-compose.yml file as it is no longer required when running v2. After completing this we then needed to update how we were scaling some of our containers. We use containers to perform build actions, but they aren’t actually used at runtime, previously this was achieved by using a scale parameter like this:

service-name:
    scale: 0

This syntax is incorrect when running Docker Compose v2 through, and now you should use the deploy.replicas property instead, so this involved changing all instances of this to the following syntax:

service-name:
    deploy:
      replicas: 0

The final change we needed to make was to one of our EntryPoint values, the previous version used the following value for the EntryPoint of the CM container:

entrypoint: powershell -Command "& C:\tools\entrypoints\iis\Development.ps1"

When attempting to use that with v2 though, the container failed to start as the backslashes were being stripped out. The simple fix for this was to double escape those slashes, so the new version looks like this:

entrypoint: powershell -Command "& C:\\tools\\entrypoints\\iis\\Development.ps1"

Those were all of the changes I needed to make to our docker-compose yaml definitions, now there are other changes that have been implemented by this forced migration but they didn’t affect our solution. You can read about the full set of changes on the docker site

Updating the PowerShell scripts

Once we had our yml definitions updated the last thing we needed to complete to have compatibility was to update our PowerShell scripts used to run the solution locally. The only change here was to update how the docker compose commands were issued. We have a few different ways that our solution can be run, but they all executed the containers using a command similar to this:

docker-compose up -d

We had to change this slightly to remove the hyphen from the docker-compose command, forcing anyone running the repo to be executing it using the v2 format, so the above command became

docker compose up -d

Final tidy up

After changing to run the solution using v2 I noticed it was throwing some extra warnings about unpopulated environment variables. After looking into it, these variables were no longer actually used in our solution, so this proved to be a good time to tidy those up as well. The final task was to update the README for the repository to state that it was now using Docker Compose v2.

Conclusion

Overall, migrating to Docker Compose v2 was fairly straightforward for our solution and didn’t involve too many changes, though it may be more complex for you depending on which v1 features you’re leveraging.