Needing access to site settings is definitely not a new challenge. I've been creating .NET CMS solutions for over ten years now and from my first project up until my most recent, every site has needed one.
If you are new to CM development then think of these settings as things like the Search page Url, the contact us page or the check out page for a commerce site. Over the years, I've used a variety of ways to add settings into an EPiServer site. This article will discuss the benefits of some of the more popular methods.
Storing them in the StartPage
This one is one of the most common approaches. You create a new tab called setting on your home/start page and add everything in there. Using this approach is very easy as you can access the StartPage using ContentReference.StartPage.
Access-wise this is pretty easy, however, on some projects the amount of settings can bloat very quickly. When you use the StartPage on a high load site, loading up all this unneeded settings data and, from the other side, passing around the unneeded start page settings, adds more unneeded bandwidth on your server.
Creating a Setting Page Type
This is also another one of the more popular choices. You create a SettingsPageType and define everything you need in it. The setting page can leave under the root page and you can easily get access to it using:
Doing it this way means you don't have any unwanted data in your start page and you don't have any unneeded homepage data being passed around when you only care about settings.
In 9 out of 10 cases, this is the approach I use now. It also means you can block access CMS editor pages. Some of the other benefits include version history and language management.
Creating an admin page
This way is a bit more old school. You can create an admin page to store your settings. This means you can prevent content editors having access to it completely.
I've always found though that people forget where it is and then struggle to find it, which is why I favour the settings page with restricted permissions. You also lose your paging version history and language management, if you need different settings on a multi-language site, this is definitely not the right approach.
App Settings
Do not go down this route. You store the pages Id for key pages in your app setting. This way is very clunky and prone to errors. If you delete pages and recreate them, your app settings will break. This also requires a potential code release to update. Yuk!
A Settings Assembly
I used this approach a few times, you create a separate assembly that has a lots of static consts that just stored settings. This means only developers can update settings. When you want to change a setting, it does require a release but that release is contained in it's own assembly, so you can deploy that without needing to do a full website release. I used to like this approach a lot but it is very flexible.
In times pre CI, when you manually copied files onto a server, this was a pretty simple approach. Post continuous integration, I've never used this approach as it's too inflexible and adds too much risk creating a full release package.
A Setting Block
Now we have blocks, instead of creating a setting page, we can create one or more settings blocks. Creating blocks is a nice approach because it's not a page, you’ve still got all your Episerver content benefits, like version history, language management. The downside of using one or more blocks for smaller sites is you need to manage one or more areas.
That draws us towards the end of this discussion. For preference, I think the page settings is the best approach with the settings block a close second. Having your settings data separate reduces the network bandwidth and having it within Episerver so you don't need to do a dev release will save you a lot of frustration down the line.
