Re-organisation of Include Config Patch files in Sitecore 8

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.

Sitecore 8 Include Folder

So why the changes from the previous way of including everything in web.config? Possibly to follow their own practices, also it allows them to individually develop different areas of the platform as Pavel mentioned in his post. Another reason could be the the already gargantuan size of the config. For Sitecore 8, the web.config file is now 238kb by default. The /App_Config/Include folder is a huge 952kb (197kb of which is disabled). Take into account that there is a 250kb size limit for web.config in IIS by default (more here and here from a quick Google) and it makes even more sense why they have to go down this route. Personally I like this approach, it makes the system more modular but it does put more reliance on Sitecore Rocks or showconfig.aspx to figure out the final expanded config rather that looking in a single config file (no big deal, I think we are all pretty much used to dealing with it this way by now).

So what’s the big deal? Previously most of us would have named our config patch files zProjectName.config to ensure it was included after everything else in /App_Config/Include. Then we were able to use a folder instead (e.g. /App_config/Include/[ProjectName]) and name our files whatever we wanted.

So now due to these new Sitecore folders, if we need to patch any of those files we have to ensure that our files are included last. Which means putting them in another folder after everything else. Since there is an XdbCloud folder it only leaves us y and z to play with 😦 Therefore it will mean going back to what we used to before and adding our configs in a folder called z.ProjectName. I mentioned this as a potential “issue” at the Sitecore MVP meeting back in September 2014 in Barcelona when discussing configuration, I even seem to recall using xDb as the example for the potential issue.

There is nothing wrong with this, needs must, but it still feels dirty.

Alternatives?

I can’t think of a good one, please post a comment if you have a different solution. It would be better if Sitecore had:

  • Put their config folders within a single folder of their own under /App_Config/Include
  • Added a config setting allowing us to specify a location where our custom files are located
  • Move all default Sitecore configs to a different location

All, or some, of the above should be pretty easy to achieve. The config loader method in Sitecore.Configuration.Factory already loads config from multiple folder locations:

private static void LoadAutoIncludeFiles(XmlNode element)
{
  Assert.ArgumentNotNull((object) element, "element");
  ConfigPatcher patcher = new ConfigPatcher(element);
  Factory.LoadAutoIncludeFiles(patcher, MainUtil.MapPath("/App_Config/Sitecore/Components"));
  Factory.LoadAutoIncludeFiles(patcher, MainUtil.MapPath("/App_Config/Include"));
}

I have no idea what is supposed to be located in /App_Config/Sitecore/Components, this folder does not exist on any clean install of Sitecore for me. But the potential is already there. I couldn’t find a specific pipeline that the Sitecore config is loaded from, and since the above method is a private method anyway we can’t override it.

So ideally Sitecore could update that method and re-organize config files with something like the following:

  • /App_Config/Sitecore – Default Sitecore configuration files
  • /App_Config/Modules – Config files for modules, like from the Marketplace, for use by module developers.
  • /App_Config/Include – User specific patch config files, allowing us to patch both the above.

And while we are at it, let’s move the Sitecore and log4net sections to their own files already and make that web.config file a little more sleek!

Let me know your thoughts, if you have anything to add or have a better solution.

Advertisements

8 comments

  1. Nona Durham · December 24, 2014

    Hi Jammy, so have you run into issues with your custom patch configs loading before other system configs?

    • jammykam · December 24, 2014

      A long time ago, yes! But once you realise the patches are included alphabetically it is easy to work around. Read my previous post on configs, they are added in first by all the files in /Include folder then it traverses each of the subfolders. I don’t have any production experience in Sitecore 8 yet, and for now a folder called “zSomethingOrOther” will be sufficient to ensure my configs are patched in last. I’m hoping there was a “nicer” way.

      • Nona Durham · January 2, 2015

        I understand now. Yea. I completely agree this could start to become a problem.

  2. Kris Verheire · January 5, 2015

    This does indeed feel dirty. Changing it into y or z feels like patching up a workaround solution.
    It would indeed make more sense if all the default Sitecore configurations were put together in one location.
    Actually the best solution in my opinion would be not for us to agree on a good convention needed for the configuration file, but rather for Sitecore to have their own convention.
    Let’s say sc-DataFolder.config and let the partner implementers stick to their own approaches

  3. Michael Smith · April 12

    Am I crazy for thinking that alphabetical order just isn’t a good scheme for ordering config files? It makes the order of execution dependent on something that’s completely irrelevant to it (what the file happens to be named). I think it’d make more sense to have either a separate file where you list all of the configs in the order you want them executed or simply allow some way to declare patch order when it’s necessary (like new value).

    Apologies for dredging up an old post, but it happens to be what I’m looking into at the moment.

    • jammykam · April 12

      It works ok once you figure it out, but the explosion of the folders does make it more tricky. But generally agree with what you are saying. I have raised a User Voice request for an additional folder (or set of folders) that would at least allow us to separate out Sitecore vs Custom configs to make it easier for us to patch in last.

  4. Pingback: Goodbye z.Last – Custom Sitecore Config Patch Folder | jammykam
  5. Pingback: Helix: Patching your Config Patches for Specific Environments | jammykam

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