During testing for an upgrade to 10.2 of a JSS implementation recently we identified that some of our connected GQL calls were failing when running locally in the client due to CORs issues.
Access to fetch at 'https://mysitecoreinstance.com/api/my-web-gql-endpoint' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.
Note to future self. RTFM and use the packages you are told to install. Recently in my haste to upgrade some SIF scripts and an older implementation to 10.2 (JSS & SXA), I downloaded all the relevant resource packages from the Sitecore download pages & SPE from Github and got to installing. All looked to be well, but noticed that some of the SXA features appeared to be missing, such as the SXA Site manager.
Sitecore 10.2 ships by default with Sitecore Identity Server 6 which has a dependency on NET Core 3.1 and related assemblies. As with previous versions it can easily be supported (in parallel with previous versions) by installing the NET Core 3.1 Hosting bundle.
RAZL is a really handy addition to a Sitecore developers toolbox. It allows for content comparison and sync between environments. Great for pre-production environments where you need to “refresh” some content or get a brand new environment up to date with the latest stuff your content producers have been working on. Razl v5+ also offers powershell scripting, so you can easily sync the same items across many environments ….it’s handy. But it can be challenging to deploy in a repeatable way when not using containers, due to it’s installation method and security model.
If you’ve ever upgraded a Sitecore project, you’ve experience the joy of trying to search and replace all of the nuget package versions in the Package references of csproj files. Invariably these are scattered throughout the tens (hundreds?!) of projects in “Helix” based solutions, so can be time consuming and error prone to repetitively upgrade the package versions. Wouldn’t it be great if all package versions could be managed in one place?
There has been a lot of discussion lately about Core Web Vitals CWV, Measuring User Experience and how this relates to SEO and website performance. At a recent Perth Sitecore User Group I dug into what CWV are, what they are trying to achieve….and busted a few myths along the way. I explored some of the tools to help measure and improve your CWV, how to better interpret them (100 Lighthouse score is not the be all and end all!) and what that REALLY means to your SEO with Googles more recent changes.
Recently I joined Nicole Montero on the Core sampler podcast in an episode of “Get to know an MVP” to talk about getting involved in the community and being a Sitecore MVP. Unfortunately I was quite sick at the time, but it was a fun to share my experiences and something that forced me to reflect on not only my achievements but the achievements of the community as a whole. Well worth checking out many of the great episodes, which are all listed here on the Sitecore MVP website.
Recently I had a requirement for the following scenario, which at first seemed straight forward, but ended up needing a little more work than expected!
On an existing mulitsite XP SXA/JSS install I needed:
2 sites to share an analytics cookie for cross site tracking of contacts
EG. Sites with the following hostnames abc.site.com and def.site.com should share the same SC_ANALYTICS_GLOBAL_COOKIE cookie by setting the cookie domain to .site.com .
Other sites to just use their default hostname for the analytics cookie.
In simpler scenarios there is the option to just change the Analytics.CookieDomain setting in config to the appropriate domain, however, this applies instance-wide and there is no OOTB provision to do this on a site by site basis. Using this method I couldn’t ensure cookies would be set on the correct domain for .site.com and my.example.com
Just before the Turkey and Christmas induced coma at the end of last year, I presented to the Perth Sitecore User Group on the evolution and future of Headless architectures in the Sitecore ecosystem. We explored some of the history, a glance at current offerings in Sitecore 10 and a glimpse into what the future might look like with Static Site Generation (SSG) and Experience Edge.
In a previous post I wrote about extending the JSS Layout service to support serialization of field types that aren’t serialized OOTB, like the Multiroot treelist added by SXA. Catch up on that post here. That was great, but there is a little more to ensure those field types are also mapped and serialized by GraphQL queries.