Showing posts with label XMCloud. Show all posts
Showing posts with label XMCloud. Show all posts

Thursday, May 8, 2025

SUGCON 2025 - the part with XM Cloud Content

SUGCON 2025 - XM Cloud Content

Save the best for last...  that does not only count for this blog post series, but also for Sugcon 2025 itself. Before we continue, as this is part three I also have a part one and a part two 🙂


XM Cloud Content


Alistair Deneys had the honor of presenting us XM Cloud Content. 

Let's start with "what is XM Cloud Content?".  Seems a very simple question but to be honest since the conference I have seen a few answers to this question. After the presentation one would have said this is a new CMS. But apparently some people who had heard about something like this before, seem to think it's not a new product but the base for a brand new version of XM Cloud. 

The session description on the Sugcon website tells me this:
XM Cloud Content is going to be an evolution of Content Hub ONE, Sitecore's fully managed headless CMS. Come and have a peek at this new product which is currently under development at Sitecore.
So for me at the moment we are looking at a new CMS. Which would be great as it has become very clear that XM Cloud as it is now is not suited for everyone and Content Hub One is dead. A new product to fill that gap would be tremendous news so let's just assume that is really what we saw here. 


XM Cloud Content should become the result of all the knowledge Sitecore captured over the past years about creating a CMS - the good things but certainly also the bad ones. Learn from your mistakes is a good credo, and we did see some of that already in the first basics of the newborn. 


Foundation


For SAAS products we shouldn't care what is behind the wall. If it works well it's ok. And although this architecture diagram probably doesn't mean much - it did help making a point about something that has been bothering Sitecore users for a long time. I'm talking about publishing - which will still be possible here but there will be no database transfers anymore making it a lot easier to make this finally fast. 

Probably a bit more interesting already is the domain model. 
  • Items will be defined by content types
  • Taxonomies will be used to classify items
  • Fragments can be used for re-usable content type parts, but as they can also be used in searches (and maybe security?) they become a vital part in composing a good content type structure


Seems all pretty simple and very similar to other equivalent products.


Queries

Queries are done with GraphQL and it seems we will get many options. One that was interesting is querying on fragments as that might avoid having lists of content types in your query. 


Note that the GraphQL schema is definitely not final yet (as is all the rest) and Alistair is looking for feedback on this part. 

There would also be a way to save GraphQL queries - a bit like stored procedures in a sql database. For complex queries this could save a bunch when sending the requests.

Demo 

The main part of the presentation was actually a demo - which is nice as this means something already exists and this is not just a theoretical exercise.


We did get a glimpse of a UI - which was completely in the line of what all the Sitecore products should look like these days. Clean, white, simple. But the demo was completely done with the CLI actually. 



If you can prepare scripts and json files this all goes a bit smoother of course. We saw Alistair creating the content types and taxonomy, then creating some actual content to test with and finally querying that content in several ways. 

The demo went pretty well to be honest - one would wonder what he sacrificed to the demo gods 😈 


We were also introduced to the security aspects. Those looked pretty nice - and you might think this is pretty common but there are some CMS systems out there were this is not so trivial. 

Anyway, it will be possible to restrict access via tokens based on several aspects going from the publish state and an environment to types or fragments and apparently even on saved queries.






Conclusion 


I can only say I am really looking forward to this XM Content Cloud. It looks very promising. Hopefully Sitecore can really deliver this time and can put some pricing on it that is also suitable for smaller markets.

To be continued...  maybe on Symposium?


Friday, May 2, 2025

SUGCON 2025 - part two with XM Cloud

SUGCON 2025 - the story continues with XM Cloud

Make sure to read part 1 of the Sugcon 2025 saga...

Vercel

Let's start this second part with something maybe not completely Sitecore related but very relevant to most current projects so I was glad to see Vercel present at the conference. Not only to have a nice chat with them at the booth, trying to get answers about their version and support strategy. To be honest, that is not yet clear to me but they also gave a session about optimizing Next.js - which was even for someone like me who is completely not (yet) into that Next stuff pretty interesting. 


Alex Hawley presented in a clear and very comprehensible way a few pitfalls and how to solve them. Very interesting for headless implementation of Sitecore (or even other platforms).


JSS - XM Cloud

This brings us to the next topic - proudly presented by Christian Hahn and Liz Nelson. The JSS SDK and starterkits have had a major cleanup.  Note that we are talking about the XMCloud version here. By decoupling this from the XP version a lot of became possible.



In general: they removed a lot of code, making the packages a lot smaller and faster to load.  All developers will know that this is a very pleasant step to take. It brings a fresh start and there seems to be indeed more things on the roadmap to keep on improving. 

 


It's nice to see some of the recommendations from the Vercel session coming back here in the new and improved jss, or should we say Content SDK now... 




As we are talking about XM Cloud, we cannot not mention Andy Cohen. His session was not really what I expected, but it was an eye-opener - as was his first implementation experience apparently 😐



XM Cloud - Marketplace

We are staying in the XM Cloud sphere with the session by Krassi Eneva and Justin Vogt about the marketplace Sitecore is creating for modules to extend XM Cloud. 

