Hi Jason,

If you're looking to create content items which don't have a URL then I'd use blocks.

What are the advantages vs disadvantages for using blocks in that scenario? Feels odd to do that since its not the ideal editing solution for my content creators. It would be hard to teach them that certain setup items are blocks on the right side of the admin, which is counter-intuitive to their perception of what blocks are used for. Plus there is no UI for them, can you have a block without a controller and view without getting a server error? What have others done in the past? This has to be almost all EPiServer developers have crossed in the past. I doubt they are creating DDS classes for them and having to build their own custom UI to edit them. While that may make sense in some cases for things that are "under the hood", what do you in this case where it needs to be editable?

In my experience, global settings are usually grouped together in a tab on the start/homepage. Then available globally from ContentReference.StartPage. 

For settings comprised of simple data types, that is how I have done it so far. What I am talking about is lists of things such as cities, states, countries, lookup lists and various complex types with more than just a name that also have media assets tied to them. 

For that, sounds like you want both. You would use a block as a property (on the startpage). Editors would still go to the tab on the startpage but all the fields of the block are grouped together with a label.

https://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Content/Properties/using-a-block-as-a-property/

The advantage of using blocks is that it gives you a content item without a URL and, if the items you're editing need to be used on pages, editors tend to be more comfortable dragging blocks into a page than other pages. You certainly can create a block without a view/controller though, if you want to stop the CMS trying to offer on-page editing you'd need to use an editor descriptor like this to remove that view for your block type:

    [UIDescriptorRegistration]
    public class MyBlockUIDescriptor : UIDescriptor<MyBlock>
    {
        public MyBlockUIDescriptor()
        {
            AddDisabledView(CmsViewNames.OnPageEditView);
            DefaultView = CmsViewNames.AllPropertiesView;
        }
    }

The disadvantage of blocks is that you can't use them to create a heirarchical structure in the way that you can with pages and, as a consequence, it's more difficult to limit the types of blocks which can be created in a given folder.

If you wanted to use pages to represent your data items you'd have the advantage that you could create structures of data and control the type of content in those structures but, if you're storing items like countries you'd need to be careful not to put too much in a given node as performance of the tree in the CMS can be adversely affected if you've got too much content. There are also more properties included on a page by default which may be irrelevant if you're storing just a property or two so blocks would be a more lightweight approach.

So it boils down to three choices it seems: use pages, use blocks, or use PropertyList<T> on the start page. All have their strengths and weaknesses, but none of them seem like a very good fit. I almost wish there was an additional content type specifically for this. I like the page approach since I can control types of content and organize it into a tree. The block approach is less appealing to me. The PropertyList approach may work well for things that you do not need to hold a reference to. I am now curious what most people have done in the past now that I have seen the choices.

Hi Jason, there are good tips/ideas already from others but I'll add my 2 cents here to.

We've used a page type(s) for different site settings. Basic setup would be something like this:

• on the site start page have a content reference property that will point to your sites settings page type
  • limit that only the site settings page type can be used here, use the AllowedTypesAttribute here
  • also limit that only users belonging to certain "security" group can edit this property, not all editors should be able to change site settings
    • see blog post on how to create a PropertyEditRestriction attribute by Linus Ekström
  • this way you also get the benefit that when the start page content is changed your site settings don't seem to get updated (assuming you will implement a service to get site settings instead of always getting the start page and reding the settings from there)
    • if you have your site settings on the "start page" it means that every time you change site settings you also change the start page content and cache is cleared for it and same goes for your site settings when content is changes so will be your settings - you get the point, when start page changes you don't know did your settings change or content, so having your settings on its own type / instance makes sure that updating content doesn't "change" your settings and vice versa
• have your custom site settings page type which contains your various settings
  • implemment a service to get the site settings and register the service with IoC
  • ensure that the site settings is not searchable (depends on your site implementation), not visible in the menu
  • register UIDescriptor, where you disable onpageedit and preview views (see post above by Paul)
  • ensure that it will not have a template
    • we usually have used some custom marker interface like: ITemplateless
      • and then we have a custom initialization module that attaches a handler to the TemplateResolver.TemplateResolved event and if something has resolved a template for the site settings then we set the template for it to NULL
      • have a look at the Episerver Alloy MVC sample site: CustomizedRenderingInitialization and TemplateCoordinator classes