Start of Main Content

When I attended Sitecore Symposium two years ago, some of Sitecore’s messaging on XM Cloud made me a little uneasy. As Sitecore’s portfolio of products grows, there has been much discussion about XM Cloud’s parity with Experience Platform (XP). One of the biggest conversations, and the source of my concern, was Content Manager (CM) customizations in XM Cloud.

Nearly every client project I have worked on has required CM customizations, from scheduled import tasks to keep Sitecore items in sync with an external DAM; to on-save actions that generate content and custom search indexing that transforms Sitecore content for Coveo or Solr; to custom content editor ribbons and workflow commands. My clients have complex, specialized business requirements, and previously, the path forward for customization in XM Cloud was unclear. With XM Cloud presented as the next step for Sitecore customers and with Sitecore’s long-term commitment to XP uncertain, transitioning to XM Cloud seemed like an inevitability.

Thankfully, this year, Sitecore’s messaging on the path forward for customization in XM Cloud and their commitment to continue support for XP left me relieved and excited. It seems like Sitecore’s C-suite and product owners are listening to the concerns of their customers and the developer community and understand the various circumstances clients face around delivering their digital experiences. These are my big takeaways from the Sitecore Roadmap session that thrilled me and alleviated my wariness from two years ago:

  • Sitecore has committed to continue supporting and modernizing XP until at least 2032. This is great news because, in my experience as a support developer, many users stay on older technology for years after newer tech is released. I still had clients on Sitecore 8 until recently. A lot of consumers are the type of people who don’t buy the first-generation smartphone but would rather wait a few years for all the bugs to be discovered and fixed. It also gives customers more time to work out the most strategic way to migrate to XM Cloud without feeling rushed, and to wait until more tools and documentation for XM Cloud migration and development are available.
  • Customizations to XM Cloud will be possible and will specifically support highly customized solutions — just with a different technological approach. More on that in a bit.
  • The Marketplace is coming back!

Sitecore clearly understands that clients require customization, but their challenge was figuring out how to make that compatible with a software-as-a-service (SaaS) product. The issue isn’t just that Sitecore doesn’t like unscrupulous developers breaking the content editor or making it unusably slow with bad custom code; one of the main benefits of a SaaS solution is scaling up and rolling out updates automatically, a process which is not compatible with custom code.

Any time the solution is scaled up, files manually installed in the filesystem won’t get included so they’d need to be reinstalled (and this can happen any time without warning). Sitecore cannot guarantee that their updates will not break these customizations, so they cannot allow changes to the CM’s file system (i.e. custom dlls, config files, JavaScript files, and aspx pages — all the ways that as a .NET developer, I used to customize Sitecore). Instead, customizations will happen via external stand-alone applications, available from the Marketplace, that use the Authoring API, webhooks, and other methods developed specifically for integrating with Sitecore from an external app.

If you’ve been in the Sitecore world for a while, you may remember the old Marketplace, a platform where developers could share their modules and users could search for and download them. Note that I say “module” instead of “application” because, in the old Marketplace, these were typically packages installed via the installation wizard to upload files to the CM filesystem. The new Marketplace is the same premise but for XM Cloud SaaS-compatible apps with standalone applications that run externally, and plugins that will modify the Sitecore user experience. These external apps will allow integration with XM Cloud without impacting CM performance or causing issues with SaaS updates.

It’s important to understand why .NET developers used to deploy customizations to Sitecore directly. The GraphQL APIs (Authoring and Delivery) and webhooks were only released in version 10.3; they didn’t exist before 2022. Using the .Net Item API requires an application with all the Sitecore dlls and dependencies, and events such as item saving, publish, etc. are only triggered within the Sitecore applications with no way to detect them externally before webhooks. Before 10.3, Sitecore wasn’t built to be modified by external applications. Now, from 10.3 on, Sitecore not only has those capabilities, but they’re the recommended (and soon-to-be-required) approach.

One initial concern about using a standalone application instead of native customization is that with the latter, it’s simple to restrict any custom admin pages so that they’re only available in the CM instance (not on the public endpoint), and ensure they have the same security restrictions that the user has in Content Editor. In other words, pages like my Content Export Tool or a custom .aspx page to manually trigger an import task aren’t publicly exposed. An external app with a web interface for users to interact with wouldn’t inherently possess the same security restrictions that Sitecore has, and we would need to make sure that any web app that interfaces with Sitecore requires the user to log in. Fortunately, the Sitecore security module simplifies integrating Sitecore security into a JSS app. You’ll need to make sure to consider this in your app development.

My other concern with creating an external application to integrate with Sitecore is that this is a new technological approach that I’m unfamiliar with, and I want to ensure there’s sufficient documentation to guide developers on how to do this. To be vulnerable for a minute, I get anxious about things I don’t know how to do. I could write a custom item:save processor or import script in my sleep, but the prospect of starting over with entirely new methods that I’ve never done before intimidates me. Anxiety aside, Sitecore XM and XP have been around for many years, so there’s no shortage of documentation and blog posts to guide developers on how to customize a Sitecore solution natively or build an external module that can be installed in any instance. However, the Marketplace hasn’t been released yet, so it doesn’t have this huge trove of documentation and community blog posts to assist developers yet.

Want to know more about Sitecore’s plans for customization in XM Cloud?

Our Sitecore MVPs can explain what Sitecore’s announcements from Symposium mean for your long-term planning and address any questions you have so you can continue to succeed on the platform.

At the MVP Summit, Justin Vogt hosted a working session where he asked the audience what we would need to build standalone apps and plugins for the Marketplace.

I raised my concern about documentation, and Justin suggested that Sitecore can provide an open-source getting-started Marketplace module in github in addition to documentation on the website. This was exactly what I needed to hear, and I’m now very excited to work on my first Marketplace project, which is bringing the Content Export Tool to the Marketplace so it’s available in XM Cloud.

A final question you may have about Sitecore customizations, and the Marketplace is, “Marketplace sounds like a platform for public apps. If my site needs customization unique to our business needs or has proprietary code, why would it be hosted in a public marketplace?” The short answer is that all apps on the Marketplace can be private or public. Having it on the Marketplace allows it to be added to your XM Cloud instance so it’s preserved when your Sitecore instance is scaled or updated. But it can remain private to your organization.

When I went to Sitecore Symposium in 2022, I felt a bit anxious because there wasn’t a clear path forward for customizations and XM Cloud. This year, I felt like Sitecore was listening to its customers, and that our community feedback was valued. They understand that customization is necessary and have a path forward for allowing customizations in their SaaS product. I left Symposium this year feeling optimistic and excited for the future of Sitecore development with XM Cloud, and eager to dive into the Marketplace.

Want to know more about what these developments for XM Cloud mean for your organization and your long-term Sitecore planning? Contact us. Our Sitecore MVPs would be happy to discuss your concerns and address any questions you have.

Published:

Latest Ideas

Take advantage of our expertise with your next project.