DEV Community: Kenneth McAndrew

SitecoreAI Scheduled Tasks - Getting PowerShell Working Right

Kenneth McAndrew — Tue, 06 Jan 2026 21:06:59 +0000

In SitecoreAI CMS (FKA XM Cloud), you have the ability to add PowerShell scripts, which is a great way to enhance functionality and run commands that you might have run in other ways in "legacy" Sitecore. You pretty much have the full run of the content and command structures, though you'll have to dig for it sometimes. A good reference can be found at the Sitecore PowerShell site.

This also allows you to set up PowerShell scripts that can be run as a scheduled task in Sitecore. For example, I have a script that scans recently update taxonomy values, and if anything changed, it finds the related items connected to it and publishes them, so the values are updated in Sitecore Search. But I found that after setting up my script and my task, the task would run but the script wouldn't fire.

I didn't see this in the documentation directly, but I did find the cause in an AI search about the topic. To get the task to fire the script, the script item has to be in a specific area of the tree structure, but then you'll find that the structure isn't fully in place. To set it up:

Go to the /sitecore/system/Modules/PowerShell/Script Library/SPE/Maintenance folder.
Create a folder called "Scheduled Tasks" - the name is the important thing here.
Place your script in this folder.
Set up your scheduled task with the PowerShell Scripted Task Schedule insert option and choose your script.

The key is the script location. My enhancement suggestion to Sitecore would be to add the "Scheduled Tasks" folder to their default IAR setup, but you can easily add it to your own. Again, it's the name that matters, not the item template, ID, or the like.

I hope this helps you out in getting your scheduled tasks going!

Off the Cuff Thoughts About Symposium Day 1 Morning

Kenneth McAndrew — Tue, 04 Nov 2025 17:41:47 +0000

So, this is just off the cuff as I sit eating lunch in my hotel room at the Disney Dolphin, where Sitecore Symposium is taking place today and tomorrow (I miss the Thursday half-day already, if only for a good reason to stay for the attendee party). This is my personal opinion on what I heard, and there's three major things.

Sitecore XM Cloud is now SitecoreAI...and so is the rest of it

So, the first of the two big announcements was that Sitecore XM Cloud was being bundled up with Content Hub, Search, CDP/Personalize, etc, as well as agentic AI, to become SitecoreAI. (Mind you don't put a space in there, Sitecore's official X post called it that...this will become like not capitalizing the C in Sitecore I think.) Apparently licensing will be all based around this all-in-one model, though I'm not sure what this means for entitlements, which were really confusing to navigate and overly restrictive I think. That I'll leave to the bean counters, but the first thought that struck me was a joke I made when Sitecore XM Cloud and that ecosystem was first announced, with the composable stack idea.

Given they had a product in each main space of the composable stack, I called it the composable monolith. Well, Sitecore even said during the presentations that they're going from composable to composed...so is the monolith back? If so, will there be better connections between products, or can we go back to event handlers over webhooks that had more stability and even a bit more versatility? (Seriously, a webhook for item:deleting...I tried that out, by the time it went to operate on the item being deleted, which you should be able to do, the item was already gone.)

Time with tell. I do see positives here as it keeps customers in the ecosystem and saves energy in shopping around. But the parts need to work together more smoothly, and the entitlements area needs to be smoothed over.

SitecoreAI Pathway was more intriguing to me

Maybe because it's the actual "newer" thing than a marketing deal with AI added in, but Pathway is intended to be a content migration helper from a variety of CMSes, and I imagine can be customized to connect to other ones as well not out of the box. Given how much of a pill content migration can potentially be, this is a product I'd like to find out more about. The confusing part for some was they announced "if you have Sitecore 360, you already have it now" - so is this a service you have access to, is this a professional service that Sitecore will do for you with X number of credits, or what's the scoop? I imagine more will come out in the near future.

Jesse Cole was the highlight by far

Jesse Cole, the founder of the Savannah Bananas and the whole "banana ball" concept, was excellent. Great energy and messaging. What's funny is, when he said "we're not in the baseball business, we're in the entertainment business," my first thought was Vince McMahon, who said that about WWE and pro wrestling. Jesse doesn't strike me as Vince-like though, thank goodness! I mean, he did have four people come on stage, blindfold themselves, do a dance-off, and the winner was the guy who started taking his shirt off...but it was funny because Jesse made the guy think he was competing still for 30 seconds after the last person was tapped out. And he gave away two pairs of underwear!

Okay, seriously, dude was funny. And yes he wore the yellow outfit, complete with hat. He needs a monkey mascot called Curious George to finish the ensemble, though. I think Sitecore streamed the morning session, though I'm not sure if this was on there...I think it definitely deserves to be seen by a wider audience. If not, then Jesse is more than welcome to come to my son's tae kwon do school and give them a talk!

