A few weeks ago I came across an issue on GitHub requesting an Umbraco Core feature to allow for specifying data or content that would be different based on the current website’s environment (development/staging/live). The question was posted in the Umbraco Cloud issues, which makes sense considering that Umbraco Cloud seamlessly supports a multi-environment setup.

The use-case example was for storing external service IDs or API Keys – if you have a “sandbox” or “development” one which is different from the live one. This is not an uncommon need. (In fact,  years ago I created a bit of .Net code to handle storing multiple values to be used based on environment.)

Considering the question today, in light of the current state of Umbraco 8 and Umbraco Cloud, 3 ways to handle this need came to mind. Here they are – in general order of coding complexity.

1. Web.config Transforms

Umbraco Cloud supports the use of Web.config Transforms which run on each environment. These are super easy to set up, from the developer side. If the data is short (username, id number, GUID key, URL, etc.) and you don’t need to allow Content Editors to add/update these values, this is the best way to handle your environment-specific needs.

How to:

In web.config:

  <appSettings>
    …
    <add key="XyzApiKey" value="DevelopmentValue"/>
    …
  </appSettings>

In the “Web.Live.xdt.config” file:

  <appSettings>
    <add key="XyzApiKey" value="LiveValue" xdt:Transform="SetAttributes(value)" xdt:Locator="Match(key)" /> 
  </appSettings>

You can specify the value for each of your environments as needed by putting similar code into “Web.Development.xdt.config” and “Web.Staging.xdt.config”, etc.

2. A “Settings” Content Node Area

If the content needs to be managed by non-developers via the Umbraco back-office, you can create a Content section for these “Settings”. The specific architecture would be based on what your exact requirements are – and how flexible it needs to be.

How to:

The simplest setup would be a doctype with a textstring property for each of the environments. Then you could add as many of these “Variable” nodes as you have data items. You can use the nodename as the “Key”. Grabbing the correct value via code wouldn’t be difficult. If you need an easy way to know what environment the site is running on, set up a web.config AppKey (and transforms for all environments) to check:

<add key="CurrentEnvironment" value="Local"/>

Then just read the matching property from the content node.

If you need to allow a flexible number of environments, the setup would be a little more complex, but not too much.

3. A Custom Property Editor

If you worked on a 1-to-1 multilingual site built with Umbraco 7, you probably came across a custom property editor called “Vorto”. It allows you to “wrap” any property editor in a structure which changes the data structure such that the single property holds separate data for multiple pre-defined languages. If you took a look at the Vorto sourcecode, you could probably work out a similar sort of wrapper-type Property Editor to manage multiple values on Environment rather than language.

You could also just create a simpler Property Editor with its own custom JSON data structure to manage environment-specific values.

 

If you need help implementing any of these options, or something else for your Umbraco website, reach out. I’d be happy to chat with you.