Docker made docker-compose v1 obsolete a while back and the deadline for deprecation and removal from the Docker Desktop application is closing in. Versions released after June 2023 will no longer support docker-compose v1, which has been used in Sitecore and community repositories as local development setup examples for a while. It’s time to get “older” solutions upgraded!
However, I’ve hit a few additional gotchas with some solutions that hopefully will avoid some googling or politely asking ChatGPT. Not all are specifically docker-compose v2 related, but snags we hit across teams when carrying out the upgrades.
Sitecore provide a number of examples (https://github.com/Sitecore/container-deployment) of implementations using containers via Kubernetes and docker compose. All examples utilise a reverse proxy for ingress (be it via traefik or nginx in the k8s examples) to access the cd, cm and id services. All of the examples terminate TLS at the reverse proxy. By default each service is running on port 80, with no TLS encryption between the reverse proxy and the service container . This is a common approach for container based deployments that remain in a secure LAN (ie. in cloud native deployments). However, does raise eyebrows with security teams that may not have extensive in these sorts of environments or with rusted on control requirements.
Recently I presented “The incremental path to Jamstack” at Sitecore Virtual Developer Day (VDD). This was a topic I had first presented a while back, but as always it evolved as I dug into it more and ended up building a full demo as a walkthrough. The session synopsis was:
This session aims to give developers a better understanding of why and how to start moving down the path from legacy MVC applications to the new world of Jamstack sites, without rebuilding from scratch. I’ll take a look at the advantages of Static Site Generation and composable applications and how this fits in with the direction of Sitecore’s latest product suite. Of course I’ll demo some of the new features and tools provided in Sitecore 10.2 that help developers incrementally migrate from Sitecore MVC to a modern Next.js application.
This presentation will be full of demos, code and practical tips to help developers better plan their journey into the modern composable DXP world, in a sustainable and incremental manner.
This session (and all others at VDD) has now been published on Youtube, so feel free to check it out and get in contact if you have any questions.
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.