Alright, almost time for the breakouts to start, so if you're reading this and you're at Symposium...you might be late to the first breakout! (It's 12:42pm as I post this.)

The Recycle Bin search in XM Cloud doesn't work. Try this instead!

Kenneth McAndrew — Mon, 22 Sep 2025 19:59:04 +0000

EDIT 9/24/2025: I had the wrong archival ID in my script, I've fixed that!

I had someone ask me to restore an item from the recycle bin in XM Cloud today. Generally not a difficult task, assuming it hasn't been 30 days since the deletion when it should get flushed. But, I've come to find that the recycle bin in XM Cloud, while it has a search, that search...doesn't work. You get a script error.

Now, in the collection of tools, the recycle bin seems to be a relic of the "old" era - it's in the Desktop of the Content Editor system, and I don't as yet see an equivalent in Explorer or Pages. But it's still a pretty useful tool. Fortunately, there's another way to do this...good old Sitecore PowerShell.

I remembered from something else I was messing with once that there was a way to get into the recycle bin, so a little documentation and AI searching and crafting, and we get the following number. This script will both search for a term in the name or original path, and if you choose will restore the item(s) back to the master database. A quick little workaround for that pesky search problem!

$searchTerm = ""
$restoreItems = $false

$database = Get-Database -Name "master"
$archive = Get-Archive -Database $database -Name "recyclebin"

# Get all items in the recycle bin
$archiveItems = Get-ArchiveItem -Archive $archive |
    Where-Object {
        $_.Name -match $searchTerm -or
        $_.OriginalLocation -match $searchTerm
    }

foreach ($archivedItem in $archiveItems) {
    Write-Host "Found deleted item: $($archivedItem.Name) | ID: $($archivedItem.ItemId) | Path: $($archivedItem.OriginalLocation)"

    if ($restoreItems) {
        Restore-ArchiveItem -Archive $archive -ItemId $archivedItem.ItemId
        Write-Host "Restored deleted item: $($archivedItem.Name) | ID: $($archivedItem.ItemId) | Path: $($archivedItem.OriginalLocation)"
    }
}

Getting fields from a "linked" Sitecore rendering parameter - good news, bad news

Kenneth McAndrew — Sat, 20 Sep 2025 10:50:55 +0000

Recently working with Sitecore, I had a scenario where I was trying to set a filter key and value to pass to Sitecore Search from XM Cloud via rendering parameter. I have a rendering that gets back search results, but the client wanted to sometimes restrict those by a certain field to a certain value. Since we have all those taxonomy values in Sitecore, we hooked up both key and value as droplink fields. Which makes sense, because you don't want to lose track of the item if it moves.

Here's the catch...by default, Sitecore Search doesn't capture IDs, but textual values. Well, you can make it capture what you want with the API Push, but you don't want to throw everything in necessarily. Plus by default, you're going to think of getting the textual value in case you want to use it for faceting somewhere else. So you need the name (or display name, or a value in a field) back instead. But by default (a lot of that "default" going around!) you get just the ID in a rendering parameter.

Enter this Sitecore setting value: LayoutService.DetailedRenderingParams. If you set this to true, then your Edge output will show the custom field output automatically in the spot for the rendering parameters instead of the ID. So there you go, an easy mapping, you get whatever value you need, and you're off to the races!

Well...close. So close. What if you actually do need the ID of the item? Or its name or path? Unfortunately, those aren't available in the output. Why I'm not sure, but I had another scenario where I was taking that droplink ID and passing it to an API call for another purpose. If I can't have it both ways, I have to defer to what data I can get (the ID) and get the other data I want another way. In my case, I switched to droplist for the key and text for the value, for now at least. I do have a feature request in for adding these basic values with Sitecore, so hopefully we'll see this become more complete soon.

An additional reminder, if you turn this feature on, it'll be on for all rendering parameters. You'll want to make sure you review any "link" field types you've used (droplink, treelink, etc etc) for how you're using that parameter value. Even after the ID is added, it won't be as simple as just getting the parameter anymore and having the value, you'll need to map to a model to pop about that ID. So definitely do your regression testing!

Sitecore XM Cloud: The Final(?) Word on Content Resolvers

Kenneth McAndrew — Tue, 09 Sep 2025 14:07:42 +0000

This is a follow-up post to my prior two blogs on content resolvers and the issues we've run into with them in play. I felt it was important to share this information with the community, especially as in the days since I wrote the blogs, I actually saw folks posting about using the content resolvers, and I wanted to warn them off.

First bit of news, we've had some a small testing group testing our alterations on a QA instance, and I'm pleased to report that so far, Edge publishing is working as expected again. To be clear, when you have Edge publishing (AKA v2) running, you should be able to change an item, like a datasource or a subitem to a datasource, and have associated page(s) reflect that change to Edge with only publishing the changed item in question. For example, we have a masthead datasource that's connected to a rendering in a partial view in a shared site, and I made a couple of changes to it and did a smart publish. When I check the Edge Playground for the homepage of my specific site, I see the change reflected. And when I refresh the page after a Netlify revalidation period, I see the change reflected on the front-end as well.

To be clear, content resolvers do work. But their use has the effect of putting your site into the original "v1" publishing state, where you'll have to republish your site to get things to render out. This was the whole reason Sitecore invented the Edge publishing model, to bring things closer to the "legacy" model that clients came to expect...change and publish something, it appears.

So this morning, we received this back from Sitecore Support. I wanted to share it, as I believe it justifies the effort we went through (and these blogs), and also it is going to result in documentation changes on their end. I should also give Support a lot of credit, as they diagnosed the issue based on a specific case we provided them among publishing frustrations that we were experiencing...it ended up being the string to pull on to untie the proverbial knot, it seems. So big kudos to them!

After a thorough review of the current architecture, we have to admit that there doesn't seem to be a straightforward way to change the behavior associated with the Navigation Resolver without needing to republish a large number of additional entities. As a result, rendering content resolvers are currently considered incompatible with Edge runtime publishing. We will update the documentation accordingly to reflect this. Thank you for highlighting this point.

For navigation components, we recommend you consider using either one of the following approaches:

Use the "Component Level Data Fetching" approach described in the Performance-optimized page listing article. This way, you will be able to handle rendering parameters in your component and modify the query to fetch the needed data.

Alternatively, you can use integrated GraphQL as mentioned earlier. However, please note that this approach doesn't allow integrating rendering parameters into queries.

The methodology they describe in item 1 is what my last blog on the navigation resolver was all about. Fair warning: the out-of-the-box Navigation rendering that ships with Sitecore XM Cloud - or maybe some starter kits in the Content SDK era - uses the navigation content resolver, so if you're thinking of using it, I advise against it.

I'm glad we were finally able to slough through this for our client, and I really hope this information helps out others in the community. Cheers!

Sitecore XM Cloud: Getting Around the Navigation Content Resolver

Kenneth McAndrew — Fri, 05 Sep 2025 01:26:48 +0000

So, in my last blog, I implored you all to avoid rendering contents resolvers. What scares me is I feel like I said it too much, like I called for Beetlejuice, because lately I've seen a couple of blogs discussing their use. I'm very much an advocate against them, but as I noted, the navigation content resolver is a sticky wicket.

Why a Sticky Wicket?

Well, to be honest, the rendering parameters are the problem. In theory, you could write GraphQL to traverse your site tree, give it a bunch of "children" calls, and call it a day. You might need to up your complexity a lot on the CM side, but the Edge side is pretty hardy. But, those rendering parameters are tricky for a couple of reasons:

The level from/to and navigation filter dropdowns are droplinks, which means you'd need to resolve those IDs first, an extra step. There's a config way to do this, but it's not perfect yet, and I put in a feature request as a result.
Trickier part...you can't pass rendering parameters to GraphQL on the rendering itself. So you're stuck with GraphQL in your component file, and you need to figure out how to work the levels. Luckily, that's what this blog is to help with!

Setup: Rendering Parameters

First things first, make your own rendering parameter template for this effort. I used droplists for the level from, level to, and navigation filter options. I also put in a field for how many children to retrieve, since you have to specify beyond the default of 10. Note that, for now at least, I dropped the start page parameter (we'll assume we're starting at the homepage) and the flattened and add root parameters (we'll assume you'll configure the output as needed). Hook this parameter up to your rendering definition.

Setup: The fetchNavData function

From here, in the TSX file (we're rolling with the OG XM Cloud foundation header), we're wrapping the call for fetchNavData in a useEffect call. We're passing in the context ID for the page we're on, the level from, the level to, and the children count.

First thing we're doing is getting the full Sitecore path of the context ID we're on. Once we've got that, we use the level from value to calculate what the starting path should be, by parsing the Sitecore path down to where it needs to be. Then we build a GraphQL query where we dynamically slide in the number of child levels we need (level to - level from), and finally execute it.

Now that's a lot to work through, but as I'm a big believer in this, I'm going to provide the code you need. Feel free to tweak it as needed, of course. I'm using this shared code file for both a contextual navigation component and a sitemap component. Note the lib/graphql-client-factory was in the foundation head I believe, so that code should be findable online.

import graphqlClientFactory from 'lib/graphql-client-factory';

export type NavFilter = {
  fields: {
    Key: {
      value: string;
    };
  };
};

export type NavItem = {
  id: string;
  url: { path: string };
  title: { value: string };
  navTitle?: { value: string };
  navFilter?: { filters: NavFilter[] };
  children?: { results: NavItem[] };
};

export type NavResult = {
  QueryResults: NavItem;
};

export type NavPathResult = {
  QueryResults: { path: string };
};

export type NavSectionProps = {
  key: string;
  item: NavItem;
  navFilter?: string;
};

export const fetchNavData = async (
  contextId: string,
  startLevel: number,
  endLevel: number,
  childrenToShow: number
) => {
  let navData = null;

  try {
    const graphQLClient = graphqlClientFactory();

    // 1. Get the full path of the context item
    const navPath = await graphQLClient.request<NavPathResult>(NavPathQuery, {
      datasource: contextId,
      language: 'en',
    });

    if (!navPath?.QueryResults?.path) {
      return { navData };
    }

    // 2. Compute the "start path" at the requested level
    const startPath = getPathUpToLevel(navPath.QueryResults.path, startLevel);

    if (!startPath) {
      return { navData };
    }

    // 3. Build the query (just structure, no baked-in path)
    const navQuery = getNavQuery(endLevel - startLevel, childrenToShow);

    // 4. Run query with $datasource = startPath
    navData = await graphQLClient.request<NavResult>(navQuery, {
      datasource: startPath,
      language: 'en',
    });
  } catch (ex) {
    console.error('Failed to load data for nav component:', ex);
  }

  return { navData };
};

function getNavQuery(levels: number, childrenToShow: number): string {
  const fields = `
    id
    url { path }
    title: field(name:"Title") { value }
    navTitle: field(name:"NavigationTitle") { value }
    navFilter: field(name:"NavigationFilter") { filters: jsonValue }
  `;

  const childrenBlock = buildChildren(fields, levels, childrenToShow);

  // Use $datasource instead of hardcoding path
  return `
    query NavDataQuery($datasource: String!, $language: String!) {
      QueryResults: item(path: $datasource, language: $language) {
        ${fields}
        ${childrenBlock}
      }
    }
  `;
}

// Build children nesting (recursive helper)
function buildChildren(fields: string, level: number, first: number): string {
  if (level === 0) {
    return '';
  }

  return `
      children(hasLayout: true, first: ${first}) {
        results {
          ${fields}
          ${buildChildren(fields, level - 1, first)}
        }
      }
    `;
}

function getPathUpToLevel(fullPath: string, level: number): string | null {
  const parts = fullPath.split('/').filter(Boolean);

  // Find "Home" in the Sitecore path
  const homeIndex = parts.indexOf('Home');

  if (homeIndex === -1) {
    return null;
  }

  // Slice from start of path → requested level past Home
  // Example: level=2 => Home + 1 child
  const endIndex = homeIndex + level;

  if (endIndex > parts.length) {
    return null;
  }

  const wanted = parts.slice(0, endIndex);

  return '/' + wanted.join('/');
}

const NavPathQuery = `
query NavPathQuery($datasource: String!, $language: String!) {
  QueryResults: item(path: $datasource, language: $language) {
    path
  }
}
`;

Usage in the Rendering

From there, add the useEffect call to your rendering TSX file to get the data (included are the relevant references):

  const { sitecoreContext } = useSitecoreContext();
  const contextId = sitecoreContext?.route?.itemId ?? '';
  const levelFrom = parseInt(props.params.NavLevelFrom ?? '2');
  const levelTo = parseInt(props.params.NavLevelTo ?? '5');
  const childrenToShow = parseInt(props.params.Children ?? '20');
  const navFilter = props.params.NavFilter ?? '';

  const [navData, setNavData] = useState<NavItem | null>(null);
  const [loading, setLoading] = useState(false);

  // Fetch nav data
  useEffect(() => {
    if (!contextId) return;

    fetchNavData(contextId, levelFrom, levelTo, childrenToShow)
      .then((data) => {
        setNavData(data.navData?.QueryResults ?? null);
        setLoading(true);
      })
      .catch((err) => console.error(err));
  }, [contextId, levelFrom, levelTo, childrenToShow]);

The data model is in the other code above, so it should be all nice and neat. From there, you can work up the appropriate front-end code to loop through the data model, put in a loading image, or whatever else you'd like to do for the presentation.

Happy coding!

Rendering Contents Resolvers and XM Cloud - Just say NO

Kenneth McAndrew — Fri, 29 Aug 2025 02:03:10 +0000

There is a feature in Sitecore renderings called Rendering Contents Resolvers...you'll find a dropdown near the bottom of the settings for a rendering. There's a few entries there, like Context Item, Datasource with Children, Context Item with Children, Navigation...all kind of self-explanatory, all useful...

And all toxic in Sitecore XM Cloud. All. Of. Them.

Working on a big XM Cloud project, also my first, has been a heck of an experience. One thing early on we struggled with was how to create a sitemap page, and how to create a contextual navigation component. We were directed by Sitecore to the Navigation rendering content resolver, which is also used on their out of the box Navigation rendering. With that "blessing" in mind, we also would use other content resolvers to help expedite some of our work.

What we ran into was publishing hell. There were times that we'd do a publish from Pages (which is a smart publish by default), only to not see Experience Edge update with the appropriate content. This wasn't just on a site level for that data folder, but even content directly subordinate to the page. It would take a republish, and sometimes more than one, to fix the problem. We're using the Edge publishing model as well, sometimes referred to as the "v2" model, which isn't supposed to require a publish of all pages when a change is made to ancillary data.

We didn't even thing of the content resolvers, since Sitecore had said the navigation one was okay, so why wouldn't the others? But the struggles on publishing reached a breaking point and we've been raising it so far up the flagpole, I think the flag is popping off the top of the pole. Pinging support about it when we had a clear sample of the issue, we finally got an answer.

"The fact that the component uses rendering contents resolver is important because it changes the internal reference to the data source used by the page's layout. Such configuration requires you to republish the page itself to update the layout"

Uhhh...what? A content resolver changes the internal reference to the data source used by the page's layout? Well that wasn't advertised! On another matter, Sitecore referred us to their Publishing to Experience Edge Accelerate recipe, and sure enough there's a section in there about content resolvers. But...if you read it carefully, it says custom resolvers are not supported, but specifically mentions the navigation resolver that should be utilized.

Friends, I haven't written a blog in two years, because I was in the PM wilderness, but now that I have crossed back to the garden of development, let me preach to you...DO NOT USE RENDERING CONTENTS RESOLVERS AT ALL!

Ahem...sorry.

But seriously...don't. We started yanking them from our project, and I've noticed publishing getting markedly better. The challenging part was the navigation resolver replacement...how to do it right, how to use the rendering parameters, etc...but there was a way. And I'll be glad to share it with you all...

Next post.

Beyond "local" for Sitecore SXA/XM Cloud

Kenneth McAndrew — Sat, 25 Nov 2023 15:28:26 +0000

Okay, let's get one thing out of the way. Yes, it's November 25th. Yes, Sitecore MVP applications are due in a few days. Yes, folks write blog posts as a contribution. Yes, it's the last minute. Am I doing this specifically for that purpose?!?

Not really, but it doesn't hurt! Plus it's harder to put technical blogs together when I'm a project manager now.

I recently got assigned to my first XM Cloud project...yes, as a project manager, but I'm using what I know of Sitecore and the great community around it to help source information for my team. And it doesn't hurt to keep knowing enough to be dangerous. So as I gather some of these tidbits, I'll try to blog them for our reference and others.

Today is some research I was doing to set up either partial designs or page branches (a topic I'll go into in another post), and using relative references with them. To clarify, "relative" references in Sitecore are those that use SXA keywords like local to denote the datasource, like local:/Data/Text 1 when you add the OOTB rich text component to a page. This is different from the traditional Sitecore datasource reference, where you see a path but behind the scenes is the ID, to keep the content locked in even if you move it. For a relative datasource, someone could move or rename it, and it'll break the datasource. So keep that in mind!

So if you're an SXA "legacy" user, the local keyword is one you're familiar with. But there are others in the Sitecore documentation that we don't usually think of, but could be very useful.

First is page, which is actually similar to local, in that it works relative to the item you're on. The difference comes when applying it from a partial design. On a partial, the local keyword will always look for the datasource local to the partial design itself, whereas page always looks for the datasource local to the implementation. So if you had a page datasource call on your partial design, anywhere you use it needs to have a datasource relative to the page it's used on. For example, if your partial has a hero component pointed to page:Data/Hero then every page the partial is on needs a Data folder with an item named Hero.

The other I'm finding useful is query as this lets you take advantage of tokens. This comes in handy if you're storing your datasources in the SXA site's Data folder (IE that's where you choose to store things, or the datasource is site-wide). SXA adds a $site token to identify what SXA site you're referring to, which you'll see used a lot in datasource locations in renderings (which sounds like another topic to expound on). But you can use it in your relative datasources too with the query command, like query:$site/Data/Texts/Text 1 which will look in the site-level Data folder.

Again, remember that the datasources using these keywords are relative and can break if the item is moved or renamed, a bit more fragile than the typical datasource connection. But there's a solution for that too, if you need it. If you right-click on an item, in the Scripts menu there is an option for Convert data sources to GUID that you can use to "lock in" those content links. You can also use security to prevent users from renaming or moving items, which would handle the situation as well.

SUGCON NA 2023 - What I'm Looking At

Kenneth McAndrew — Sat, 30 Sep 2023 20:29:53 +0000

It's almost October, but instead of a Sitecore Symposium this year, the event will be a North American SUGCON (I think the first in a number of years). A day and a half in Minneapolis...well a week for me between the MVP Summit, DX, and then SUGCON. So what am I looking at in the agenda? We've got an XM Cloud migration from "legacy" Sitecore on the horizon, so this is a timely event.

MVP Summit

Nice try, I can't tell you! :)

SUGCON

After the usual opening morning of keynotes and presentations, we get into the breakouts.

Unlocking the Power of AI: Migrating to Sitecore Headless / XM Cloud 10 Times Faster

I'm not sure about the whole AI craze yet (hello Skynet?) but the meat of this session will be about migrating from "legacy" Sitecore to the headless/XM Cloud Sitecore. This is a trend that's going to ramp up more as time goes on, I think.

Crafting lightning-fast composable digital experiences

One of the big draws of the headless/composable architecture, besides the composable, is the performance gains that are touted on the end sites, from load speed to Lighthouse scores.

Content Hub DAM Maturity Model

Content Hub is another of those areas to be looked at more closely...let's face it, while the media library has been convenient, it's not designed for ultra-rich amounts of content. We have a client that is probably near 200 GB of media content in the media library, but it's only by the grace of Azure blob storage that we aren't going mad. This is the next step up.

Build for XM Cloud according to the Architect of XM Cloud

Let's face it, if you could learn at the feet of the creator, wouldn't you?

Implementing Sitecore Search

Without Solr in the mix for the headless front-end, search solutions will become a bigger lift; for example, no Coveo out-of-box components this time if you go that way. Sitecore introduced its own search platform that will likely be looked at very closely. After all, while it's a composable stack, staying "in the family" likely has benefits.

A University's Journey to the Creation of their Composable Roadmap

I'll be honest, my original intention was to go to "Tips and tricks for Next.js and Sitecore Headless" but I'm co-presenting this session, so I'm occupied! We're going to talk about our roadmap project with Michigan State University and their march to composable. Come on by before dinner!

Building No Code Integrations with Sitecore Webhooks and GraphQL

Webhooks are the next evolution from the old pipelines we used to write, so I'm curious to learn more.

No Compromises in XMC: On Demand Revalidation with Experience Edge

This is a session about speeding up getting your content from author to end-user, something that is always handy.

Sitecore Symposium Aftermath: My Thoughts on XM Cloud

Kenneth McAndrew — Mon, 24 Oct 2022 01:54:33 +0000

So I got home yesterday from Sitecore Symposium and it was an interesting time. My feet are finally recovered from all the walking around the Museum of Science, at least! But you didn't come here for that. I have some thoughts on stuff I heard at the conference that I wanted to share. I should note, these are my opinions, and just because I'm a Sitecore MVP doesn't mean I have to cheerlead everything they do. They're getting there with this stuff, but there's work to be done for sure.

So, XM Cloud. Sitecore announced its availability in July, when it wasn't really (marketing and development really need to talk more). A few partners have gotten in there to look around, and they've written some blogs about it that you can find out there. This isn't looking at all of the technical details, but more the overarching concept and its readiness for prime time.

The Good

XM Cloud is Sitecore's foray into the SaaS space, an evolution of the managed cloud approach they're using now. The big difference is, Sitecore will handle the updates and upgrades for you. Given how much of a pain these can be sometimes, that'll be a welcome note for many companies. In the background, XM Cloud is run on containers, making this an easy prospect. (A hope on my part is that Sitecore will start patching their existing 10.x containers with hotfixes as well, rather than leaving it to the developers to do.)

One thing to note, despite the name being XM Cloud, Sitecore is positioning this as the evolution of XP, the version of the current product with the analytics mixed in. You won't have to deal with the morass of app services and databases anymore, though, which is a definitely upgrade for your sanity.

Setting up new sites will be pretty straightforward too, at least their structures, with a wizard setup. If you're familiar with SXA, you'll find things will start falling into that model. This will put more management of the site into the business' hands. There will also be a new Pages interface, the evolution of the experience editor and Horizon editor, but don't worry the content editor is hanging around. Also, Sitecore is encouraging more connectivity with webhooks and APIs, part of the composable idea of linking in whatever service(s) you need with XM Cloud as your central CMS.

Is It Ready?

If you have a basic site, then XM Cloud may very well be ready for you now. But a lot of us that use Sitecore don't get that luxury, and beyond that there are considerations you'll need to take into account.

First is this, as of this writing, there's no support for item security on the front-end of the site, nor for extranet logins native to Sitecore (IE the core/security database). So if you use a login system with Sitecore roles today to determine what content folks see, it's not there yet. What you need to keep in mind, there's no content delivery server as you know it, but static pages that uses Graph QL for interactivity. There's no web database being looked up or the like.

There's also no index available by default; the Solr indexes are only available to the CM. This means the old ContentSearch APIs are no longer valid, if you did searches that way or looked up data in buckets. Graph QL has a forward-only query method that you can use in the buckets type case, but if you made your own search page experience with facets, it's obsolete. Sitecore will be offering a Search product soon, which relies on page crawling...think Coveo if you've used that. You can use Sitecore Search, or Coveo, or SearchStax has a crawler/hosted search page, etc...that's the idea of the composable stack.

Are You Ready?

In a similar vein, you have to remember that if you're on the "legacy" Sitecore with MVC today, any move to XM Cloud will never be just an upgrade. XM Cloud only supports the headless technology, so your application will have to be rewritten. While Sitecore says any headless protocol will work, I'll tell you that most folks pushed the JSS/NextJS approach during Symposium. While I know the .NET Core Rendering SDK method is out there, I'd take a hint from what Sitecore folks were mentioning more as far as future-proofing is concerned.

One good thing is Sitecore did announce the "bridge" from the MVC world to the headless world, in the form of Sitecore 10.3, due out in a few weeks. The big news here was that it will include headless SXA, which is a basis of XM Cloud. If I had any advice, I'd get this and bone up on headless using it.

When Will XM Cloud Be Ready?

That really depends on your needs. Keep an eye out for how the product evolves. But based on the containers approach that was pushed ultra-hard after 10.1 was released, then backed off on, I'd say to give Sitecore a year to really get some feature parity, or workarounds in place, to handle things that have been commonplace to the "legacy" developer. Meantime, get yourself a copy of 10.3 and start learning that headless world. You can always build headless there and push that product out, and sell it to your clients as making the transition to XM Cloud much easier later on if that's how they choose to proceed; if they don't go there, it's at least more up-to-date as a tech stack than .NET Framework 4.8 stuff is.

I'll try to write some more about some other big idea areas coming out of Symposium. My approach to all of this is pragmatic...I want folks to advance on the tech stacks for sure, but realize that some stuff isn't quite ready for prime time in certain circumstances. Do your research, talk to your Sitecore rep, read what others have to say out there. If you know what the limitations are or the rework needed, you're better informed to know if you should go now or stand pat and wait.

Sitecore Managed Cloud Containers: An Introduction

Kenneth McAndrew — Thu, 17 Feb 2022 00:03:47 +0000

So, back to the beginning. What is Sitecore managed cloud containers?

First, let's back up a bit more. Sitecore started a managed cloud service, where they would set up the infrastructure of your Azure environment for you, leaving you to manage your solution more than the ins and outs of Sitecore. It's not truly software-as-a-service (SaaS) in that you still need to handle upgrades and patches; Sitecore is preparing a SaaS offering in the near future, however. But the idea is they'll handle architecture, alerts, watch performance, etc.

This splits into the platform-as-a-service (PaaS) camp and the containers (Kubernetes) camp. The PaaS side, to be honest, is very much like you can set up with the Azure marketplace today, but with Sitecore backing it and adding alerting to help you, and them, out. The containers side is more robust and "modern" and what we'll discuss here at a high level.

What You Get Out of the Box

When you set up a new containers instance with Sitecore (done via a service request in the support portal), you're given the following assets:

Azure Kubernetes Service (AKS): The place that will run your containers, equivalent to the app services of the PaaS world.
Container registry: This is where you will upload custom images to use for AKS. We'll discuss this a bit more below.
FrontDoor/Web Application Firewall (WAF): The routing tool that exposes your front-end addresses, such as the CM, CD, identity server, and others you might add in (like Horizon). The advantage here is that unlike a PaaS setup, your xConnect services aren't publicly exposed. The WAF helps protect you from malicious attack, and by default is set for the CD only, but you can create a WAF to use for IP restrictions on your CM. (That's another blog post!)
Azure SQL: All of the databases you need for Sitecore. But in this containers world, Sitecore got wiser and is making use of elastic pools, allowing resources to be shared between databases, so if your master database needs more "oomph" but your xConnects don't right away, you can rob Peter to pay Paul, so to speak.
Key Vault: A secure place to store your secrets and certificates. By default you'll find SQL usernames and passwords, Sitecore's admin password, and a host of other information. This gets read into the containers but not written there, keeping the data protected if someone cracks your pod. Of course, you can add your own secrets and wire them in. (Yep...that's another blog post...)
Azure Dev Ops repository: Wait...you get another one?!? Well, read on...

The Managed Cloud Dev Ops Repository

First, let's be clear, this is not for your solution code! You'll maintain your custom code in your own repository, and as part of your build process, you'll create a custom image that'll be sent over to the container registry. (You guessed it, another blog post!)

Sitecore provides two repositories: infrastructure and application. The infrastructure repository sets up the guts of your environment, and if you look through there you'll see things like FrontDoor clear as day. This is the repository you're less likely to change, but if you need to add an endpoint (like for Horizon) or WAF to FrontDoor, this is where you'd do it.

The application repository is what establishes the containers, identifies the images to be used, connects the secrets via Key Vault, etc. By default, you get an out-of-the-box Sitecore instance. As time goes on, you'll replace at least the CM and CD images with your own, and if you customize other images, this is where you'll do that as well. When you push a new image up, you'll update the tag and run the application pipeline, which will deploy your changes for the world to see.

Now That You've Seen It From 10,000 Feet...

Future blogs will dig into some of these processes more, as well as some practices I've helped put together that helped us get going. But you can get started with Sitecore's Docker examples...in fact, our upgrade project started out from their "custom-images" folder. From little acorns, mighty oaks grow.

Now, am I saying to do it my way? Nope! But managed cloud containers is a bit of a "wild west" at the moment, and anything we can do to provide guidance is helpful. I'd encourage you to join Sitecore Slack, the Docker channel will be good to help you get going, whether with this or Sitecore containers in general. For now at least, this is the direction Sitecore is moving in, so becoming familiar with Docker/Kubernetes/containers is important.

Good luck!

Get Docker Running Without the Desktop

Kenneth McAndrew — Mon, 14 Feb 2022 11:38:19 +0000

As many of you may know, and I'm sure you find out if you go to download it, Docker Desktop is no longer free. While I don't think they have a mechanism to check these things, technically if you're on a bigger team or your company earns a good chunk in revenue, you're supposed to pay for it now. And a Docker account does get you some benefits.

But...it's one of those "carpet pulled from under your feet" things, isn't it? Kind of like when Oracle said you had to start paying for JDK, and all us Sitecore developers were using it for Solr, and were like "uh, what?!?" Of course, now everyone knows how to use OpenJDK, and Sitecore even baked that into its setup scripts. So, similar principle.

Fortunately, it's only a few things needed to get Docker running "in the wild" so to speak. Fire up your trusty Powershell prompt and start here:

choco install docker-engine docker-compose docker-cli choco install Containers Microsoft-Hyper-V --source windowsfeatures

This gets the basics of Docker installed for you, including the engine and command structure. Also, for Sitecore folks, it gets Hyper-V installed and ready for Windows containers.

The next bit you may not have to do, but I definitely did. When I tried to fire up my docker-compose process after removing Docker Desktop and using the commands above, I got errors in my solution build trying to hit the Nuget site. The fix is to update the C:\ProgramData\docker\config\daemon.json file (which you could do in the settings in Docker Desktop). Our version that worked is as follows (your mileage may vary on this one):

{
  "registry-mirrors": [],
  "insecure-registries": [],
  "debug": false,
  "experimental": false,
  "dns": [
    "10.1.2.3",
    "8.8.8.8"
  ],
  "features": {
    "buildkit": false
  },
  "builder": {
    "gc": {
      "enabled": true,
      "defaultKeepStorage": "20GB"
    }
  }
}

Finally, you need to start the Docker Engine service; it was installed above but not started. Again, Powershell, and run this command:

start-service -displayname "Docker Engine"

The other nice thing Docker Desktop provided was monitoring of your containers and images, as well as quick access to logs and a terminal prompt. Well, there's another tool that can do that for you...Visual Studio. I believe the "classic" Visual Studio has it, but I use VS Code for this one. If it isn't already installed, check your extensions for the Docker and Docker Explorer ones at the vary least. Once you do this, you'll have a sidebar item for Docker that will give you access to everything you need. The one catch is you may need to either run VS Code as an administrator, or set up your Docker Engine service to run as an administrator. I chose the first option myself, but do what works for you (subject to your company policy of course!).