Jeremy Davis
Sitecore, C# and web development
Data Template inheritance. Most of the time it's great and a powerful tool to help you define your content schema effectively. But there are a few places where it can trip you up - and one of the interesting ones is duplicated field names. I found myself chatting about what actually happens and how this might affect PowerShell scripts and headless code recently, and it seemed worth writing down...
With all the excitement about containers and SaaS and the like, it's been a while since I've spent time worrying about local Solr installs. But recently my good pal low-effort Solr Installs" script doesn't work with recent Solr releases. So I figured I should fix that, because it's clearly still useful for some people...
I was asked to do some configuration on a remote computer recently, and discovered that the security-concious network admins had locked down the ability for me to share my local computer's files with the server via RDP and the ability to get to services like OneDrive. I had a collection of config files I had been asked to deploy, and manually creating each file on the server and copying over its contents seemed like a lot of hassle. So I tried a trick with PowerShell to make my life easier...
A couple of times recently, I've found myself needing to deploy files that come wrapped in a
.tar.gz
archive onto servers. On your desktop that's not too much of a problem – you just run the installer for your preferred
3rd party tool, or maybe
use the new Unixy shell
and you get on with it. But on client servers security can be higher and you don't always get the option to run any old installer. So I needed an alternative...
Sometimes the learning point from working on a misbehaving Sitecore server isn't related to the CMS. Recently I learned something useful about Excel while I was addressing some other issues. Not sure if this is "so trivially simple I'm just the last one to realise" or whether it's a really useful bit of trivia – but just because someone else might benefit:
Continuing my voyage of obscure-error-discovery around Sitecore 9, this week SIF has been putting a lot of red into console windows for me. I'm not sure how many people will have this scenario, but if you have multiple people who all need to install their own Sitecore 9 instance onto one machine, this may be of interest:
It's a pretty common requirement that deploying instances of Sitecore will require slightly different configuration on different servers. Different roles, like content management and content deployment, will require different settings and features to work. So it's not surprising that there are a variety of approaches to how you manage this configuration in your projects.
In the past I've often made use of separate config files, where you have a file for "config changes needed on all servers" and then further files for "config changes needed for CM servers", and even down to the level of "config changes needed on server CD01" if necessary. This works fine if your deployment process understands which files should go on which servers.
Recently, however, Sitecore have started to offer a "role based configuration" approach in the configuration of v9 – so you can deploy a single config file and the server can pick and choose sections of its configuration based on what role it is performing. But back in the real world, most of us are still supporting V8 (and older) sites, so is it possible for them to adopt something similar to this idea? Here's one approach that achieves something similar:
I've been doing some work with Release Management in Visual Studio Online recently. Overall it's been a pretty positive experience, but there was one face-palm inducing moment I came across which needs writing down so I don't fall into the same trap next time I have to do this. When you're working with local release agents, you mustn't forget the security settings that your agent's server is configured with...
A challenge I've come across a number of times while working with PowerShell scripts for Sitecore is that scripts sometimes have other files they depend on. Making sure that your scripts and their dependencies stay in sync can be a challenge at times, especally when scripts get reused across an organisation. So what approaches can you use for this?
There's been a bit of a theme in my recent posts about scripting stuff, and that continues this week. I've been looking at some ideas for automating tasks for developers recently, and one of the things I was interested in was being able to get stuff downloaded from dev.sitecore.net without having to do it manually. So, here's some PowerShell that can help you with that...
