Sitecore SXA - XP navigation bar site resolving

Sitecore Experience Editor - navigation bar site resolving issue

Situation

We inherited a Sitecore 10.2 setup with a number of sites created with old school MVC. Nothing really fancy, just a bunch of sites just as many other solutions probably. The setup is a little weird (just as many "inherited" solutions, right...) and the customer is not used to working in the XP editor. 

When we were asked to add one more site, we decided to go for a headless approach and installed JSS and SXA on the environment. This is all working fine - all sites are running fine and I dare to say the new site is much more towards all best practices. And also introducing the XP editor - especially to add new components to a page. With the SXA extensions that is working like a charm.

Although we noticed one little issue. The navigation bar in the XP editor didn't work as expected. 

We can open a page in the XP editor and it works - the url looks like

https://dev/?sc_mode=edit&sc_itemid=...&sc_lang=en&sc_version=1&sc_site=portal.

But when we then use the navigation bar to go to another page we get an error because the sc_site parameter in the url is wrong:

https://dev/site1/?sc_mode=edit&sc_itemid=...&sc_lang=en&sc_site=site1&sc_ee_fb=false.

When we manually change the sc_site parameter back to "portal" it works. It seems that it takes the first site in the site definition list.

Site configuration

First thing to check is the site configuration. That seemed to be fine - we also checked the SXA Site Manager and that as well was all ok. 

Note here that the mvc sites are in the config (files), the SXA site is configured in Sitecore (items). This makes is tricky to order them.

There is a SiteResolving config section from SXA where you can add sites that should be resolved after the SXA sites. Just to be sure we added all sites to that list in the config:

<siteResolving patch:source="Sitecore.XA.SitesToResolveAfterSxa.config">
  <site name="exm" resolve="after" />
  <site name="website" resolve="after" />
  ....
</siteResolving>

When all sites are added you can see in the SXA Site Manager that the SXA site moved up and that is now our first site.

Unfortunately, that didn't solve our issue. The site resolving in the navigation bar is still wrong. 

The solution

We contacted Sitecore Support. I thought about trying to find the responsible code to see if I could fix it myself - didn't do that as it would take too much time for something that is not convenient but also not blocking. 

And finally none of those options solved it, but well - let's call it luck. I can't remember why I decided to add a targetHostName in the site definition of the new SXA site. But I did - and actually that fixed our issue. The site resolving is working fine now.

We still don't know exactly why and don't want to spend time searching for a root cause but it is solved and might solve a site resolving issue for you as well. If anyone would know the root cause, please do share though.

Sitecore EXM - issue with long name emails

 Sitecore EXM - emails with long names

Our customer is using Sitecore Email Experience Manager to send campaigns (e-mails) to their contacts.  We got notified that they had an issue with a specific campaign that was not sending. 

First of all we noticed that the email was completely blocked in the EXM management tool. We could not de-activate it to try to change anything which was pretty weird. Luckily the logs showed us some meaningful information.

ERROR Exception: Sitecore.Exceptions.InvalidItemNameException

Message: An item name lenght should be less or equal to 100.

Source: Sitecore.Kernel

   ....

   at Sitecore.EmailCampaign.Cm.Pipelines.DispatchNewsletter.DeployAnalytics.AddCampaignItem(MessageItem message)

 

An item name lenght should be less or equal to 100

Yes, item length - that is the issue. (including the typo in the exception message 😊)

But what item name? Yes, the name of the email was long, but not that long. EXM does check the length of the name - just try to type more than 100 characters in the name field of a new regular mail and it will turn red. 

Let's have another look at the trace in the error message - it seems to be from "AddCampaign" and that rings a bell. When a regular email is created, Sitecore also creates a campaign item in /sitecore/system/Marketing Control Panel/Campaigns. When we check the names of the items there it seems to be the name of the mail campaign with the item id (guid). This means that this item is 36 characters longer than the mail name - leaving us with only 64 characters for the mail name. 

Which is fine - if you know it. And yes, that should be checked in EXM. You can consider this a bug -it is- but I'm not going to patch a solution for it. 

Fix ?

We could try and patch it ourselves, but it's actually not worth the effort. We could also increase the MaxItemNameLength but again - don't seem worth it. Note that we are talking about the name of the mail campaign, not the subject or anything the end customer would see.

So we decided to just fix the impacted mail and inform the customer to use shorter names in future (until we move the solution to Sitecore Send 😛)

Fixing locked mail items

Fixing the item seemed to be not that easy actually as it was really locked. I could not deactivate it to edit it. An old trick to the rescue, described on Sitecore Stack Exchange (of course... ) in another situation but still very useful. 

