Jeremy Davis
Sitecore, C# and web development
I bumped into an interesting issue recently, which I though others might come across. Trying to run a project with Dianoga in it didn't work properly in a developer's Docker container – it kept failing whenever it was asked to process an SVG image. Why didn't that work? Here's why:
I've got a project on the cards where I need to connect both Sitecore and a third-party image capture system to Content Hub. While I've done the official admin & developer training for Content Hub, I thought it would be worth a quick proof-of-concept so that I could verify the plan I had would actually work – and it turned out that there was an interesting issue hiding under this...
It's October – which means we've only got a few weeks until this year's Sitecore Symposium. Are you signed up? I am, and here are some of my reasons why:
I've been spending a bit of time helping out a client who's working through an upgrade project recently, and the work to move from v9.1 to v9.3 raised an interesting issue I wasn't aware of. So in the spirit of making life easier for others, here's what happened:
Ages ago I wrote up a bit about how your public sites should consider implementing Content Security Policy because of all the hacks it can prevent. In a bit of frustrating irony, I was tripped up by a problem caused precisely because Sitecore have added some CSP headers to their own code. Google came up empty on this, so I'm documenting it for the next person who gets bitten.
A while back I wrote about some initial investigations I'd made towards having SolrCloud in a containerised Sitecore instance. Since I worked on that, Sitecore have shipped their "official" container approach, so I've revisited my experiments using the examples Sitecore provides.
Now that Sitecore 10 is out, I've been having a dig into the new Docker approach that's been released. There are some interesting differences here between Sitecore's official approach and the way the community scripts I'd experimented with worked – and I've learned a few interesting new things as a result of having a read of the examples provided. Here are the things that caught my attention:
I've got a project on the cards that I'd like to use docker containers for, but we're talking about using SolrCloud for search. Right now, there isn't a SolrCloud container in the Sitecore community container repo. So I started thinking about what would it take to make one.
We spend a lot of time worrying about the marketing content, and the general website text and images in Sitecore. A lot gets said about patterns for organising that content. But some projects have information that comes from external systems that needs to be rendered on the website. And plenty of sites choose to integrate that into their main content tree. Over the years I've bumped into a few problems because of this – usually because I find myself supporting something where poor decisions were made early in the design process for the integration. So here's some things to think carefully about if you're planning work that relies on back-end data:
If you're looking for the simplest possible developer setup for Sitecore then creating an ASP.Net web project, dropping Sitecore over the top, configuring it for shared databases and checking it in to source control is the answer. Back in the day it was an accepted pattern to to work this way – so you could click "play" in Visual Studio to run your site. And I still find myself workig on projects running that way. But today this is considered a bad idea. So why do I keep finding projects set up this way, and why isn't it a good approach?
