The WordPress Theme Review team made a major decision this week to enforce the use of the native customizer on new themes submitted to the directory. Theme authors who want to include customization options will no longer be able to create their own settings panels but will be required to follow the new customizer standard, effective immediately.

Existing themes in the directory will have six months to comply before the Theme Review Team starts to enforce the new requirement. To facilitate this process the team will is preparing a series of posts and better documentation on how to use the customizer.

Theme Review Team member Justin Tadlock brought the matter to a vote during the last meeting:

I’m proposing that we do an outright ban on custom settings screens in the admin. The plan was to allow theme authors to naturally move over to the customizer given time. This hasn’t worked.

As attempts to standardize the use of the customizer in new themes have not been successful, the Theme Review Team has opted to draw a hard line, as gatekeepers to the official directory. For the most part, reactions to the new guidelines have been positive, but theme authors who incorporate other options frameworks are not thrilled about having to rewrite their options for the customizer.

Will the Customizer Requirement Stifle Innovation for Theme Developers?

While many developers agree that the customizer is WordPress’ strongest option right now for providing live previews on design customizations, some are worried that the new requirement will limit creativity and innovation that might spring up from different solutions.

@justintadlock Big change. I’m pro customizer but not allowing it means better solutions may not see the light of day or even be attempted.

— Carl Hancock (@carlhancock) April 21, 2015

@justintadlock It’s better than most as far as WP goes today. I’d just hate to see it stifle other ways of tackling the customizer concept.

— Carl Hancock (@carlhancock) April 21, 2015

Dovy Paukstys, lead developer of the Redux Framework, commented on the announcement to express a common concern among developers who utilize more specialized controls than the customizer can currently provide.

So essentially what you’re mandating is for Frameworks, like Redux, to port all of their special controls to the Customizer because if a theme uses any form of a custom control and doesn’t display it in the customizer, in 6 months time you will boot from WP.org. Correct?

Doesn’t that seem a little narrow sighted? The customizer is great for live reload, but it doesn’t have the real-estate for advanced fields that developers make.

Resistance to the new guideline is frequently met with the suggestion that developers instead work on improving the customizer to be better for all users, as it is now WordPress’ core-supported method of providing theme options. Paukstys finds it to be too limited in its current state for anything other than simple style changes.

My personal motivation to improve the customizer is low since I personally do not see it as a viable option outside of styling. There’s simply not enough real-estate from a design perspective. It also doesn’t have things like visual validation, warnings, etc. It doesn’t offer field visibility linking, etc. It serves a powerful purpose, but I do not feel it is a complete replacement for the settings API.

Paukstys further contends that the community was not represented in the decision process that followed the official proposal and that the new mandate unfairly promotes a single, narrow approach.

Why do you wish to limit developers so much? Isn’t the point of open source for people to make things in different ways and improve the whole? Why are you limiting your devs? Could it be that the customizer hasn’t had the adoption that you think it deserves? This just seems like a mandate by your team and not a desire of the community as a whole.

According to Emil Uzelac, theme authors using Redux or another framework are still at liberty to use the TGM Plugin Activation library to notify users of a theme being “Redux-Ready,” for example, but will not be able to fully package those options as part of the theme submitted to WordPress.org.

Tadlock is currently preparing a more comprehensive reply to these concerns but maintains that he will always support more innovative ways of approaching customization, should a new solution surpass that of the customizer in the future.

@carlhancock I’ll always fight to get something innovative pushed through even if it doesn’t fit in the guidelines.

— Justin Tadlock (@justintadlock) April 21, 2015

The Theme Review guidelines have continued to evolve with WordPress over the years and the team meetings are open to all who wish to have a voice in the decision-making process.

Tadlock is aiming to produce more education for theme authors within a day or two. He has also committed to helping developers build controls that are not readily available.

Make me a list of controls you’d like to see. Core added a lot more options in 4.0, but I’m open to building any control classes that could be utilized by theme authors. If there’s a control that the customizer doesn’t support out of the box, it should be built by extending the core WP_Customize_Control class. I’ll at least attempt to build any controls that people need help with.

Theme developers who are worried about working with a limited set of customizer options will have help from the Theme Review Team. Those with themes that need updating have a six-month head start before the guidelines will be enforced on themes that submit an update.

Source: WP Tavern