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