All theme options must now be included in the Customizer for themes submitted to the WordPress theme repository. Custom theme options pages will not be allowed. The change will have implications for authors, reviewers, and users of WordPress themes.
The Theme Review Team announced that all themes hosted on WordPress.org will be required to use the Customizer for theme options moving forward. The new requirement will be phased in over 6 months, which gives existing theme authors some time to make the updates and new theme authors some time to adjust themes that might already be in progress.
This is a huge change. Although the Customizer has been available since WordPress 3.4 — which was released in June of 2012 — adoption has been slow on themes submitted to the official WordPress theme repository.
Official stats aren’t available, but of the ten most recent themes submitted to the theme repo I looked at, 20% had a custom options page. Of the ten most recent updates, 40% had a custom options page. This is a very small sample, but there’s no doubt this change will effect a huge amount of submissions.
From a theme review perspective this makes a lot of sense. Verifying proper sanitization and proper use of the Settings API can take a huge amount of time for reviewers.
Many theme authors use frameworks like the Options Framework, Redux, Titan, Options Tree, and UpThemes — but reviewers still need to check for potentially malicious alterations, proper text domains, and function prefixing. Standardizing this by requiring the Customizer will make the job of theme review simpler.
@devinsays Echoing others, it's a win for users and will speed up review times. I think the time has come.
— Kirk Wight (@kwight) April 22, 2015
From a user interface perspective, it also seems like a good move. Users can always expect options to be available in the Customizer tab if they exist and they won’t need to navigate unfamiliar custom screen layouts — though users of specific themes might be confused when the options page disappears on an update and moves into the Customizer bar.
For theme authors it is probably a mixed bag. Many authors rely on WordPress.org to drive sales of commercial theme upsells, and the theme options page is a common place to promote such upsells. It can also take quite a bit of time to migrate options from a custom page to the Customizer and ensure perfect backwards compatibility.
@devinsays I think it’s a great way to standardize and will ultimately be easier for both users and theme authors.
— Dan Manchester (@elseloop) April 22, 2015
Certain frameworks also provide features that aren’t native to the Customizer, like repeater fields, multiselect, image radio buttons, datepickers, editor instances, and custom typography options — though Customizer libraries like Kirki can also bridge those gaps.
The Customizer has evolved quite a bit since it was first introduced. WordPress 4.0 brought a number of enhancements like contextual controls, panels and additional field types. Core features like custom headers, custom backgrounds and widget editing have migrated to the Customizer and then been improved over successive releases. In the upcoming WordPress 4.2 release users will be able to switch themes directly from the Customizer.
It could be argued that space constraints in the Customizer could make organization a bit more difficult for themes that ship with hundreds of different options, but there are many examples of WordPress themes already handling this well.
The Make theme by the Theme Foundry is one such example. It has six custom panels and over three hundred individual customization options — but is still a very usable and popular product. Obox also went all in on the Customizer with their Layers page builder theme. Examples like these help prove that the Customizer can scale fairly well, even with a lot of options.
Personally, I think the standardization of options is a great move forward. I originally started developing the Options Framework (an easy way for developers to build custom options pages) over five years ago because there was not a good solution in core. I’m now happy to report that the code I helped develop is nearly obsolete as better tools have become available.