Anyone who's been doing Sitecore DXP for a while will be fairly comfortable with Solr and how search works under the Content Search APIs. But if you're moving to the newer SaaS products then you're not working with that any more. And getting started with Sitecore's SaaS Search product does involve learning a few changed concepts.
Here are four quick things they tell you that you might not have thought too much about, but you need to remember to help avoid project surprises...
For a long time a small thing in writing Razor code for Sitecore (and in some other places) has irritated me. It's not really very important, but with the new version of C# there is finally a way to round off this rough edge that's been getting to me...
I got asked for help with an issue in some QA test the other day, and it struck me as a fun one that others might encounter. A nice little side effect of how literal computers can be...
Sometimes it's the simplest things that can trip up development work. A case in point is a bug ticket I got handed recently, which I think shows the need to understand your tools when writing code. Read on to avoid an interesting mistake with code flow in Razor views...
I was doing some investigation into moving some Experience Forms UI over to the new SaaS Forms in XM Cloud recently, and bumped into an interesting issue. If you're looking to make use of this new tool you may find this an interesting read:
A while back, work moved from having a traditional domain-joined laptops and an on-site Domain Controller for our Active Directory to the more modern SaaS model of cloud domain. Mostly this doesn't matter at all to employees as they work. But I bumped into one place where I do need to do something different because of this: setting explict disk permissions. So as a reminder to myself for next time, here's how to achieve this.
I've been tinkering with some pipeline modules for the Statiq generation engine that I use to render this blog, and I bumped into a fun mistake in my code which confused me for a while. To help me next time I'm doing this sort of modification, this seemed worth documenting - even if it is a bit of a silly mistake...
A common but not-fun issue for working developers is when you do some work, test it locally, submit a PR and then find that it blows up on someone else's computer. I'm not too proud to admit that I had an issue with this recently, which highlights a thing you have to remember when working with Sitecore Content Serialisation.
One of the fun things about defining objects and their APIs in C# is thinking about which bits you want your consumers to see, and which bits need to be there just for you, and consumers should avoid using. Most developers are aware of keywords like
public
/
private
and
internal
for achieving this, but Explicit Interfaces are another approach to this...
An issue that crops up fairly often in web agency work is that you have to work on code for older versions of Sitecore. Most of the time this is fine, but sometimes in between the Sitecore version getting released and you doing this work, stuff changes in Windows that makes this setup harder than it should be... This has been a challenge recently as some of my fellow developers now have Windows 11 on their laptops, and they're having to work on Sitecore 10.2 projects. And out of the box, SIF or SIA won't install in that scenario these days. Having had to help a couple of people with these issues recently, I figured it might be worth automating the fixes with some Powershell, so it's easier in the future. And maybe that automation might help you?