Settings how and why?

[TimGeyssens]

Hey,

Just wanna start the convo on settings (properties / nodes)... you know stuff that lives in the content tree, related to global stuff in the site...

How do you do this? Just group/tabs on your level 1 root doc... or move it around in a different node(that isn't rendered but only used for these settings)

[AaronSadlerUK]

Personally I house my settings in a node either called Global Settings or Site Settings.

This traditionally lives in a single site, at root (the same level as home), or in a multi site setup, under the container but again at the same level as home, outside of the routable area.

I would then, using an interface, create either a Html Helper or ViewPage method to access these in a typed way.
For example in a ViewPage:

using Umbraco.Core;
using Umbraco.Web.Composing;
using Umbraco.Web.Mvc;

namespace X.Core.ViewPages
{
    public abstract class XViewPage : UmbracoViewPage
    {
        public ISiteSettingsService SiteSettings => Current.Factory.GetInstance<ISiteSettingsService>();

        public override void Execute()
        {
        }
    }

    public abstract class XViewPage<TModel> : UmbracoViewPage<TModel>
    {
        public ISiteSettingsService SiteSettings => Current.Factory.GetInstance<ISiteSettingsService>();

        public override void Execute()
        {
        }
    }
}

This could then be accessed in the View like this:

@inherits X.Core.ViewPages.XViewPage
    @if (SiteSettings.GoogleTagManager().Enabled)
    {
      GTA Script
    }

In the backoffice it looks like this (This example is a multi site, but it's similar for a single site):

[NikRimington]

These days I follow the following structure

-> Site Root (this contains site specific settings such as google tag manager settings, navigation, common social media handles etc)
-> -> Home page
-> -> Other content page type
-> -> (Repeat)

-> Global Settings (This acts as a repository node for things like categories and widgets if needed)
-> -> Categories store
-> -> -> Categories group
-> -> -> -> Category A
-> -> -> -> Category B

Site root contains a picker that also points to the global settings node, so you could have multiple global settings for common groups of sites if you wanted.

[protherj]

Our current favorite is a Settings node at the root. That allows us to have sub-nodes if necessary to break things out (typically curated navigation or other "lookup" type settings).

[jesperordrup]

Settings can contain so much different stuff. Our typical setup uses a nested content property in which you can add the settings needed. It's all nice and clean and don't take much space in content.

On the site rootnode we have a a nested content setting for global stuff. On any other page we have page specific nested content settings.