Go to the content editor and locate the mail item. Unprotect it and make the changes you want - in this case shorten the title.  Protect the item again - use the "Open EXM" button to go to the item where you now can de-active and activate again.  And that should fix your mail.

Conclusion

One more reason to start moving the mail part of the solution to Send...

Sitecore SXA Responsive Image - null reference

 SXA Responsive Image null reference issue

We recently faced an issue on Sitecore SXA with the Responsive Image component. Our customer informed us that if an image was not published pages containing that image would be broken. And not just missing the image - but actually broken. 

The site is running on Sitecore 10.2 using SXA - and the site is patched with the latest hotfix packages so actually running on 10.2.1 (and even 10.2.2 now). On the broken pages we had renderings that use the ootb Responsive Image rendering variant. So it was clear that the issue was with that component.

In the release notes for version 10.3 we found the matching bug: 

If a Responsive Image variant field points to a broken link, a NullReferenceException error occurs.

Upgrading is 10.3 is not an option. So let's try to fix this ourselves. I found the issue in the class Sitecore.XA.Feature.Stylelabs.Pipelines.RenderVariantField.RenderFallbackResponsiveMImage which came with the 10.2.1 update. The RenderField method in that class uses a function called StylelabsDataExtractor.GetSrcAttributeValue. That is weird as this one is deprecated in 10.2 and it mentions to use the new function GetAttributeValue. When I tried the same code with that function the error was gone. 

So let's recap that and show the code you need.

using System.Web.UI;
using Sitecore.Data.Fields;
using Sitecore.Data.Items;
using Sitecore.Web.UI.WebControls;
using Sitecore.XA.Feature.Stylelabs.Services;
using Sitecore.XA.Foundation.Variants.Abstractions.Pipelines.RenderVariantField;

namespace Foundation.Infrastructure
{
    public class RenderFallbackResponsiveMImage : Sitecore.XA.Feature.Stylelabs.Pipelines.RenderVariantField.RenderFallbackResponsiveMImage
    {
        public RenderFallbackResponsiveMImage(IStylelabsDataExtractor stylelabsDataExtractor) : base(stylelabsDataExtractor)
        {
        }

        public override void RenderField(RenderVariantFieldArgs args)
        {
            var variantField = args.VariantField;
            if (args.Item.Paths.IsMediaItem || string.IsNullOrWhiteSpace(variantField?.FieldName))
            {
                base.RenderField(args);
            }
            else if (PageMode.IsExperienceEditorEditing)
            {
                args.ResultControl = (Control)new FieldRenderer()
                {
                    Item = args.Item,
                    FieldName = variantField.FieldName,
                    DisableWebEditing = !args.IsControlEditable
                };
                args.Result = this.RenderControl(args.ResultControl);
            }
            else
            {
                var field1 = args.Item.Fields[variantField.FieldName];
                if (field1 == null)
                {
                    return;
                }

                if ((FieldTypeManager.GetField(field1) is ImageField field2 ? field2.MediaItem : (Item)null) == null)
                {
                    field2 = (ImageField)field1;
                    string srcAttributeValue = this.StylelabsDataExtractor.GetAttributeValue("src", field2);
                    Control fieldRenderer = this.CreateFieldRenderer(args);
                    this.RenderControl(args, fieldRenderer, srcAttributeValue);
                }
                else
                {
                    base.RenderField(args);
                }
            }
        }
    }
}

Note the usage of this.StylelabsDataExtractor.GetAttributeValue("src", field2);

To get this code working instead of the original one we can patch the configs and insert this into the dependency injection:

<sitecore>
  <pipelines>
    <renderVariantField>
      <processor patch:instead="*[@type='Sitecore.XA.Feature.Stylelabs.Pipelines.RenderVariantField.RenderFallbackResponsiveMImage, Sitecore.XA.Feature.Stylelabs']"
				type="Foundation.Infrastructure.RenderFallbackResponsiveMImage, Foundation.Infrastructure" resolve="true" />
    </renderVariantField>
  </pipelines>
</sitecore>

That's it. Don't forget if you ever upgrade to remove this code of course. 

SXA duplicate main placeholder

Sitecore SXA & the main placeholder mystery

It sounds like a fairy tale and it almost was but a few hours were lost on this mystery so maybe writing this down can save someone some time in the future. 

What happened? We installed SXA on a XM environment with an already existing site (not using SXA, just a plain old MVC site). The idea was to use SXA for future sites that are being build on the same environment. But of course, we had to test if the current site was still working with this new framework installed.

