Re: the second option, i’d considered that, but couldn’t work it out. Could I store them notionally as a json file in a page, then pull them out? Or do you mean use the get helper to only pull the preset options (eg. excerpt, feature_image etc.).
If you open the right side menu on a post or page, there are a /lot/ of fields there. I’ve previously stashed values I needed in a page that I just didn’t route from anywhere. (Googlebot may find it from the sitemap, but I don’t really care.) So you use the #get helper to get that specific page, and then you’ve got access to all the values on it. It’s hacky, but it’s editable (with directions) on the front end, and it’s all server side.
Settings shouldn’t be overwritten, unless I’m misunderstanding what you are doing. Are keeping the same folder name when uploading the new theme? If not then you are creating a new theme each time rather than updating a theme - new themes will always use the default custom setting values because they don’t have any previous values to continue using.
@Kevin, do you know if custom values beyond the 15th are accessible in the .hbs files? I’d totally let Ghost throw an error on theme install if it got me a 16th and 17th (and 18th and…) setting, in some cases.
They are. However theme errors will be shown quite prominently in Admin’s sidebar from 5.28.0 onwards so probably not something you’d want outside of development.
Interested to hear what the use-cases are for having more settings. 15 was chosen as a decent limit for settings to avoid themes having everything under the sun configurable and becoming multiple-themes-in-one (with the resulting usability problems for theme end-users) which is a problem some theme marketplaces suffer from.
Sure, here’s one:
Customer wants a banner across the top of all pages. Sometimes. (One config setting for on/off)
They want to pick the color (2)
They want to enter the text for the banner (3)
They have subtext (4)
They want to have a button with text on it (5)
They want to customize the URL (6)
That’s six config settings used up on one small feature.
Social media (0-25 config settings - no one wants all 25, but lots of users want 2-4, and which 2-4 varies a LOT)
When I customize other designers’ themes, I often find they’ve already used 10-15 of the custom settings. That doesn’t give me much to work with if the customer wants something user-editable in the admin panel.
Yes, for us anyway, primary use case is being able to make changes that don’t sit in a page or a post, where we’re using a template across multiple sites. In this case, we’re using it less for layout configuration changes and more for content insertion that doesn’t change regularly, but makes it easier for non-devs to be able to make the changes from the admin panel.