Not at all sure if this is the
best way to go, but this is how I might go about it, depending on the client and the project:
Create a content-type "settingrecord" with all the fields you want. Create a record of type "settingrecord" in the admin back-end.
Use a code like
- Code: Select all
{% setcontent sitesettings = 'settingrecord/first/1' returnsingle %}
at the beginning of the template. This will use the oldest record of content-type "settingrecord" - likely but not always 'settingrecord/1'.
Then you should be able to access fields like
- Code: Select all
{{ sitesettings.field }}
and manipulate them like any standard field.
This has the advantage that it only makes use of existing admin interfaces and common code.
It has several disadvantages:
The possibility of having multiple "settingrecord" records could be confusing to the user. If multiple records of "settingarray" are created, only the oldest published one will be used. (Using settingrecord/first/1 ensures that you don't hard-code a reference to a particular record in your template, allowing your user to delete a settingrecord record, create a new one, and still have the functionality.) The user will also have to create and publish that record in order for the site to work properly unless you have fall-back defaults.
You might want to restrict edit permissions for the content-type "settingrecord" if the site has multiple admins.
You will also want to set specific templates for the record and listing display for "settingrecord" so they don't expose your internal site settings - maybe redirect them to the homepage or something.
I'm sure there's a more elegant way to do this with a plugin, but this might work for some projects. Note I haven't actually tried this code, but I'm fairly sure it should work.