Customization of site settings

[dumboster]

Hello,
Is there a way to customize Site settings ? Currently there are "Application name" and "Allow automatic updates", but I would like to add my own settings via the admin interface.
Thanks a lot

[HeyJoel]

Not yet I'm afraid, not that's documented anyway. The settings functionality needs reworking and will be changed at some point in the next few releases to make it extensible in the way custom entities are.

[dumboster]

Thanks for your response. I look forward to this enhancement.
Bravo for the incredible work that you do!

[HeyJoel]

This functionality related to the idea of having singular custom entities e.g. having a "Menu" custom entity that will only ever have one entry. This is similar to the way customizable settings would work.

The idea is that you would create a "SettingsDefinition" (naming tbd) that would have the following properties:

• DefinitionCode (unique and used for lookups via queries)
• Name (for the admin panel -no need for pluralisation)
• Description (for the admin panel)
• AutoPublish (the settings would be optionally versioned as with custom entities)

Questions

• Would we need an option to localize as with custom entities? If so, would this appear as a version per supported locale and would there be an optional inheritance model to the settings e.g. en-gb locale inherits from the root if nothing is specified?
• We'd need some way of expressing default state since the entity would need to be created at startup after it's been defined and if there are required settings then you'd expect some default values to be applied
• Where would these sit in the admin panel menu? Some examples are clearly settings, others are entities? There's a job to make the admin menu more configurable, but that development might happen after this so we may need to make an interim decision.

Example settings/singular entities

• Main Menu
• General Settings
• Contact Page (e.g. simple scenarios where you just want simple data for a specific page without a template)
• Footer (i.e. layout level content)
• Vimeo Account Config (i.e. plugin settings)

[purplepiranha]

I definitely need this ability for my menus.

Looking through your questions...

• Although I'm not using Cofoundry for anything that supports different locales at the moment, In the past I have worked on large multi-locale sites and I can see that the option to localize custom entities would be advantageous. I would say that a version per supported locale would be the way forward, with it defaulting to a root or default.
• Default state: Certainly there would have to be a default state option, whereby either the value can be set, or nulled if appropriate.
• I was thinking settings: For my top menu (and possibly footer menu) I would want to pick a single menu from a list of existing menu custom entities. A singular entity is surely just a related group of settings?

Hopefully this is helpful.

I've been really impressed with Cofoundry so far. Currently redeveloping a site which was using Umbraco - which I would never use again with all the hassle it's been.

[JornWildt]

Many of my ideas/scenarios could be solved with classes like this:

[Description("My group of admin settings")]
class MyAdminSettings : IAdministrationSetting
{
  // Decorate with attributes like [Required] as needed.
  public string SettingA { get; set; }
}

Storage could simply be in a table like this:

Group: varchar
Description: varchar
Name: varchar
Value: varchar

Group could be the class name, description come from the Description attribute and Name be take from the property name.

Add to this meta data like created-date or even versioning/change-history.

With a table like this it would not be necessary to think in terms of singleton entities. On the other hand you may already have so much built-in utility stuff for entities so adding a new data table like this would be silly. I'll leave it to you guys - this is just some ideas for inspiration.

[relatable-web]

Stumbled across this issue when searching for something similar to what is described here. Are there any plans to tackle this any time soon?

If it helps I have two distinct use-cases for this kind of functionality:

1. Global settings for the site - things like common labels and error messages that I'd like my editor to maintain rather than hard-coding in source code, as well as visual elements commons to all pages such as a site menu, socials etc.
2. A custom-entity-level settings object - so each custom entity type gets a single settings object, again with the purpose of allowing the editor to specify common labels, error messages etc for all instances of that custom entity. My naïve expectation for how this might be defined would be something like MyCustomEntity : ICustomEntityDefinition<MyCustomEntityModel, MyCustomEntitySettings>

Thanks as ever for this truly awesome CMS - I'm a big fan.

[HeyJoel]

@relatable-web for point number two, I wonder if feature #391 would work? It's not developed but it is an easier implementation than this one.

I did start a spike for this a while back when I had some free time but unfortunately I've been too busy to look at new features recently.

[relatable-web]

Thanks for the reply @HeyJoel. If I understand your suggestion in #391 correctly, whilst it'd address the issue it would be more of a work-around than a solution because it'd still require a dedicated custom entity type to represent the settings, then editors would need to be instructed to maintain only one instance of this entity. Not a major issue but I think it starts making the admin UI more confusing for the non-technical user. But maybe a special type of custom entity - a settings entity - could be introduced? Behaviourally it'd work just like any custom entity (so could just be a new binary flag on the entity definition) but the UI could surface these in a separate blade of the UI and restrict them to 1 instance max. But obviously you know your CMS far better than I do so I have no real idea of the complexity involved in such changes. Hopefully food for thought though :)

[HeyJoel]

@relatable-web ok I understand now, it's a single set of settings for the custom entity type, not per custom entity instance. This would be a separate feature so I've opened issue #552 to cover it.