Goodbye z.Last – Custom Sitecore Config Patch Folder

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…

sitecore-custom-configreader

Oh hello! This makes it ripe for overriding now…

Create a custom class, override this method and add in your own custom directory anywhere. Then update the type in sitecore section in the configSections at the top of web.config to point to this class.

Bingo!

On application start-up the default Sitecore configs will be patched in from /App_Config/Include and then your own custom folder. Not really a big whoopee but hey, keeps those folders a bit cleaner and one less default Sitecore folder in our solutions.

As an added benefit, a watch is kept on this folder, just like the default config folders, so if anything changes then the application is restarted.

No idea when this was changed, but it’s there in Sitecore 8.1 Update-3

UPDATE

I’ve had an additional thought about this. If you change the ConfigReader to your own implementation, then most likely the offline Sitecore Config Builder will not work correctly since it will not take your custom folder into consideration. The source for the module is available, so it should be easy enough to change though. Sitecore is looking at something for the future, so there is some longer term hope. In the meantime, this was a POC and a PSA, so as always use at your own risk.

Advertisements

4 comments

  1. mursino · October 20

    My colleague actually posted a solution just like yours that takes advantage of this: http://www.rockpapersitecore.com/2016/08/10/deferring-config-file-load/

    His approach was to expose an opt-in config file where you decide to defer configs from loading, regardless of alphabetical sequence. If Sitecore can change their native config reader to provide something like this, then it becomes opt-in and not required.

    Thanks for sharing your post, I wasn’t aware of the original static method.

    • jammykam · October 21

      Thanks for sharing Mark. A little to off the Sitecore piste at the moment for my personal taste, but an interesting approach. Maybe in the future Sitecore will look at something like this.

      I’ve added an update to the post about the Sitecore Config Builder, which would equally apply to that post as well.

  2. Pingback: Sitecore setup considerations – The dev Shack
  3. Dheeraj Palagiri · December 14

    Nice one!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s