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.
“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.”
I see that as one of the primary benefits of this whole decision – those themes will be forced to either do away with a bunch of their options, or make them work in a much smoother UI.
Over the last few months I’ve been “nudged” to get more comfortable with tapping into the customizer area via my use of symphony pro starter theme and conductor+note plugins. Previously, I had actively avoided the customizer area for client projects. But now, I find that my default behavior is to look to the customizer area before other areas. It would be nice to have a consistent experience across various themes to be able to teach all clients to use WordPress admin in a similar way.
I was struggling with customization of new themes since started my WP website, because Customizer for long time simply doesn’t work and I heard about the same problem from other users as well.
I had it worked only at beginning (first month) while it was working like a charm and has been easy as pie, so child could use it.
While new policy will be disadvantage for those looking for high-level and perfection in customization, it is a big plus for average users (who I guess make the most of WP clients) and do not ask for all “bells and whistles”. Those with higher demands should be offered paid “Pro” customization option, so all sides would be happy.
I’ve read this article with great satisfaction, because new WP policy will end my terrible hassle and struggle as well as of all average users, who do not have time or enough knowledge to dive into hard-coding and editing (which often ends in disaster).
There is a saying from one wise man, scientist (forgot the name):
“You have to grow-up considerably in order to reach simplicity.”
That is what actually WP guys doing now. I congratulate them and fully support their new path.
Way to go!
Pretty happy that Layers saw this coming. Building settings into the customizer is not easy but if done properly is the most obvious method to take. Well done WP for making this a requirement!
Given the types of themes I build and am willing to support, this decision won’t negatively effect me. But I have to admit I find it a little concerning how this decision effectively picks winners and losers in the massive and growing market for builder themes. While I’m not always a huge fan of the results such themes produce, there is clearly a lot of demand for them. I’d even go so far as to say there is a battle being waged over the very idea of what a theme is. For the TRT to decide that a theme should be bound by the customizer is a pretty big deal. Many, like Make and Layers, are already in the customizer. But a lot of them pursue alternative models which aren’t necessarily worse. When I asked Justin Tadlock for a rough idea of his ideal page builder it didn’t include the customizer.
I think there’s a broader issue going on here, that is maybe driving some of the passion behind the responses to this decision. That is the way in which there seems to be increasing pressure for WordPress.org to move away from a package manager model towards a service provider model. Enforcing architectural choices in themes (rather than just code standards) is one step in this direction. Automatic updates is another one. But in general there seems to be an appetite for further-reaching changes to “tame” the ecosystem. Building service-based businesses rather than product-based businesses. Tackling plugin discovery and curation.
I’d love to see more discussion and analysis of the implications of this shift — not just from a user experience perspective, but also in terms of how it might effect the open-ness of the platform, the ease with which beginners can begin contributing to the ecosystem, the place for plurality and innovation, and the sense of ownership over communal assets.
It won’t be the “end of WordPress” by any means. But it may represent an epochal shift in how WordPress is governed and the waters in which we all swim. When will this attention be turned to the plugin repository and what are the implications of that? Will we ever see sales and support more actively regulated on the .org repositories? How will curation tools be governed? These things may seem far-fetched now. But I’d wager that as WordPress.org moves further towards the service provision model they’ll become more relevant.
I just wanted to note that the page builder idea I jotted down would actually fit into the old theme settings guidelines as well as the new settings guidelines. Technically, that doesn’t fall under what we call “theme settings”. That’d fall under under post meta and functional/presentational-related guidelines, which are entirely separate things. I actually wrote the idea down with the review guidelines in mind.
There are builder themes that wouldn’t fit under the old guidelines either. There are some that would. Most that I’ve seen wouldn’t fit into either. They run into other guideline issues. For example, I’ve seen several that make extensive use of shortcodes, which we also don’t allow.
Of course, that’s just one piece of your comment, but I thought I’d touch on it in case there was some confusion over what we we’re talking about in terms of theme settings.
Thanks for replying Justin. I think you raise an important distinction that maybe I hadn’t fully groked: that there’s a difference between theme options and layout managers, and perhaps a big grey area in-between. A lot of the reaction to the announcement has interpreted it as an attack on options-bloat in themes. But perhaps that’s a mis-reading.
It would be great to get a little bit more guidance regarding what constitutes a theme option and what doesn’t. It sounds like you already recognize a need for this. There are some obvious answers: colors are a theme option; a layout manager isn’t necessarily one. But there’s a lot between those two extremes which might need clarity.
As an example, I’m considering for my next themes building a small homepage layout manager. At it’s most basic, it would allow people to construct a homepage from a few different pre-existing content blocks (eg – hero image, Google Map, bookings form, etc). But it may offer more generic components (eg – a row of 3 highlight boxes). I was actually thinking of trying to work along the lines that you set out in that AMA (my secret reason for asking the question).
If such a homepage builder were built into the theme, would it have to go into the Customizer? Ideally, it’d work on the Page editor and the Customizer. But I’d be curious to know whether that constitutes a “theme option” or not.
I appreciate the TRT theme is probably pretty busy fielding questions at the moment, so I understand if you don’t want to provide an answer now. But it would be nice if such ambiguous cases were considered when you get around to discussing and writing more about the guidelines.
(And just to be clear, this isn’t an academic discussion for me. I am planning to explore the freemium model with a theme on the .org repository later this year.)
When TRT is talking about theme options, we’re referring to your basic theme options panels that are common among themes. The distinction I wanted to make is between “theme options” and “per-post options”. Layout managers tend to handle things on a per-post basis. Generally, they either utilize shortcodes, post meta, or some combination of both. We have other guidelines that deal with those items (e.g., shortcodes not allowed, post meta must be presentational in nature).
As for clearing up some of the gray areas, we tend to only handle those as they come up. TRT makes a point to keep the guidelines simple. That way, it’s not a set of guidelines the size of an entire tech book. It also means we have a little wiggle room when we see edge cases and new, cool stuff. Of course, the simplicity of the guidelines also means there’s a little confusion. We’re constantly working on things though to find a balance between simplicity and informative.
As for your specific scenario, it’s probably best to deal with it on a code level. What the code is doing is ultimately what we’d be looking at.
You may be interested in how I implemented just this sort of thing, in Oenology. I added custom Widgets with width/height meta data, and then use Widget order and CSS to provide a fluid, flexible, grid-based featured content template.
It comes out looking something like this:
http://design.chipbennett.net/oenology/
(And not a bit of it is Theme option-based. It’s all handled as a dynamic sidebar, i.e. Widget area.)
Thanks Chip. To be honest, I wouldn’t want to add that kind of flexibility in. My main beef with most layout managers is that they allow the user to do too much. I would like to avoid widget areas mostly because there’s scope for users to try to cram all kinds of crazy widgets into a sidebar area. That’s fine for a sidebar but leads to all kinds of trouble with other content areas — and more trouble means more support and customer dissatisfaction.
In all honesty, standardizing around the Customizer API in lieu of the Settings API will actually make things easier for beginning developers to contribute. Learning to hook into the Customizer API is far easier than grokking the Settings API.
What the vast majority of beginner developers have done, instead of learning either API, is simply to drop in some framework/library implementation of the Settings API, without any understanding of how the API itself works, or how their chosen library implements it. It has done absolutely nothing to teach those developers anything at all about the Settings API, or about proper handling of Theme options, user data, and security.
The Customizer API handles so much more, right out of the box – and understanding it is at least an order of magnitude easier.
This change is more of an issue/problem for the more-experienced developers who have a lot of time and effort wrapped up in custom UIs that implement the Settings API.
I see what you’re saying and I do think once the transition phase has passed we’ll see plenty of tools around the Customizer for beginners.
To be clear, though, the line of mine that you quoted was in reference to the broader changes in community, platform and governance that I referenced in my post. Not specifically to the Customizer change.
It’s user-centered decisions like this that made WordPress such a hit.
And yes, boy did Layers get it right. 😀
It is a win for the community which will result in easier to use themes and will force innovation on theme developers. Feature creep is so yesterday 😉