The first tests seemed fine. The existing site was still working and we couldn't find any issues in the logs. But then we noticed that one placeholder was not working anymore in the Experience Editor. The site had a placeholder called "main" (as many sites probably do) which the editors will mainly utilize when creating new pages. The issue stayed under the radar when editing existing pages or even adding some new components as those are usually put in other placeholders.

So we faced an issue with the "main" placeholder. The person debugging this had knowledge of the current implementation but no real experience with SXA and was a bit lost. Although if you looked carefully at the placeholder definition item, Sitecore did give a pretty decent clue: 

Duplicate placeholder keys

Sitecore is telling us here that the key value should be unique. Which make sense of course. So we have to find out why this is suddenly happening and of course we should look into SXA. And yes, SXA als has by default a main placeholder for the MVC version: /sitecore/layout/Placeholder Settings/Foundation/Experience Accelerator/MVC/main.  As we have will only be using the headless version the easy fix was to change the placeholder key in this SXA item. 

Note that other placeholders keys are added as well, like header, footer, head...  so you might encounter this issue on those as well.

It appeared to be an easy fix for a trivial issue, but for those who are not acquainted with SXA this hopefully helps if you ever face this problem.

 

Sitecore Powershell Extensions - Elevated session state issues

 SPE - Elevated session state issues

Some time ago I faced a very weird issue on a local setup of Sitecore 10.2 which includes the wonderful Sitecore Powershell Extensions (SPE). I wanted to run a script and SPE requested elevated session state. As you probably know is you have been using SPE already this happens (quite often) and requires you to provide your password again.

The problem was that in my case my password didn't work. Although I was sure it was correct. I could use the same password to login in Sitecore. I had this issue only on my local environment, not on any other test or production environment.

So I started my investigation that actually surfaced a few things so it might be worth putting this in a blog post.

SPE identityserver config

First of all, make sure the necessary config file is present and not disabled: https://sitecore.stackexchange.com/a/28255/237. In "\App_Config\Include\Spe" rename Spe.IdentityServer.config.disabled to Spe.IdentityServer.config. And restart.

This didn't fix my issue though and then I bumped into some configuration that could disable the request for elevated session state. Normally I would never consider this, but the problem was only local so it might be worth doing - but my curious mind wanted to fix the issue instead of putting it aside. 

Disable elevation

If you do want to tamper with the elevation requirements, check the "App_Config\Include\Spe\Spe.config" file and find the following entries: 

<token name="Default" expiration="00:00:00" elevationAction="..."/>

<token name="Console" expiration="00:05:00" elevationAction="..."/>

<token name="ISE" expiration="00:05:00" elevationAction="..."/>

<token name="ItemSave" expiration="00:05:00" elevationAction="..."/>

To disable the requirement, put "Allow" in the elevationAction.

But as mentioned we continue to solve the issue properly. I can't remember where I actually got the idea to verify the SHA settings... but that was next on the list.

SHA - the hash algorithm

I hope you do know you can (and should/must) change the hashing algorithm on your site. This is explained in https://doc.sitecore.com/xp/en/developers/latest/platform-administration-and-architecture/change-the-hash-algorithm-for-password-encryption.html.  

To do so, you need to update two files. The web.config file in the website needs an updated hashAlgorithmType setting (eg to SHA512). And if you use Sitecore Identity, you must also change the algorithm on the Sitecore Identity server. 

And apparently that was my issue. On the local environment I had no automated publish towards the Identity Server and so the hash algorithm was not changed there. I still think it's pretty weird that I could login to Sitecore with those settings but well.. I did. It's only when using SPE that this turned into a problem. Settings the hash to the same value as in the web.config fixed it all.

Conclusion

If you run into issues with elevated session state login:

• check the SPE config folder if you have all necessary configs enabled
• check whether the hash algorithm on the site and on the Identity Server are the same
• check if your user is not locked (after a few failed attempts that might happen ☺) 

And if needed, you can also disable the elevation although I would not recommend doing so.

Sugcon 2023 - Composable in Malaga

 Sugcon 2023

Better late than never..  a post about a really very good edition of Sugcon. I had my issues getting there but I'm glad I did. Meeting the people from the Sitecore community again in person was really good and we had some good talks, laughs, kebabs and a few drinks.

This year we gathered in Torremolinos (Malaga - Spain) at the Melia convention center. We've had worse locations than this ☺

