In this tutorial, I will cover some strategies on how you can manage global data and settings within an Episerver CMS powered website. Having an area to manage global site settings will be a requirement on every project, so how do you best management within Episerver CMS 🤔. Settings are a fact of development life. Feature flagging options, storing a reference to key pages like the search page, placeholder text required in the header/footer, the needs are endless.
Episerver does not provide an out-of-the-box solution for managing global settings. It is left up to you to decide how to deal with global settings. If this is your first Episerver project and you are lacking experience, it can be hard to know which is the best solution. Building something and then finding out it does not work, is the most expensive way to validate ideas. The aim of this guide is to give you the knowledge to pick the right solution so you do not have to refactor everything 🔥🔥🔥
1. Storing Settings On The Homepage PageType
One approach to settings management is to store all of the settings as properties on the homepage page type. This approach is not my favourite, however, it is probably the most widely used pattern. In this approach, each setting is a property on the homepage page type. The reason why people like this approach is because accessing the homepage is very easy. You can use ContentReference.StartPage.
There are two downsides to this approach. First, if you have hundreds of settings, the homepage can become bloated. This can affect performance. The more data that you need to load and transfer within a request, the slower things become. The second issue is refactoring. In the future, if you need to change the underlining type in code, it is very easy to take a whole website down easily 😔
2. Creating A Setting Page
Using a dedicated page just to store settings is another popular pattern. You create a SettingsPageType and define all the settings within it. I recommend making sure the parent of the setting page should be the root page. If you add the settings page under the homepage, you run the risk it gets indexed in the search 😕. In code you can access settings easily, like this:
Using a settings page is good because you don't have any potential secure settings data on the homepage. This is the approach I use in 99% of my projects. Another benefit of a settings page is that the version history only contains settings updates.
3. Creating An Admin Page
It is also possible to create an admin page within the Episerver admin UI to store your settings. This approach means all settings are hidden from content editors and only admins can access them. In this approach, you use something like the dynamic data store to save the settings. The downside of this approach is effort. It will take more developer effort to create a custom settings management solution. Another sad fact is that the admin still uses web forms, so expect to create a .aspx file with a code-behind 😔.
Not using a CMS page to store settings means, you 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. Also, think about data migration, how do you share settings between the different environments. Using a page means the import/export feature can be used! In general, I recommend avoiding it this way!
4. Settings Within App Settings
One option is to add all settings within the web.config as app settings. This approach is OK for settings that never change, however, it is not ideal for settings that change regularly. This approach also requires a code release just to update settings. Yuk! One thing to keep in mind is that deployment in DXP might take 30 minutes. If you need to quickly turn on /off a setting, be warned, it may not be possible this way ❌!
5. Settings In Code
I used this approach a few times, you create a separate assembly that has a lot of static variable const 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 its 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.
6. A Setting Block
In this pattern, you hardcode all your settings in code. The most travelled route, would be to create a seperate class library that contains one or more classes.Those classes would only contain properties marked as static const variables soley used to stored the settings. As this is a code-based solution, only developers can update settings. This approach does require a release, however, as the release only need to contain the updated settings assembly, rather than the whole site, it is less risky.
I tended to only use this approach if the client didnt use a Ci/Cd pipeline. Copying a single file onto a server is quick and pretty risk-free. I haven't worked on a project without a build pipeline for many years, so this approach is less useful.
6. A Setting Block
Finally, you can add settings into blocks. Instead of creating a setting page, we can create one or more settings blocks. Creating blocks is a nice approach as you get a lot of positives. You have still got all your Episerver content benefits, like version history, language management. You have less risk of bloat and fewer refactoring issues as you do not need to add the settings block to the homepage. This is another approach that I recommend highly and use a lot. You can even mix a settings page with multiple settings blocks 🤔 This gives you the best of both worlds 💥
This draws us towards the end of this discussion. I hope you now understand the options and the pros and cons of each approach. For reference, I think the settings page or block approach is the best. Pick the options that make you smile. Happy Coding 🤘
