I recently wrote a detailed post about all the config changes in Sitecore 9. I highly recommend taking a read if you have not done so already.
I suggested in that post that we could introduce custom configuration roles in order to allow us to configure specific settings for different environments, such as UAT or Pre-Prod for example. After a conversation with Alen Pelin he told me of a much better way to achieve this, which is both cleaner and semantically more correct.
I assumed there was something hardcoded in code to worked against specific AppSettings keys during the patching process. Turns out there is way more magic happening here than that – we can define whatever keys we want and follow a convention to have those applied. Looking at it again and with this additional info, it turns out this is exactly the same as how the configuration works to switch search providers.
I’ve previously written several posts on Sitecore Configs. Well Sitecore 9 just landed so it time for a big update! This is not going to get your marketers all giddy but will certainly make all you developer and developers super happy.
Over the years the number of configs in Sitecore has grown and grown and grown. Then so did the number of folders. Sitecore has a new trick up it’s sleeve to clean this all up.
What’s new? Rules Based Configuration.
It’s a new configuration approach designed to drastically improve how server roles are configured and how all the config files are now organised, making it both easier to manage and deploy.
Following a conversation on the #helix-habitat channel over on Sitecore Slack Chat a few days ago, I thought it would be worth penning a quick post…
A question was asked about “How to organise your CM vs CD config in a Helix Solution”. This was about configs in your specific implementation, not the default Sitecore configs that need to be enabled or disabled for a specific Sitecore environment.
For example, you may have some specific custom pipelines or event handlers that should only run on the CM instance.
Some suggested that these custom configs should be enabled/disabled/modified as part of the deployment process using PowerShell, possibly using an XML file which provides a mapping of files for the environments. This could then be maintained by the developers.
I suggested a different approach, and “tagging” your config nodes to make them easier to patch… The approach was new/unknown to some so I thought I would (re)blog it.
I’ve previously written a couple of blog posts about Organising your Sitecore Patch Include Files and the subsequent Re-organisation of Include Config Patch files in Sitecore 8. As mentioned in that blog post, in order to ensure that our custom configs are patched in last we can place our own files in
/App_Settings/Include/z.Project. I also raised a Sitecore userVoice request to add additional folder locations for patching.
Recently when providing an answer on Sitecore StackExchange about alternative ways of disabling config files and taking a peek inside the Sitecore.Kernel to post some code for the answer I noticed something…
If you looked at the code snippet in my original post then you would have noticed that the method was
private static 😥
Something had changed…
Read my previous blog post about SEO Friendly URLs? Go have a read, I cover several methods of achieving SEO Friendly URLs.
Did you read it? Did you read that part about
encodeNameReplacements? Yeah, I still don’t like them, but it seems like now we all have to deal with them at least.
I previously wrote about Organising your Sitecore Patch Include Files, a simple way to ensure that your own patches to Sitecore configuration is included after any other Sitecore patch files. Generally, my preference has been to put all my custom config in /App_Config/Include/[ProjectName].
Just in case you have been hiding under a rock for the past few days, Sitecore XP8 was officially released a few days ago, bringing with it a whole heap of amazing goodies.
It also looks like Sitecore is eating its own canned soup and has started to patch in their own updates, which matches the /bin folder explosion. A post from Scott Mulligan this morning got me to take another look.
tl;dr Putting config files in a folder under
/App_Config/Include causes them to be patched in last.
Following an answer by @Bruud on Stackflow a few months ago I found out that it is possible to organise patch config files much more neatly. It was also mentioned as a passing comment on one of the recent Google Hangout highlighting the changes in Sitecore 7.X.
I’ve just started working on a few project from existing vendors and noticed the common patch file naming convention to ensure custom changes are applied after the standard Sitecore configs in
It turns out that you can simply put your custom configs in a child folder and Sitecore will include them after any files in