Andy

As someone who develops themes for client projects rather than for general sale, I can say that I prefer the standard Theme Options pages (using the Settings API) to the Customizer.

The Customizer is good for basic and more stylistic changes such as colours, fonts, etc, but is not so good for more general options such as an API key, a textarea or WYSIWYG editor used for a block of text, or options which don’t directly affect the appearance of the front-end. (And yes, you could argue that API keys etc would be relevant to a plugin, and therefore go in the plugins’ settings, but I prefer to keep things as simple as possible for clients and put all the options in one place.)

I think there is currently confusion amongst theme authors as to what should go in the Customizer and what should go under a separate options page. I’ve seen premium themes with dozens of options under the Customizer, most of which make no actual difference to the ‘live preview’ (because they’re not styling-based options).

I think this stems from a decision by wp.com a while ago to choose the Customizer as ‘the core-supported way to do theme options’, and quietly discourage use of Theme Options pages, because that’s a good fit for the more blog-oriented themes on wp.com, and because the additional features provided on wp.com (which are not in wp.org) work nicely with the Customizer.

I would definitely be interested to know whether it’s possible to contribute to these kinds of discussions in future (e.g. preferring the Customizer over theme options pages). AFAIK, trac is great for reporting problems, bugs, etc, with existing core functionality, but not for discussing which features in core are developed in the first place and which are dropped (Theme Mods API anyone?).

Name *

Email *

Website:

Topic Title (Maximum Length: 80):

Forum:
— No forum —AI and WordPress Articles Blocks Showcase Discussions Events Introductions Jobs and Working in WordPress Podcast Episodes Site and Block Editor