Config

Sitecore 9 : Custom Config Roles

Posted on by jammykam

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.

Read More

Sitecore 9 : Config Patches – Layers & Roles

Posted on by jammykam

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.

Sitecore 9 Configuration Management

Read More

Disable Edit and Preview Modes on your CD servers

Posted on by jammykam

A real quick post on something that stumped me and had me scratching my head last week. A colleague mentioned that when browsing the Production site with ?sc_mode=edit appended to the URL then the site would attempt to redirect the user to /sitecore/login page. In some cases it would cause an infinite redirect and cause the browser to throw a “redirected too many times error”.

In and of itself, it didn’t cause any security issues – the CM server was only accessible to our internal network and we had followed server hardening best practices and blocked access to the CMS interface on the CD servers (we actually just return a 404 rather than anything specific related to access denied).

We had also correctly followed the guide to configure a CD server so was pretty sure it was not related to having missed disabling a file.

So I asked on Slack if it was expected behaviour that appending ?sc_mode=edit would attempt to redirect to login page on the CD servers, I would have expected it to do nothing. Having then dug a little into the Context code, turns out there is a setting for this which we had completely overlooked.

Read More

Helix: Patching your Config Patches for Specific Environments

Posted on by jammykam

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.

Read More

Goodbye z.Last – Custom Sitecore Config Patch Folder

Posted on by jammykam

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 More

Redirecting URLs After Major Content Restructure In Sitecore

Posted on by jammykam

About a year or so ago I was working on a project which involved an upgrade from Sitecore 6.4 to 7.0 (the latest version at the time). The upgrade was fairly incidental, the site was (kind of) “working fine” in production. The main reason for touching the codebase was to fix issues due to a poor implementation that was carried out initially, namely:

  • Lack of Page Editor support
  • Poor coding not following Sitecore Best Practices
  • Sitecore section in Web.config modified directly (which made upgrading more difficult)
  • Poorly structured Content Tree
  • Difficulty applying a good security model for multi-site, multi-editor environment

…amongst others. It wasn’t all bad, just some common mistakes made by developers struggling with Sitecore during a first implementation.

One issue was the poorly structured content tree. It seems there was struggle with getting a handle on how to structure content whilst trying to use that same structure to create the navigation menu on the site. They had the usual “Include In Navigation Menu” checkboxes but the navigation structure did not actually completely match the content structure.

Read More

Re-organisation of Include Config Patch files in Sitecore 8

Posted on by jammykam

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.

Read More

Creating Site Specific Pipelines for Multi-Site Implementation in Sitecore

Posted on by jammykam

tl;dr Use the Sitecore Configuration Factory to pass parameters to enable Pipelines to only run for specific sites

I’ve been working on a few multi-site Sitecore implementations lately and the majority of the time most brands within the same company umbrella all want similar functionality, which is very nice and easy for us developers. But as you start to work on larger implementations with different brands it will be inevitable that they all have slightly different requirements.

Pipelines provide us a great way to customize Sitecore, but they run for all requests unless we put in some hacky code:

public override void Process(HttpRequestArgs args)
{
    if (!Sitecore.Context.Site.Name.Equals("mysite1") || !Sitecore.Context.Site.Name.Equals("mysite2"))
        return;

    // run your site specific code
}

Read More

Organising your Sitecore Patch Include Files

Posted on by jammykam

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 App_Config/Include, e.g. xCustomSitecore.config and zCustomSitecore.config

It turns out that you can simply put your custom configs in a child folder and Sitecore will include them after any files in /App_Config/Include.

Read More