Hi Dan - yeah, I face that same dilemma all the time - a seemingly static element that I’d still prefer the client to maintain the ability to edit, but without giving them access to the template area for variables, snippets, etc. The dedicated channel thing is overkill, you’re right, but I haven’t managed to find a better way to do it. There’s two approaches I’ve taken for it commonly. The first is a miscellaneous channel with a small group of fields to store snippets of text. Commonly I’ll use the title field only as a label for telling the entries apart and not actually make them part of the content, since typically such snippets of text would never have their own single-entry-view, in which case the url title doesn’t really play a role anyway. The problem I have with that approach is sometimes i need more or fewer fields from one type of snippet of text to the next, so it’s not a great solution - if only because what I would want as “required” fields might change from one type of post to the next. What I’ve been doing lately is creating a dedicated “site settings” channel. Then using EE snippets to draw out and cache the elements of the settings that are needed in certain places. It’s certainly not the most efficient way to do things from a database perspective but it has a couple of advantages from my point of view:
1) It provides a very consistent editing experience for the client admins - nothing unfamiliar since it’s just another entry screen
2) It keeps the client away from templates, variables and snippets.
3) It allows me the same granular control, including required fields, field types, etc. that i get for everything else in EE.
4) If you don’t focus on it being a single entry, you could actually implement it for A/B testing of certain content as well - my site settings channel often includes on/off triggers for certain things, but also default meta description and keywords for the site as fallback for my dynamic entry-specific meta data
On the downside:
- and entire channel for what is basically only likely to ever be a single post is certainly overkill and not very likely to be the most database-friendly way to handle it
- treating settings as an entry doesn’t quite “feel” right either to me or to the client, since it’s content that likely will be entered the first time and then for the most part forgotten
So until EE adds an entry-style “settings” area to which we can assigned multiple field types of our choosing but have a lightweight non-channel database impact, this has been my solution.
Hope that helps.