Adding EPiServer multisite support to global settings functionality

First off, the GlobalSettings class which previously contained all of the code have now been reduced to almost nothing. This is due to our need of providing an easy way of mocking the settings for our unit tests.

As you can see, the Instance property is still static, so you will be able to access it in the same way as before.

var setting = GlobalSettings.Instance.IntegerSetting;

However, all the functionality has been moved to a SettingsPageRepository. The interface used to fetch the instance exposes a method for retrieving the settings page for the culture found in the current context.

The interface also exposes a method in which you can specify for which culture you would like the settings page. This is useful while for instance writing EPiServer Scheduled Jobs where you will have no HttpContext while they are running on schedule, or in any other case where you can’t get the current culture automatically.

The two public methods both use a third private one to retrieve the SettingsPage object, one just passing on the recieved culture, and the other trying to determine the culture itself by requesting it from the ContentLanguageService. The SettingsPage itself is not cached since EPiServer does a good job with this, however since all languages in the EPiServer installation uses the same page (just different language versions), we can optimize a bit by caching the ContentReference.

This is roughly the same as in the previous article, with the difference that we now work a little more with the language versions. If we don’t have a settings page for the current language, one is created automatically.

The masterpage get method is also rather straight forward. It assumes that the master language is Swedish. Also the ParentPage is the root page just as before, and the default page name is [GlobalSettings].

The SettingsPage class also get some alterations. We’ve now added a separate block for each site (88-98), and keep common properties that should be the same for all sites separately.

The final thing added is a current site property. This will automatically give you the current settings, without you having to worry about which website you’re on in your EPiServer installation. I’m sure you can think of a more clever way of determining which site you’re on, but this was good enough for our purposes.

Both the site specific blocks need to implement the ISiteSettings interface, and it need to contain all the properties that all of the sites use, regretfully. Also you’ll need to ignore the ones you don’t need in your block implementations in order to keep EPiServer from synchronizing them to the database.