It didn't take that long to find the rooftop bar(s), the local kebab within walking distance of that bar, the beach for a morning walk...  and of course: the people - our precious Sitecore community. Networking is a part of such a conference that you should not underestimate. And when you have been around for a while as I am you start getting to know a few people.

But we are also gathered here of course to learn something. To get some new insides,  hear from Sitecore what is on their table and from community members what they have achieved or are struggling with. I was glad to do my part in this by speaking about composable and customers.

The Sitecorians

Let's see what the people from Sitecore had to tell us. Of course new features and such - and if you are interested in those you will also be interested in the rather new changelog which can be found on https://developers.sitecore.com/changelog. 

Dave O'Flanagan was the first one to give us some sneak peaks about what they are working on. 

Components was mentioned and did get it's own session later one. They also seem to be working on a complete revamp for the content editor in XM Cloud (Explorer) and a new Forms module is in the making as well - although very little details are known about this yet. 

As you might notice, all interesting things are happening in the composable cloudy areas. That is a trend that will not be stopped and which also influenced a lot of the other sessions. 

Let's stick with the red Sitecore brigade a bit. It was very nice to see so many of them present which lead to many good conversations about Search, Horizon Pages, and so on. I do hope that if you were present you also took the opportunity to give and get some feedback in person. But next to that there were some interesting sessions from them as well. To pick a few: Ivan on Sitecore Connect, Sebastian on Components and Bart on Yarp - which is not a Sitecore product but a tool that might help to make the switch to a headless CMS more gradual. 

And we should also not forget the representatives from the Content Hub One team (Ezgi and Hande) who showed us what they did and what they will be doing next. I do hope that localization will be delivered.

 

The community

Sugcon also had many speakers from our beloved community of course. Too many to mention here - and I also couldn't see all the sessions obviously. So I will just name a few that I remember for various reasons so that you might check those when recordings are available or when they are repeated in local user group sessions. 

So in random order:

• Jason Wilkerson going totally hipster with headless SXA
• Vasiliy Fomichev securing a composable setup
• Rob Habraken migrating to XM Cloud
• Timothy Marsh doing amazing things with Content Hub
• and can I mention myself as well? 😊  Selling composable to customers - with a few 🐈🐈 

There were many more - so a big thanks to all of them to be part of this. And all visitors for being there (otherwise there was no Sugcon). And surely also thanks to the organizers.. they certainly deserve their picture here too:

I would also like to mention the more entertaining sessions. 

To be honest when I noticed the closing keynote was virtual I did had my doubts - but Scott Hanselman is an amazing speaker and even remote he managed to entertain and inspire the whole room. 

Entertainment also came from the community... and not only at the bar - although I do think they had a few drinks before going on stage:

 

And that's it folks. Sugcon was great, Malaga was great. Time to go home. Hopefully till next time...

Talking to a typical customer about the road to composable - SUGCON 2023

Talking to a typical customer about the road to composable

I was very pleased to be able to present a new lightning talk at SUGCON this year in sunny Malaga. Where is usually go for technical topics, the idea this year was rather different so I am glad the response was pretty well. I had various good talks afterwards about it so I guess I must have somehow hit a spot. 

And of course, there were some cats 😸.

Description 

We've probably all seen sessions about moving to composable lately and we all know this is the road ahead but how do you talk about this to a customer that is used to his Sitecore editing environment and is sending mails with EXM.

In this talk I will explain how we handled this with a (B2B) customer that has been using Sitecore for over a decade. We brought them a story that (pl)eased them and opened the conversation to start the composable journey together. Taking into account procurement departments, IT departments, business owners and so on. Most of us have learned that for a company that is not willing to take a real big bang (hereby questioning not only products but also vendors and partners) it is not such an easy journey. The example I want to present in this talk is not the biggest customer or the most sexy solution - it is about one of many Sitecore customers that are looking at the future and are not sure what to do.

I'll present the roadmap we gave them - trying to give you ideas and/or open a discussion on how to start the journey for your customer as well.

Presentation @ Sugcon - Malaga March 24th 2023

Video

Videos are still in progress and will be uploaded to Youtube. I will edit this post and embed it when it's available. 

Slides

I can already share the slides - as some people requested them. Note that they don't come with all the animations which makes it less appealing and you'll miss some cats but if you were there you'll get the ideas (again).

Talking to a typical customer about the road to composable @ SUGCON 2023 from Gert Gullentops

PS: if other Sitecore UserGroups are interested, I can present this remotely of you want. That way you do get all the extra fun. Just reach out on Twitter or Slack. It's a "lightning" talk so it takes 15 minutes (well, maybe a minute more) - that is without Q&A... 

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.