Well, actually they are talking about a hub to extend and customize Sitecore Products. So not limited to XM Cloud but the examples went in that direction and it does make sense. As you probably know Sitecore is heavily discouraging custom code on your XM Cloud - something that made the product in the beginning in the eyes of some not really "saas". Even though I am a developer and I always liked extending everything I do believe not putting custom code next to a product that should be SAAS is a good idea. We already had interaction points with several event webhooks. With this marketplace, we can also build real extensions into the editing UI.


 
There are a few levels in the marketplace - each will have a (slightly) different path to register your module.  A single tenant module can be used to extend the product to a use case for a single customer.  This can cover a very specific business need.  A next step is the multi-tenant module which is probably targeted at partners who want to build their own extensions and use them for multiple customers.
The public modules are available to everyone. They can be either free or paid but they must be approved by Sitecore to make sure the quality is good and the look and feel is similar to the original product. 

In order to achieve all this, there is an SDK:
 



Next

There is one more story to tell...  but that will be for part three in this years Sugcon series


Wednesday, February 15, 2023

XMCloud SxaStarter local setup - solr-init issue

 XMCloud - solr-init error on a local container setup with SxaStarter 


Headless SXA

I wanted to try the new headless SXA. As this can be installed on Sitecore 10.3 I installed that version locally and installed SXA on top (tip: a good blog post from Dan about this setup). That went fine, but I bumped into issues with SXA. I asked on StackExchange and Slack but nobody seemed to know the answer (if you do, please answer the question on SSE). I was going to open a support ticket but as this was just a test... well, you know... I'll do that when I need it in a project.

I heard there were differences between SXA in Sitecore 10.3 and the version in XM Cloud. So I decided to try that one.

XM Cloud

As XM Cloud is sort of a SAAS solution there is some discussion about the fact why people would install it locally and it does make sense not to do is - but I was in test and mess-around mode so let's do that on a local setup (just because we can).

As I'm no expert (yet) in containers nor nextJS and such, I was looking for a simple way to do this. With the information I gathered during various sessions about XM Cloud, that should be possible.

The setup 

I found a blog post from Serge van den Oever who already succeeded in such a setup and documented it very well - thanks Serge for the very informative blog.

The setup seemed to go very well...  it takes a while to download all the images but at the end, I had a site that started and I could create the SXA site. Even the creation of the rendering container went fine - some issues mentioned in Serges post seem to be gone, some are still there. But I ended up with a running environment. 

Even Headless SXA worked. So the issues I had on my local XM were not present in this XM Cloud version. Hooray, cheers, all happy...   so why am I writing this post?

The issue

Of course, there had to be an issue. The next day the containers wouldn't start anymore. The solr was going crazy and that means nothing works.  Well in fact, the solr-init won't run because the solr isn't healthy. 

I started two tracks: as I had another laptop I tried the same installation there.. and at the same time started searching on Sitecore StackExchange, Google...    The second installation on the other laptop worked. Once 😞  The result was the same: solr-init would fail when trying to restart the containers. 

In the meantime my search quest led to a blog post from Jeremy Davis that actually didn't sound very hopeful - as you can read in his blog he had the same issue with Sitecore containers (not XMCloud) and already tried several things. So I was not going to try all of those again, but on my machine his workaround "docker network prune" didn't work.

But he does also mention an alternative provided by Rob Ahnemann. So that is a third Sitecore MVP bumping into the same issue 😨  Rob notes that the issue could be solved by removing the Zookeeper - so actually using Solr standalone instead of SolrCloud. This sounds reasonable, but we would need a change to the solr-init. As I'm no Solr expert (and neither a container expert) I'm very glad Rob provided us a full fledged solution on docker hub. 

So, let's try this. If you want to do this as well, read his post to understand the options for the solr-init image. His example is for XM - so we have to make a few small changes to get this working for XMCloud. It will result in a solr-config yml section like this:
solr-init:
    isolation: ${ISOLATION}
    image: rahnemann/solr-init:1.0-ltsc2019
    environment:
      TOPOLOGY: xm-sxa
      SITECORE_SOLR_CONNECTION_STRING: http://solr:8983/solr
      SOLR_CORE_PREFIX_NAME: ${SOLR_CORE_PREFIX_NAME}
      ADDITIONAL_SITECORE_CORES: _horizon_index
    volumes:
      - type: bind
        source: ${LOCAL_DATA_PATH}\solr
        target: c:\solr
So we are using the image from rahnemann here, we kept the topology xm-sxa as that fits our purpose but we have to add an additional Sitecore core for (oh boy) "Horizon". This is the Pages editor (which is not Horizon, but actually is).

You will also need to change the solr mode and the solr connectionstring:
solr:
    ...
    environment:
      SOLR_MODE: standalone
cm:
    ...
    environment:
      ...
      Sitecore_ConnectionStrings_Solr.Search: http://solr:8983/solr
    ...
After applying these changes, I can now run the containers again. More than once. 

It doesn't feel like a very decent solution. And I guess lots of people will not have these issues - but as some people did and blogged about it I would also assume there are more out there who actually do bump into this and maybe this post about my experience can save you some time of you do.