I’m in the midst of reworking a site and in trying to make the backend as friendly as possible I’m trying to avoid hard-coding some of my options in template files. I’ve got a few archive pages where I’m setting up arrays of data (in my case, a few large lists of categories that are used to alter the display of the template based on what category is being viewed).
At some point I want to expose these options in the backend. I’ve seen a few ways to do this, including leveraging CPTs, using the settings API, and using an additional db table.
I assume the settings API is the preferred method, but where I’ve seen other themes use this, it’s usually for more global options (site logo, color schemes, etc.) – I’d prefer to somehow expose these options in an area that would make more sense (in the above example, under the categories menu item).
Am I going in the right direction here? I’ve not been down this road before, most of my themes are basic enough that I’ve not needed to setup any options.
1 Answer
If the options have “visual” impact on the website, consider using the customizer, it gives immediate visual feedback on what changing a value means.
If the settings have no visual impact on the website, then maybe they don’t belong in the theme after all, but in a separate plugin.
There are always edge cases, so if the options are really related to categories, and have no visual impact, but you still feel they belong in the theme, then could make sense to put the menu entry close to categories.
But if you have other options, then I would suggest against spread the options in different submenus, because themes can be easily switched, and if you have all theme options in one place it is easy to understand what you loose switching theme. In fact,
if you put something in the under the main “Posts” menu, users could easily and rightfully assume that is a core functionality.