Cancel

Sarah Gooding

WordPress.org Now Requires Theme Authors to Use the Customizer to Build Theme Options

colored-pencils

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 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.

https://twitter.com/carlhancock/status/590613807870906368

https://twitter.com/carlhancock/status/590614883525341185

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.

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.

Category: ,
Tags: ,
223

223 responses to “WordPress.org Now Requires Theme Authors to Use the Customizer to Build Theme Options”

    • Talk about shooting yousdlf in the foot. It’s not wordpress core that makes it the versatile tool it is now but the work of the theme and plugin developers. Restrict the input of the creatives out there and you might aswell just use twenty eleven. Carefull wordpress your core is not that exceptional. There’s always another solution round the corner. Concentrate on security and leave the rest to the community that has made you popular.

      Create forum topic from comment

    • I just learned of this WordPress power grab, and as a long time WordPress user I am appalled.I NEVER use Cusomizer because it provides me none of the options I need to build a site that works for me. Forcing the excellent developers who have managed to create extremely versatile, user-friendly theme options that do everything from sliders to typography and everything in between to use an API that is so incredibly limited in scope means one thing to me–Automatic is trying to force everyone into WordPress.com. For $99 that platform (which they have ruined by making it so simplistic and cutesy it is an annoyance to every person over the age of 12) gives users a custom domain, typography, color settings,—and custom CSS, but none of the great options of a theme like Nirvana or Asteria–both of which are FREE. So, when those custom themes on WP.org become impossible to use–Theme Team and Mulleweg surmise–everyone will go running over to WP.com.

      Sorry guys, it’s not going to work. Implement this nonsense and many, many, many of us will leave and move to a platform that allows developers to implement their creative vision as they choose.

      Create forum topic from comment

      • The Customizer can do anything a settings page can do. It is, out of the box, a more complete API than the Settings API used to build settings pages, and it is just as extensible.

        And why would the Theme Review Team want to “chase” people to wordpress.com?

        Create forum topic from comment

      • Strangely enough most people believe that the customizer is not powerful enough and that it can’t handle the things that they think they need.
        All of the above assumptions are wrong.
        The customizer IS powerful.
        It can be extended to do whatever one needs to do.
        It is written a lot better than any other options framework I’ve seen out there, and it’s guaranteed to be supported, maintained and improved for years.
        What’s not to like?
        The only thing that I see here is that people just don’t like it when change happens.
        This is a good change and will help improve the future for all themes.

        I’m sure the “powerful themes” you mention above can easily be converted to use the Customizer, and when they do they will be better than ever.

        Just give this a chance. :)

        Create forum topic from comment

          • So your whole argument against it is that you create the settings + controls separately??

            If that’s all then it’s quite easy to combine the settings + control creation with a simple function…
            Perhaps instead of arguing against the customizer everyone should just get used to the idea that it’s here to stay and focus on improving it.
            Instead of complaining that it doesn’t do what everyone needs or the way you want it, try to make it better. :) That’s what I did with Kirki and I offer 2 alternative syntaxes you can use: https://github.com/reduxframework/kirki/wiki/Fields

            Anything’s possible if you try to solve your issues. :)

            Create forum topic from comment

          • aristah: My whole argument is not that. You need to write JavaScript, you need write configuration for the various controls and where it goes, you need to register the various files that loads the control. You need to write code for how it should be rendered on the frontend. And that is just part of my issues with it.

            Your solution to my complaint is that I need to depend on yet another framework? I need to bloat my theme or plugin code with inclusion of other framework since default WP is not enough? Like I said stupid.

            chip: Do you mean saving theme_mod stuff or? Because I have not had any issues with Settings API from what I can recall.

            Create forum topic from comment

            • You need to write JavaScript

              You only need to write extra JS if you want to use postMesaage – which you don’t have to use!

              you need write configuration for the various controls and where it goes

              Don’t you have to write configuration using the settings API in order to create an admin page for example? If anything, the customizer makes that easier!

              you need to register the various files that loads the control

              That’s only if you plan on building your own advanced controls. Which you would have to do anyway if you were using the settings API… and it would be even harder there ’cause you’d also have to write a lot of extra code to support that!

              You need to write code for how it should be rendered on the frontend

              And if you were using the settings API you wouldn’t have to write any code to handle how your saved options would affect the frontend of a site? The code to control how your options affect the theme/frontend shouldn’t change at all, it’s exactly the same thing.

              Your solution to my complaint is that I need to depend on yet another framework?

              No, it’s not!! What I said earlier is that if you want to do it it can be done, and then posted a link as an example. Building a simple function to simplify the way you write your own code shouldn’t be that hard, and if you need any assistance I’d be more than happy to help out!

              Create forum topic from comment

            • @andreas: I haven’t written a single line of javascript for my Customizer API implementation. It isn’t required.

              And keep in mind: Settings API and Customizer API are both used to expose settings to the end user for configuration. Options API and Theme Mods API are both used to store/retrieve settings to/from the database.

              The Customizer API can be used with either the Options API or the Theme Mods API, with equal ease. You literally change one key in the $wp_customize->add_setting() args array, to change from the default (Theme Mods API) to the Options API. Everything else works exactly the same. But the Customizer API is much simpler out of the box, because unlike the Settings API, the Customizer API at least has the basic, most-used controls already in the API, and sanitizing is actually much simpler (and easier to follow/understand).

              With the Settings API, you have to register the settings page, make sure user capabilities are correct, then build out the settings fields (with custom markup, because the API doesn’t provide any of them), then configure the form submission, then build out the sanitization/validation callback.

              The Customizer API cuts that work by at least half.

              Create forum topic from comment

          • aristah: Why would you not want instant preview of the changes the user is making? The possibility of instant preview is what is good with the Customizer. So why would I not want to use the postmessage stuff? At least for most things. I use it for most things anyway.

            chip: I dont doubt the improvements. I just dont see them as such revolutionary improvements as you seem to claim. I like the capability stuff and the controls.

            ——–
            I work mainly with plugins so I write Settings API stuff regardless unless I would want users to go to Customizer to change things that has no need for preview. This just seems like more fragmentation. Instead of improving across the board with a single system we now have two separate systems (or rather three or four depending on how one counts). Just like we will have two separate systems for managing Menus. There are also duplicate areas for a bunch of other settings. I find the whole thing to be a sign of no direction. Core people just tinkering away with no set goal or leadership.

            Create forum topic from comment

  2. Unbelievable.

    This is the most insane decision I’ve ever seen on WordPress.org. This will kill hundreds of themes, prevent all upsell themes, and completely stifle future innovation of theme options and custom themes.

    WordPress.org is officially no longer an open source community.

    Theme authors deserve the same rights as plugin authors.

    Anyone involved in this decision should be fired.

    Create forum topic from comment

  4. I don’t mind requiring Customizer being used but I do NOT like all themes being limited to what is in Customizer. I pick themes based on WHAT I can do with the theme to match my content as well as how hard is it to understand WHAT to do as well as how hard it is to maintain. I am dropping themes from what has always been regarded as an excellent theme company because I didn’t like the direction the company was going — focusing on ONE theme in a full year plus with a promise of a new one … soon. The theme chosen is great if you have a complex site but I found it was just too much for what I guess are much simpler needs.

    However, I find a restriction to just Customizer to cut a developer off at the knees. What if architects were restricted to 1500 square feet for ALL future homes?

    Does this decision mean we won’t see “[Name of Theme] Options” anymore? If so, I hate this decision.

    Create forum topic from comment

  5. I really feel with the team of Redux Framework. Too sad, that WordPress.org seems to make “pressure” a lot more these days.

    Dovy Paukstys is totally right, that the Customizer is nice for some styling and colors, but otherwise too limiting. His answers point in the right direction where the real issues are.

    The future of WordPress.org Themes to me seems a bit like:
    under the surface it is (or will become…?) a lot of the same, including the Customizer interface, so themes here become more and more like “skins”. If this is good or bad I really don’t know yet.

    All the migration debate aside, we have to meet a year or two from now and discuss this all again and check the current state of themes and the .org repo, I guess…?!?

    Create forum topic from comment

    • I oppose- that mostly because I’ve been working on the Customize since a very long time assuming this day would come this year (for our upcoming commercial themes).

      At first, I felt same as Dovy- but soon I dive into the challenge, I came to realize the power it can provide. The way customize has been integrated into the core it simplify many many things- the most important of it is that it enforce sanitizing data and the ability to share data/UX from with JavaScript make things very very easy.

      You can do almost anything with Custom Customize Control- and all those things that Redux Framework does can be ported nicely into Customize Control, just need the effort to do so.

      The only limitation I find is that once you’ve few hundreds options/controls- the rendering (for the first load) takes more time and browser freezes sometime if there are heavy JavaScript based controls like ‘Colors Control’- I hope those issues will be resolved coming days- but enforcing from now on is the best decision to get the proper attention from the developer community.

      Create forum topic from comment

      • @Moonomo Redux will soon have an extension that has all the Redux fields in the customizer. So that’s not the issue here. It’s possible to do, but it involves advanced programming and not everything is a good fit.

        I think my concern is what you pointed it. The customizer is slow and freezes the site. WordPress needs to incorporate what we did in Redux, and have lazy loading JavaScript for field controls.

        My fear (as I stated here: https://make.wordpress.org/themes/2015/04/22/details-on-the-new-theme-settings-customizer-guideline/#comment-41167), is that this move will only cause very large customizer panels and painful speed issues because the customizer is not performant as it needs to be for something like this. Also untold custom controls with no consistency in coding because the customizer has VERY few controls.

        Redux already did what the customizer insists on, basic sanitizing. Yes, now it’s forced, but you can easily bypass that with a return function and do no sanitization, just add more empty code…

        I see the hope for progress. I’m not against that. I’m against the limits and the “our vision only” requirements.

        Create forum topic from comment

        • I forget what theme it was but I once came across a theme that had 25 different accordion options in the Customizer. It was impossible to use and did indeed crash like you describe. However, that was entirely because of poor planning and programming at the hands of the developer. Had the developer planned properly, the list of options could easily have been cut in half or even more. The issue with theme customizations is that developers tend to offer too many of them. I think that’s the original reason for the move toward the Customizer – to force developers to simplify their processes. Whether that is the result is a whole different issue.

          Create forum topic from comment

          • Exactly that was my experience- the more I work on it I had to find way to make it simpler. I had to make a group system and put options inside it, thankfully WordPress recently added ‘Panel’ and it was better solution.

            The Customize UI by default doesn’t really look that good- but styling can be improved really and extending customize controls to fit for many purposes yet to be made for everyone’s use- that’s a must do but a not a problem at all.

            Still the concern is that, Customize have to be technically silent for allowing hundreds of options instead of having freezing issues.

            Create forum topic from comment

      • For my commercial themes, the best development in the last years was actually to give up my large options panel (couple of hundred design options in the RichWP FrameWork back in the days). I made the change to the customizer back in 2012 by cutting down to just under 10 options in total. Sales went up and support requests went down. It was a win for RichWP. Feature Creep is so yesterday ;)

        Create forum topic from comment

  7. I agree with Dovy Paukstys. The customizer just doesn’t work for non style settings. I build themes mainly for companies. These companies have specific branding guidelines and giving the theme the ability to change the style isn’t an option. All of that is left in the stylesheets where it belongs, so no one can mess things up.

    With that said what’s the point of the customizer if you don’t allow styling from the admin? None that I can see. It seems like the core devs are taking the “It’s a Blog and Only a Blog” approach to their decision making. You know that 20% of site that WordPress powers aren’t all blogs. I doubt if most of them are, so what keep making decision like they are?

    I don’t see much use for the customizer in the themes I build and I feel like the customizer should actually be a separate plugin, instead of part of core. It’s just adding unnecessary bloat to an already bloated system.

    Create forum topic from comment

      • Yes, there are about a ton things that need improving and updating. Why do they keep focusing on minor stuff and not universally wanted features like this? I say let’s get the core cleaned up and up to modern standards before add extra thins like this.

        Create forum topic from comment

        • With applications that have such a wide area of usage decisions such as this might not make any sense to all of us but instead fit into a long term staging roadmap none of us our privvy to see. Its VERY common. Microsoft’s introduction of WPF (Windows Presentation Foundation) and XAML turned Windows coders worlds upside down and the frustrations were ENORMOUS. But nobody was privvy to the long term reasons back then nor are many privvy to their direction today.

          The WP core that directs that direction of the application are not about to do something like this without good reason or “it makes things easier for users”. They do so as it fits into (I hope) the long term direction that the application NEEDS to take in order to stay competitive in its market.

          Applications that have SO many sites have alot (alot) to consider when building that future roadmap and atop that, the roadmap need be able to change based on technological changes or demands coming in the future.

          Its like steering the Titanic one needs think about where we are 15 miles ahead and not just full steam ahead hoping we dont hit an iceberg.

          When you are stating that the core need be cleaned and brought up to modern standards you really need illuminate which standards we are talking about? Like Object Oriented code? It comes at a price with PHP. PHP works “best” with Arrays. PHP is coded in C++ and objects are not mapped as C++ objects but instead as C++ Arrays with Object Buckets.

          There is quite a bit of overhead in that .vs. know what, use arrays. If WP were converted to OOP code its footprint will be considerably larger. On the other side of the coin, WP properly moved to Object Oriented Code could make it much easier to move to Java or C# or even C++ for Intranets and exhibit significant performance gains.

          Either way… doesnt matter. Decisions such as these from the core do not just happen at least in my 35 years of programming experience. It happens because a long term roadmap requires it. That may mean the customizer will be undergoing significant changes, new functionality… who knows?

          Create forum topic from comment

    • Yes, yes, yes, a thousand times over. Even with all my custom options being available in the customizer I still don’t like working in it.

      Our Runway framework makes every option available to include in the customizer as well as a custom options page, but the customizer UI feels restrictive to work in. It is not easy to scan the options and see what is set and available. I don’t like how it shows the site either. I like having my setting feel comfortable on the page.

      I don’t use the customizer just because it has an awkward user experience that I’ve never enjoyed.

      Create forum topic from comment

    • I would venture a guess that the advantage has to do with the end-user. When a user switches from one theme to another and has to first search for and then learn a whole new set of customization options hidden under some highly customized interface (that often overflows with ads) the WordPress experience becomes a horrible one. Having all themes use the Customizer means any user, whether novice or pro, will know where to go and what to do to customize their free theme.

      Create forum topic from comment

  10. First, Sarah, thanks for the unbiased article. I didn’t know there were many journalistic types left out there who gets that.

    For me, personally, I can’t stand the customizer. It’s bloated, bulky, and to be honest, the UI sucks. Too many flyout panels and the like. It’s like the tab interfaces that plagued Windows shareware back in the 90s; too many makes for a shameful UI. Even with dev modification, the interface can be very confusing to end users who aren’t computer savvy.

    Yes, we knew this day was coming, when wp.org would forbade any and all innovation they didn’t personally put their stamp of approval upon, but this? This decision? No, WAY too early. The customizer isn’t ready for this kind of ‘prime time’. I find the decision to force something that’s not ready on users akin to Microsoft/Google practices. It’s self serving. “Simplicity’ is spoken of, but what I see is anything but! The people in charge of these things speak of ‘contributing’ and ‘making a difference’, but, c’mon, let’s at least call a spade, a space. Inward thinking defines the wp.org dev team as of late. There was a whole debate about it on a certain FB group that got me kicked out, because I didn’t tow the party line. This decision is pure inward thinking.

    Now, I understand the customizer has it’s fans, and believers, and that’s fine. Different stroke for different folks. Diversity and all that. But what this decision has done is not only stifle that diversity, it takes away choices, it takes away OPTIONS. It’s “my way, or the highway”. Now it’ll be ‘customizer, or nothing’.

    Don’t be evil, WordPress. Don’t be evil.

    Create forum topic from comment

    • You are right! that 300px wide panel is narrower than smallest mobile screen available. the collapsing sections and scroll makes things worst. i have kind of love and hate relation with it,

      In one of my recent release “i-excel” i had to replace “option framework” with customizer. New WordPress users love that, may be because of live edit view. But i am not going to change my commercial theme options with that 300px wide panel.

      Create forum topic from comment

        • i am comfortable with customizer except 2 issues;

          1. if setting default value and get_theme_mod default value does not match the live view and placeholder values are not really live until customizer is saved, making things confusing for first time user.

          2. the 300px wide panel is too less specially for code editor and image select, lets say i give option of multiple header and there is a no way i can accommodate screenshots of headers as select.

          for WP.org themes, i can live with that, but for premium themes the UI is just not ok. i hope they will find a way.

          Create forum topic from comment

          • I wanted to comment on these two things because I think they’re easily “fixable”.

            1) That should be easy to control with making sure the theme is using sane defaults. Point me out any problematic code. I’ll help out with it.

            2) The customizer is actually customizable. With some custom code (there’s an enqueue hook specifically for the customizer), you have complete control over this width limitation.

            Ping me on Slack if you run into any issues. I’m sure I or someone else on the team can help.

            Create forum topic from comment

          • Thank you Justin for reply, I need to explore possibilities of customizer more, I will bother you with my quarries if I am stuck.

            I guess many of us are in middle of those few hesitating steps between known and unknown. I am more worried about thousands of existing theme options users who are used to it. It will take some time for everyone to get used to.

            Create forum topic from comment

  12. I really enjoy and choose theme what do this already in Customizer. Its horrible experience for me if I need to clicking and clicking somewhere in menu for any additional setting.

    If somebody think its limited, just check theme Make https://wordpress.org/themes/make/ how they did so powerful and customizable theme with a lot of option and everything is in customizer. That is WP way and its intuitive, simple and it works well.

    This change shows, that Justin and team around really know what they do, thanks for this.

    Create forum topic from comment

    • When the customizer started gaining support I made a theme for a client and used the customizer for all the settings. My client asked me to change it because he thought the new settings were clunky and hard to navigate. He specifically asked to use a settings page like in his las theme, because he thought it was easier to use.

      This is the problem. Not everyone is sold on the customizer, developers and users alike. Why make a draconian decision like this if the community is so divided on it?

      Create forum topic from comment

      • You mentioned that you build themes mostly for companies, are these themes also in wp repository? If you build premium themes for companies you can bloat there anything anyhow you and your client like.

        True is, that if you check majority of themes with own setting, mostly its bloat, links for upgrade and functions which belongs to plugin, not theme.

        Create forum topic from comment

        • You kinda missed the point there. It’s not about for whom the theme is built for. It’s that not everyone is sold on the customizer, and this seems to be a very dividing decision. Those kind of decisions are never good for all parties involved.

          The bigger issue is not that the decision was made to require the customizer for the theme repo. It that the core team made a decision, and are basically saying “Screw you, if you don’t agree. We made this decision, so you can deal or leave”.

          That’s bad for the community overall. WordPress was built on the community of developers and users, but that community doesn’t seem matter much once the core team has made up their mind.

          Create forum topic from comment

          • From my view, people in core team are right people on right place. What WP can do, actually do and how fast improvements are done compared to other systems proof this.

            Community has to be managed/controlled by leaders. If you keep it wild it finish like ThemeForest, just jungle with anything anywhere anyhow … or like Joomla, one year add feature, another year remove feature and after few years funeral :D

            Create forum topic from comment

          • I agree with you. They are the best people for the job and there does need to be leadership, but once you start forcing the hand of the devs who support your system. It becomes less of a community and more of a dictatorship.

            This kind of decision has repercussions far outside of just the theme repo. It’s trying to force a standard use of a system that many feel is not robust enough, not user friendly, and is a general pain to work with.

            Create forum topic from comment

  13. Oh lord, my sides :)

    Mr J armed and loaded. And frickin’ majority voted. Step back from your sh*tty hacks lads!

    Chuckles aside, most of the options found in bespoke settings panels belong in plugins. Them authors were warned. They ignored said warnings. Justin opens a can of sit the f*ck down. Tea. Spilt. Every. Where.

    Best day ever. Thank you Mr Tadlock

    Create forum topic from comment

  14. Glad to know that I’m not the only one who thinks the Customizer is useless for advanced users & admins, and is annoyed at having it forced on me no matter what (Genesis currently uses the Customizer for it’s newer themes if you don’t want to tweak the CSS code in the templates).

    On the other hand, I haven’t used a theme from the repository since 2008, and this may well be a back-door way for the team to clean out the old themes that have been cluttering up the joint while not being maintained or updated. That, and create opportunities for others to build theme repositories and marketplaces outside wp.org

    I don’t mind making things easier for newbs to learn the ropes, but handcuffing the advanced users and developers at the same time doesn’t make a lick of sense.

    Create forum topic from comment

  16. As a designer (not a developer) I’m not happy to hear about this. To me, the Customizer is mostly a waste, and I’d prefer to open up different panels to make my changes, and play with CSS when necessary, rather than getting into the clunk Customizer. My experience with the Customizer is that is seems unfinished, and I just don’t like it.

    I’m sorry for the developers who already have things set up the way they think works best for their themes, and now are going to have to user the Customizer even if they don’t want to. Of course they have the option of not listing in the repository, but we all know that would be a ridiculous choice.

    Autocratic decisions like this often do more harm than good, and sometimes signal the fact that the committees who run these organizations are over-estimating their own importance.

    This decision actually seems like something no one thought about very much…seems almost capricious…and gives the impression that Automattic doesn’t care much about the people who are helping to make them successful…the theme developers.

    More and more we read about how WordPress itself is a very secure platform, and that plugins are some of the main avenues for hacker attacks. With that in mind, why doesn’t Automattic do something to crack down on that problem by setting some rigid standards for plugin developers?

    Making life harder for theme developers just seems wrong.

    I’ve predicted for awhile now that WordPress is near it’s peak, and will soon start into decline, giving way to other platforms, and this might be one of the first signs of WP’s demise.

    The decision to force this on developers seems like some of the other things being forced on people these days, such as some of the ridiculous interface changes in recent versions of OS X, Adobe’s new Acrobat Pro DC, and the incredibly horrible new bookmark setup for Google Chrome.

    Create forum topic from comment

    • I think you may have a fundamental misunderstanding of the relationship between Automattic and WordPress.org. Automattic is a for-profit company that runs a blogging network at WordPress.com, WordPress.org is a non-profit open source project, they are not synonymous.

      If you want to blame somebody, blame the theme review team (who are all unpaid volunteers, mind you), which is one of many contributor teams for the WordPress open source project.

      Create forum topic from comment

      • This is not entirely accurate, it would be wrong to say that changes done via wordpress.com do not heavily effect decisions at wordpress.org. Just look at the inner circle and how decisions over the last 5 years are made, it becomes very evident that there is a lot of influence and crossover.

        It is also important to note if you dig deep enough that wordpress.org is not managed in the same manner as other open source projects, for example with a revolving board of directors.

        /stirs rat nest

        Create forum topic from comment

  17. Hells to the muth freakin yeah!!! Awesome day indeed.

    There is nothing wrong with the customizer. I believe the customizer will now evolve into what its supposed to be, which is the defacto options page for WP themes.

    I think the people who are creative enough will embrace the change and make things happen and, more importantly, make things work. I hope this ends the days of a million font options, a bazillion color schemes and tons of this and that. Excess is not needed in a theme and the ones who are complaining the most are the ones who’s themes are probably very bloated, jmho.

    Anyway, all of the devs talking about not being able to sell more themes, think of it this way. You offer a basic theme, for free, on WP.org with a few simple things offered in the customizer. Then you get to “up sell” a theme with a more “advanced”, heavy duty options page… think about it.

    Great decision.

    Create forum topic from comment

  18. I know this decision is well intended, but I’m not a fan and I think if it sticks it’s likely to backfire.

    First, the customizer isn’t that great. I personally dislike it, and I know a lot of other devs and users do as well. And I think that’s probably the main reasons adoption hasn’t been as quick or thorough as some had hoped.
    – I also don’t think it’s flaws can be “fixed” with more dev attention, as they’re baked in to the design and philosophy of the customizer.

    Second, the customizer reflects a single theme development philosophy. So imposing is really like imposing a single theme development philosophy on all WordPress themes. In my view, one of the strengths of WordPress has been simple core with lots of choice when it comes to themes and plugins. There are so many popular theme frameworks that take different approaches and appeal to different kinds of users.

    Third, I think the attempt to impose the customizer is also an effort to reduce “options growth” in themes and theme frameworks. That’s a big part of the philosophy. But because many market segments *want* options, developers will find ways to provide the options. That means we’ll just end up with huge and complicated customizer implementations.

    Fourth, for those who think this is only about themes in the repository, I’d really question that. The fact is that once something is deemed “best practices” even if the initial basis is arbitrary, premium developers or others outside the repository tend to be held via community pressure to the same standards / approach.

    –
    So I think this really risks undermining the attractiveness of WordPress to devs and users by reducing theme choice and diversity and forcing everyone to use a development framework and user interface that many dislike to begin with.

    Again, I know the theme team genuinely thinks this will improve the user interface for WordPress by making it more consistent. But the trade off is that you reduce flexibility and choice. If you are going to take away choice, you better be extremely sure what you impose is awesome. And the customizer just isn’t there in my view.

    Create forum topic from comment

    • Yup, I’ve been meaning to comment on this. While this is true, and I know the theme team carries a big workload, I’m not sure that streamlining the review workflow is a good reason to make this kind of change. Really, the motive should be what’s best for end users. Ultimately, I know the theme review team thinks it’s both in this case – good for review workflow and good for end users – but I’d probably disagree on the latter.

      Create forum topic from comment

      • If such a decision is strictly made to make the theme reviews peoples lives easier then its a HUGE mistake.

        As others have noted, it is the development community that makes wordpress do all the nifty things it does. Standalone its at best a fair blog platform.

        On the other hand as I noted in another post. If its part of a future WP strategic roadmap then I am good with that as without a future strategic roadmap WP will be somewhere in Wikipedia 10 years from now in a web history lesson as the corporations eat the CMS or Web Interactive Publishing (as i have heard it called) market with no needs for developers, designers or micro firms scratching out their livings.

        I would assume (<— bad word?) that the Theme Review volunteers are not a stand alone operation that does not communicate to the core WP directors. I would assume (<— There it is again) that such decisions come from the top down no matter where we think they come from.

        The customizer may be revamped, already revamped or in process thereof. We simply do not know.

        Whats best for end users is a consistent experience, thats a given. If everytime you switched your Windows Wallpaper on your desktop of your PC the entire user interface was re-arranged folks not be real pleased.

        It'd simply be pretty hard to believe that a bunch of volunteers are going to be able to direct the future of the product in such a substantial fashion. Pretty unlikely. So something else is more than likely afoot.

        Create forum topic from comment

  20. Problem: The customizer has limitations in both UI and real-estate.

    Solution: Develop new UI using WP_Customize_Control and get more creative about how to use the space.

    Problem with Solution: The average update to Core takes a year (correct me if I am wrong) and needs someone to own the Trac ticket while demonstrating the solution is solid in some manner.

    I think the is a step in the right direction, however its too soon and the Customizer is too immature to make it a requirement.

    Create forum topic from comment

    • Problem with Solution: The average update to Core takes a year (correct me if I am wrong) and needs someone to own the Trac ticket while demonstrating the solution is solid in some manner.

      Yeah, you’re way off. Major core releases happen about three times a year currently. This year, 4.2 is scheduled to be released tomorrow, 4.3 is slated for August, and 4.4 is Slated for December.

      It’s true that tickets need a willing owner, but that can be anybody willing to expend the effort to shepherd it. If you really believe in a cause, it’s pretty absurd to stand around and wait for somebody else to realize it for you.

      Create forum topic from comment

    • Solution: Develop new UI using WP_Customize_Control and get more creative about how to use the space.

      Problem with Solution: The average update to Core takes a year (correct me if I am wrong) and needs someone to own the Trac ticket while demonstrating the solution is solid in some manner.

      Did you know that the Customizer is, perhaps shockingly, customizable? A theme (not just a plugin, mind you) can indeed change things in the Customizer around. Such as colors, widths, fonts, and whatever else they like. It’s not even particularly hard to do. There’s action hooks specifically for that purpose. It even has its very own wp_enqueue_script hooks, if you want to fiddle around with it via JS, or just a body class of wp-customizer if you want to hook in some admin styling.

      Theme authors can’t really use “it’s ugly” or “it’s limiting” as an excuse when you literally can change anything and everything about it in the theme itself.

      Create forum topic from comment

      • Sorry, Otto, but I read that as saying “We’ll give you a half baked UI, but it’s up to you to make it usable.”

        I like the idea of the customizer, but it shouldn’t be up to devs to make it usable. That’s just a cop out.

        And devs had already worked out a perfectly good alternative to the limitations of the customiser and built their own options pages (using standard WP hooks and practices mind you).

        Create forum topic from comment

  21. The theme review team is open to everyone. Customizer or no customizer, it’s a real shame that some framework developers dont understand that if their precense and availability to the team makes a HUGE difference.
    To be part of the team is an oportunity to make your voice and opinion heard, and at the same time drastically reduce the time it takes to review themes. I’m not sure if you actually know what we do and how much effort we put in to try and make sure that no broken themes show up in the repository. If you are a developer, how often do you check the themes trac to find common problems with your frameworks? I strongly encourage you to do so, and see how theme authors are using your code.

    And no, you can’t really fire volunteers.

    Create forum topic from comment

    • Carolina: I appreciate your personal feelings and I believe in your genuine desire to help out. I don’t know about other frameworks, but I am very avid on trac whenever Redux is brought up. I have the second most weekly downloaded framework in the WordPress.org repository. I try very hard to work with the TRT, but I feel constantly restricted and generally looked down upon.

      I wish I could really believe that there is room for developers like myself. It just feels like opinions are set, and that’s that. Perhaps with time and further experience I can change my opinion. :(

      Create forum topic from comment

    • Hi Carolina,

      I am rather new to WP development. We are porting some framework code from Joomla to WP towards an unrelated project. But at the sametime the framework is considerably more robust than any theme framework I have looked at in WordPress. It has real workflows cooked right in at a level that is as granular and in some respects more so than Liferay. With an Apache extension we’d made in assembler and C++ it blew the doors off any other Joomla framework in respect to lowering resource usage and increasing sessions and speed. In fact, I just got part of it working with WP the other night, 300%+ performance increase “out of the box” without optimizing anything.

      While certainly we can comply with using Customizer that minor “taters” to us though I can see where others may be concerned. If your team were to look at our codebase there is simply no way you are going to understand it unless they are very seasoned developers. Such a decision as using customizer favors us. But if our codebase would be rejected based on the reviewers inability to understand enterprise level constructs then we may collide.

      Dont get me wrong, I am sure the community understands the hard work you all do as volunteers and appreciates that. Many of these entities do have commercial concerns which is important to recognize. As with any commercial concerns, those entities are often the ones who drive much of the innovations as they are doing so with monetization in mind. A good motivator.

      Their product visibility may decline due to such a decision or the features they offer in their products be limited by such a decision. This can cascade in a wrong direction for the product itself. Its not like there are not a million other CMS platforms that are more capable and would embrace developers even if that means they loosen all controls.

      While again, I and all of us appreciate the hard work you all do its important to also remember at all times that WordPress is a product. Even though its free. That decisions of a product that claims 20% of all websites utilize it is an ENORMOUS responsibility. In helping steer and guide that big ship *IF* the theme review team has the authority to induce such a fundamental change then the responsibility of such a decision should not be based on “The work we must do to review themes” but instead, “We cannot make decisions on something this fundamental without interacting with the core strategic directions folks at WP”. I assume that happened and this is part of their roadmap.

      I am good with that.

      If however it is based on workload, lack of volunteers than the more purposeful course of action would be attempting to get a developer team together to revamp customizer, perhaps scrap it for something better. Then implement such an action so developers/designers are given a consistent and well functioning customization API that services everyone towards the better as well as WordPress itself.

      Create forum topic from comment

  22. As a User the idea of forcing options into the rather cumbersome Customizer wasn’t even a thought much less a priority. It seems to make much more sense to have a separate settings page for theme specific options; it’s not as though it’s that difficult to navigate the Admin Page to find them.

    The differences between themes seem to be being reduced to small variations in layout which doesn’t create much incentive to buy anything new.

    Create forum topic from comment

  23. I hate to break this to anyone, but I should point out first that nobody has ever forced, or is forcing you to use a free an open source platform.

    The only people here that are truly getting upset are the ones who see this as being a monetary loss instead of a gain – a call of conformity for an entire subculture based around this application.

    This is ridiculous that people take this in a negative light. Themes have gotten to the point of having so many “features and options” that they are just cluttered nonsense filled with random cr*P. Why would I need to ever have 3 sliders to choose from in a theme? I don’t even want just one (http://shouldiuseacarousel.com/ :) ).Then think about a “beginner to WordPress.” There’s enough to learn in WordPress without having to learn a completely different system just to use the next hottest theme. It’s gotten to the point where you look at premium themes that are all exactly the same with js ripped off another theme, and a huge options experience (not even a panel anymore because of complexity) that completely devours making sense of anything that they list as a feature. Yes flexibility is awesome! Creativity as well, having a standard for how theme developers allow or restrict their settings is something that I feel has been needed for a long time.

    I used to pump out premium themes on themeforest, and found great ways to make them alluring and unique, but the next week I would see recycled code and a higher price tags because they now include even flashier and fancy jquery plugins on their super mega theme 5000. It’s just ridiculous and has become a game of who can cram the most junk into a “theme.” I will agree with Thomas that Make was a theme that really did give users an expected experience. Good marketing plays a firm role in that as well, but Make brought customizer options into full focus. Most theme developers probably thought it was stupid until they started getting more publicity as well. Their theme is clunky as well, and I would be hard pressed to find a way to defend the customizer as being innocent in relation to that.

    As a developer using an open source tool, I’ve had to come to reality myself on several occasions. It’s an open source community. I love it because I can ignore any sort of life changing decisions involved for a platform that potentially impacts millions if not billions at times. However, it’s nice to know that I can also make a difference and contribute to something that I feel strongly towards. Yes, I’ll agree the customizer sucked, and it still kinda does. However – I’ve seen some amazing things happen with it, and have been doing my own work on the customizer and am starting to have a true appreciation for it. Selecting themes directly from the customizer, (hopefully getting that menus plugin in 4.2 0:| not likely, but I look forward to that as well cough cough), and improvements already made on the api have given it new life. It’s not like there’s a team of people who want to do everything possible to ensure that WordPress sucks. The decisions are based on knowledge, and the goals for WordPress itself. As developers we focus entirely too much on the negative impact we perceive, and forget about the millions of other users who ARE NOT DEVELOPERS. Don’t get angry at a decision that is meant to only solidify an open source platform. Even if 20% of ALL WordPress users are developers according to made up numbers I’ve read in these comments – then what impact would that have if they all just left? Not a huge amount in the overall picture of things, it’s a minority – and I would really not strive to go far out of my way to even say that 20% of users are developers because I doubt that.

    Having a standard IS the WordPress way, so it’s about time that theme developers were subjected to conformity. It’s not just with silly js or php formatting, or clear and concise commenting which a vast majority of plugin and theme developers don’t seem to give thought to, but just the overall inconsistency that themes have brought WordPress over the years has really been a key component that has caused WordPress not to progress in certain directions.

    When all is said and done, you don’t have to ever have your theme in the wp repository. In fact most people shedding this situation in a negative light don’t even seem to have a valid case as to being so anti other than it seems trendy to be anti-something. Nothing prevents you from forking an open source platform, forming your own community, and setting your own rules – does it? Even if you don’t agree with what an open source community says, you’re a “developer” and can just create your own tools and solutions. Why use something that you feel so much negativity for when a decision is made? If you truly love what WordPress WAS, and feel like it HAS become something it shouldn’t – then voice an opinion by not just complaining, but actually actively contributing towards it. If you not only proposed why something is bad by ranting about it on websites, but wrote code for the solution, and documented why the solution is effective in resolving the primary concerns addressed originally and the new concerns that have risen – then it would probably be perceived a lot better than a bunch of whiney people upset about a decision that impacts their “hardcore development.”

    This really comes down to people being upset because they were able to make money for so long by keeping things a bit more “complex.” WordPress has always been a platform that was built to just keep being better because it has a strong community behind it. In recent releases and changes made all over the core, ui, editor, and much more – it keeps doing just that. It keeps striving to become better. The overhauls that have been going on are different, and it’s mind blowing to see things are being done to improve not only the user interface, but user experience and ease of use….? I would definitely urge anyone with negative things to say about ‘forcing’ the customizer on developers to give their own way a shot.

    There’s also something generally referenced to a plugin as a feature. If anyone has a great idea – again, wrap it up in a plugin, propose the feature, and let people say how much it sucks or how awesome it is. That’s the kind of stuff that sways a decision and impacts the community. If something is well thought out, easy to use, and done correctly – then why say no to that feature.

    I would opt for the customizer over anything because it’s blatantly clear for anyone who does development with WordPress, pays any attention whatsoever to the slack channels, or even reads trac tickets which most of us developers should be well aware of from our own journeys – that this is the direction WordPress is going in. It just makes sense, and it’s more about making sure that the application provides a pleasant user experience. Ultimately as a developer – you should have the similar goals as anyone who works on the core or makes any decisions. Programming is about automation. Performing tasks that are ordinarily redundant or hard, and streamlining those processes to end users. Just because you think that this is a shot at developers all over the world and that a system has let you down – why don’t you stand up for your belief and not just voice your opinion which all of the world seems so good at doing, but make a difference? People in these comments have said that the decisions were made by such a tiny group of people that it’s not fair? Why don’t you join that group of people? Why didn’t you voice a solid and unshaken method of change? Too busy? Don’t care enough? Care too much it hurts?

    What is chosen to be or not be in the repository is completely up to the teams that manage them. An application of this proportion has to have leaders, so saying that it’s not fair for a leader/group of leaders to make a decision is also beyond incompetent – and actually it’s just downright retarded to say. If anyone thinks they could make a better decision, I’d welcome everyone to go to the WordPress slack channels and get involved. It is an application based on the community, and if 20% of said community is against something, and 30% is for it while the other 50% are just unsuspecting sheep – then I’d say the choice in favor of the majority sounds like the right choice. They could turn around and say we only accept themes that were made while sitting in a sandbox filled with raw chicken corpses, and to provide photographic evidence for all I care. Hell, I might even do it if I’m feeling frisky.

    Point is that no matter what decision is made, one way or another – people will be happy, and people will be unhappy. It’s like part of life or something like that.

    PS – Dovy, Redux for example, I love it, and use it all the time for projects. I would be excited to see what is offered by redux directly available in the customizer (with slightly more estate, and of course not a huge lag). I however don’t ever want a client to use redux. It’s unwieldy, has an ugly interface for it’s settings, and without providing a user certain restriction, gives people who know nothing about WordPress way too much of a chance to mess things up. I still love it – and not knocking it because it works for it’s intended audience just fine. Despite the fact that this decision was made, Dovy, I don’t think your current monetization structure will really be horribly impacted and I encourage you to continue the good work. You developed a plugin, and it’s more commonly used by advanced users who are acting as a developer to their clients anyways. I would be upset in your shoes, no lie, but I also would suck up enough dignity to not try and emotionally swoon people on a blog. I would instead look at what it is you COULD do to make this change beneficial to your own company and business model. I am sorry though, I generally feel the same as you when talking to certain people who act as if they are better than everyone else on WordPress channels, so i know that “not welcomed feeling” and I’m sorry that you feel as if this decision will be negatively impacting you.

    Create forum topic from comment

    • Guessing this decision would come and there would be such reaction, at Nov 15, 2014 I shared the official announcement named “Toward a Complete JavaScript API for the Customizer” with following text: “Winter is coming to WordPress”.

      It just hit the wall now- ;)

      Create forum topic from comment

    • Tim:
      I have no concern at all with encouraging the customizer as much as possible. I’m simply saying it’s a bit extreme and limiting to require everything in it. Again, I could care less either way. My code will work in the customizer soon enough. I just wish there wasn’t such a strong hand to this and more effort was put into making it a better solution for adoption. ;)

      And I hardly would consider myself whiney as much as wanting actual developers to chime in. Change only occurs when people are aware of a concern.

      Create forum topic from comment

  24. This new requirement is extreme.

    There are options that are inconvenient to adjust with Customizer. Customize color, font choice is good when there is a realtime preview. But there are options for which is not necessary preview.

    Require the inclusion of all theme settings options in Customizer is too much.

    Create forum topic from comment

  25. I fully support the decision to require theme authors to use the customizer for their theme options.

    I was at this point back in 2012. The years before I developed the RichWP FrameWork which came with hundreds of design options, sliders, galleries, etc… but as soon as the customizer came out, I knew that this had to change. First I tried to convert my old options panel into the customizer, but soon reached the unavoidable limits. I then started to built new and much leaner and faster themes with just enough options to appeal to the masses.

    This step had proven to be very successful in overall sales as well as in a huge drop of support requests.

    To sum it up, requiring the use of the customizer will instantly improve the usability of a lot of option heavy themes in the repo and it will enable new users of a theme to understand the given option panels instantly.

    It will also force authors to makes option rich themes more elegant and come up with a smarter options architecture and as Justin let us know, there is room for innovation. If you come up with something truly great, then there will be exceptions.

    Create forum topic from comment

  26. If I’m honest I can see both sides of the argument. I am all for simplified solutions and consistency across themes, but I can’t say the Customizer is the place to do it. As many before me have said I see the Customizer as a visual tool, which means framework settings for SEO, blog settings, currency selection etc will have no relevance to live preview. In fact it will slow things down far more than necessary.

    I wouldn’t say this will harm WordPress as a products, I DO believe that many theme authors who would have offered themes for free through the .org repo, won’t bother anymore. This could see the rise of more third-party free marketplaces that don’t require the use of Customizer, or more people opting to sell their themes under a commercial version…

    …one step away from it’s Open Source roots.

    Create forum topic from comment

  30. Because this post popped up in the wp-admin dashboard on our company site, I popped across for a read … and for the first time ever I had a look at the Customiser (BTW guys – there is no “Z” in customiser or customise – perhaps the typo has put me off from looking at it in the past?).

    My reaction to the Customiser is ” mehhh ” – everything it offers for me to customise is available in the default WP Appearance and Settings sections’ screens.

    To me, customising a theme is all about creating a child theme and then messing with the underlying php and html.

    Some of my best performing sites (and most favourably commented about) still use themes that were released pre-WP 2.7, which had their core files hacked about to fit needs. With the exception of editing WP function tags to overcome deprecated functions, they’ve never needed further development or customisation to operate with later versions of WP, and certainly would not benefit from activating the last few years of bloatware added to WP.

    Personally, I am very much in favour of keeping things simple … so, Justin, here’s a thought for your TRT –

    Up to the last pre-WP 3.0 version and prior to TwentyTen theme release, I could hack and modify any theme’s files directly alongside the best of you. Since the “coding standard” introduced with TwentyTen I simply don’t have a clue how you’ve all structured the coding and have all but given up using themes released since then.

    Roll it back guys, go back to your coding roots before introducing more horribly arcane and mystic coding standards.

    Create forum topic from comment

    • Customize (with a “z”) is commonly used in the USA while Customise (with an “s”) is commonly used outside the USA as used by the British. Not sure where you are located, but the Customizer name is not a typo.

      Create forum topic from comment

    • Judging by your website, you’re in the UK, and so most likely seeing WP with the British English language files. One of the few changes in those files is to change the default (en-US) Customizer to Customiser. I think en-CA and en-AU copy us Brits too.

      If you’ve never seen it written with a ‘z’, and seeing it with a ‘z’ looks wrong, then we’re doing a good job with the en-GB strings :-)

      Create forum topic from comment

    • Personally, I’m right there with you. Hacking themes back in the day is how I got started. I’d love to see theme authors take a few cues from the old days.

      The theme review team wasn’t involved with Twenty Ten or the other core themes other than individual members adding a few suggestions here and there of their own accord. The folks who work on the core themes are actually a separate group of people.

      As far as this guideline change goes, it probably won’t change anything for you. If anything, it should at least standardize some of the different theme options code you might’ve come across.

      Create forum topic from comment

  31. There would have been more appreciation of that decision, if it was supported by a Theme Customizer with a lot more control classes in core. But I am confident this will change soon.

    Also a more in-depth announcement about such impactful changes, together with the ideas and long term vision behind them etc., would greatly benefit its adoption, and help people to really understand the decision being made, rather than getting lost in confusion or even turn to hatred.

    I use Redux, and rejected this decision at first. I don’t count myself a fanboy of the current Theme Customizer, especially when it comes to more complex themes, yet! But giving this a second thought I discover more and more benefits of this “enforcement”, which makes the non-dev/end user life easier. Which is what we should focus on, anyway, all the time.

    Benefit #1 – CONSTRAINS
    (addresses and hopefully avoids theme bloat)

    I can see and support Dovys point about the lack of real estate in the Theme Customizer. Although themes such as Make and Layers inspire how one can arrange plenty of options, and spark ideas on best practices, that are yet meant to be established.

    For everyone who cares about UX this restrain provides great opportunity to reconsider what options need to be packed into a theme, and to distinguish between:

    – what is really necessary
    – what is nice to have
    – what is actual bloat

    But that of course depends from what perspective you look at the “problem”. If you are only worried of the amount of work this equals to, then this is terrible news.

    If you already stuffed dozens of options into your theme, adding another ten, and a month later another, doesn’t seem like a big deal, right? But it actually is. You see what that leads to..

    Because where do you draw the line? When do you decide your theme has enough options? If you embrace the “more options = more flexibility” mantra fully, I would say, you simply don’t draw any line at all, and that is a problem, or soon will become one. As it will be more difficult to use your theme as time goes by and options increase. Which the current panels encourage and make so easy.

    No matter how smart you arrange the Customizer in your theme, it requires a more thoughful and deliberate setup due to less real estate, which is something we should learn to embrace. The end user will thank us.

    – –

    Benefit #2: CONSISTENCY
    (little to no learning curve for the end user, less frustration setting up a theme)

    If you are aware of WordPress’ overall strategy, this change shouldn’t come as a surprise.

    To take over the web, you have to develop a CMS, that can be used by the majority of people.
    And last time I checked those folks aren’t devs or anything alike. They change themes like underwear, and those are in need a consistant user experience.

    You don’t want to switch themes and spend the entire weekend to learn the new theme. No thanks. Goodbye WordPress.

    Keep in mind this change only affects wordpress.org. If you build premium themes or do client work, you can happily continue doing pretty much whatever you want. And I highly doubt that ThemeForest will enforce this change in the foreseeable future. Anyone up for a bet?

    – –

    WordPress isn’t the little blogging platform it was 12 years ago. And to make it appeal to most people, that want to run a simple website, more and more standards have to be established or “enforced”. Whatever it takes or how you interprete it. If a few devs leave the boat, who cares. Which they won’t do, anyway.

    This change won’t be the last of its kind, I am sure. So be prepared, and adjust your expectations, especially on wordpress.org

    If you want to develop for something that feels more “Open Source”, please do so. No one is stopping you to fork WordPress or from building your very own solution. But of course this won’t provide you with the exposure you get when developing for WordPress. It’s a tradeoff, and only you can decide what do to about it. But please, please..

    Stop complaining without substance.

    Most people that are concerned with this decision have to swallow this pill at one point or another. The sooner, the better. While you still complain and express how little you like this decision, the rest of us looks at the upside, and happily moves forward, building the future, with WordPress.

    I need to get more popcorn now..

    Create forum topic from comment

  32. Imagine if your iPhone had just one level of settings with no conditional options, place for bigger images, no full width fields, and only a couple of “Controls”. That’d suck right.

    It’d be way more better for wp.org to attract developers to use Customizer, rather than “force” them to do so. Or atleast before taking a decision like this, make sure there are alternative controls for all the controls offered by popular frameworks like Redux, SMOF. I know it’ll get better with time as more developers contribute to Customizer, but then what’s up with that 6 months time limit?

    Create forum topic from comment

  34. I know this decision is really controversial and a lot of people don’t like it.
    To my eyes, this is something good for the future of WordPress. Providing a consistent experience to everyone can only be considered a good thing.
    The customizer is really powerful and not many people realise just how powerful it is and what they can do with it.
    Most of the complaints I see here are that people don’t like its UI/UX. So… why don’t you guys try to improve it?
    There are some really wonderful things you can do with the customizer and further extend it.
    The customizer has panels, sections and controls. If you really work on it you can add tabs and sub-sections just like the guys behind https://wordpress.org/plugins/easy-google-fonts/ did (if you haven’t already seen it, check it out… it’s brilliant!)

    About a year ago I started extending the customizer to add extra controls and the result was the Kirki Framework: https://github.com/aristath/kirki or https://wordpress.org/plugins/kirki/ on w.org
    It’s not perfect and I know that. But it’s a way to use advanced controls if you want to take a look at it and help its development.
    I suspect a lot of people will turn to solutions like that now that they have to use the customizer.
    Its main problem right now is that it doesn’t work with PHP 5.2 but we’ll fix that. :)
    Don’t get me wrong here, I LOVE Redux! I believe it depends on what you want to do… If you have a few options then using the customizer is easy.
    If you have 100 options then you can again use the customizer with careful planning and proper structure.
    I’m not going to debate whether having 100 options for a theme is right or wrong. I believe in the “decisions, not options” moto, but I understand not everyone feels that way. That’s why there are themes out there with more than 300 options (not necessarily on w.org… I’m talking about other commercial themes).
    In those cases, option frameworks like Redux, SMOF, Titan and others can really be useful.

    There’s the right tool for every job… Themes control the appearance of a site. It only makes sense to use the customizer with its live preview in all its glory for themes.

    The decision is made and for the future of WordPress themes I really believe it’s a good decision. Our job as developers now should be to improve the customizer.
    Don’t like the customizer? Why? What is it that you don’t like? What could you do to improve it? Why haven’t you done it yet? Perhaps now is the time to start working on it.

    Create forum topic from comment

  35. I understand that the decision to use the customizer only has been made in order to standardize things, and I agree with this. But i don’t agree that every single option should be into the customizer.

    I personally like the customizer, i like it’s current layout because it makes sense that when you customize a theme, you want to see your changes live. That’s a perfect reason to have all layout/colors related options into the customizer.

    As of now, i don’t see the customizer as a solution to modify every option of a theme. Options that don’t modify the layout, or options that don’t have a visible effect within the customizer preview, shouldn’t be part of it. To me it doesn’t make sense having those options there because the user can’t see what happens.

    Create forum topic from comment

  36. Delighted to see this decision made official, I really hope it sets a precedent and we see other theme directories / marketplaces following suit.

    Now that we have a standard that we can all rally behind, rather than a splintered group of options we’ll hopefully see the Customizer grow and improve very quickly.

    Most importantly I think this will bring themes focus back to where it should be; delivering the visual layer for a web site. Generally speaking, if the Customizer can’t handle an option you want to add, then it probably shouldn’t be in the theme in the first place.

    Let this be the beginning of the end of the ‘kitchen sink’ themes.

    Create forum topic from comment

  37. As I started before, one you wrap your head around the customizer, adding options is easy and like James pointed out if you can’t put it in the customizer it probably shouldn’t be in there to begin with.

    That’s what plugins are for. So all the devs with kitchen sink options, why not put those options into plugins and sell separately. This way users can pick and choose what they want, when they want it and not have an overly bloated theme.

    Create forum topic from comment

  38. Given all of the extension and framework comments I have a question.

    If a theme uses a framework or plugin to extend the customizer will it be accepted at .org? Will the reviewers install the required plugin when they review it?

    Create forum topic from comment

      • stating that the TRT tests themes without any plugins, whilst sting that functions that don’t fit in the customiser should be ported to plugins, is a sure fire way to piss off developers … not to mention that it could encourage removal of the “open” from open source by forcing themes off wp.org

        Is this the beginning of the “dark Press web”?

        Create forum topic from comment

    • Themes must function correctly without any plugins installed. However, they may recommend (but cannot require) plugins that they integrate with, such as BuddyPress, bbPress, WooCommerce, and even an options plugin.

      The theme review team will not review the theme with any recommended plugins installed unless the specific reviewer just wants to do so.

      Create forum topic from comment

      • @justin – Thanks for your reply, I am hoping you can help clear up some confusion for me on the new policy.

        If the customizer doesn’t offer the functionality or the fields I need, I have to extend the WP_Customize_Control class and anything else I need to accomplish said functionality. Once I do that, I have to put the code in my theme in order for it to be seen and used by the review team; but what if the code legitimately belongs in a plugin? Does that mean that this new policy is going to dictate what code goes into a theme and into a plugin?

        If this is the case, will we start to see more bloated themes with frameworks/libraries included that have no way of being updated unless the theme author updates the theme? Or is it that we are expected to spin up our own custom extensions for every theme created to avoid this problem?

        Create forum topic from comment

        • This new guideline doesn’t dictate what belongs in plugins. We have existing guidelines that cover what the team considers plugin territory.

          As for bloated themes, we already have that problem. We have some guidelines in place that help in that department. Ultimately, I think the only way to really fix the bloat issue is by ongoing education.

          There are times when it makes sense to use a framework/library and times when it doesn’t. Personally, I’d like to see libraries geared at handling specific controls that aren’t default to core and nothing more. Or, if not a library, I’d like to see a Git repository that theme authors can use to get controls that they need for specific themes. Those are just ideas I have in mind. I imagine we’re going to see a lot of experimentation in this area.

          Create forum topic from comment

  39. For all those critiquing ‘kitchen sink’ themes, I just want to add two thoughts….

    1) Option rich themes are immensely popular. Many of the most popular themes in the WordPress landscape are option rich, “kitchen sink themes.” They are popular because a lot of people like them and want them. There are literally millions of WordPress users – it may even be a majority – who’ve looked at all the themes available out there and decided they prefer option rich themes. While we’re all entitled to our own preferences, I just think we should think twice between taking a single set of theme preferences and imposing those on the entire community of WordPress users, many of whom have demonstrated through their own theme choices that they disagree.

    One of the reasons WordPress is popular is that it has simple core plus lots of choice via themes and plugins. The real keyword is choice. Themes are a choice. If you don’t like option rich themes, you don’t need to use them. But it seems odd to me that we’d try to prevent millions of people who do like them from using them.

    2) On the same note, there may be misunderstanding of market demand and supply at work here. Many seem to assume that kitchen sink themes are a “supply” problem. That is, devs shouldn’t make them, and if we make it harder by imposing the customizer, we’ll limit the supply of option rich themes.

    But that assumes that demand responds to supply for this sort of thing, which is mostly backwards. As long as there’s demand for option rich, kitchen sink themes, developers will continue to produce them (as they should). So if the customizer is imposed as a new norm, all those options *will* get packaged into huge customizer implementations. As long as the demand is there, supply will follow. Trying to mandate away demand never works.

    –
    And while I’ve said this already above, for those who say this only applies to WP.org repository themes, that’s really not true. What’s happening here is a discussion about what the standards will be for theme development in the future. If there’s a pseudo-formal determination that the customizer-only themes represent “best practices” (even if that’s somewhat arbitrary), that will become the standard and there will be strong pressure for all theme developers, not just those on the repository, to move toward customizer-only themes.

    The result – sadly – will be huge and needless loss of choice and diversity.

    Create forum topic from comment

  40. Hi Maria – The main point I’d make for the current discussion is that the goal of the proposed change isn’t to encourage option-panels-via-plugins. It’s an attempt to do away with options panels entirely and shift WordPress themes to customizer-only options.

    As I noted, I don’t think this is just a discussion about the WP.org repository. It’s a discussion about what the community will consider to be the standards and best practices for themes going forward.

    If this becomes the norm, then any developers still using options panels in a year or two – whether via plugin or built in – will face strong pressure to adopt the customizer because it’s “best practice.” Even outside the repository, public criticism from WP influencers (even if they are not representative of the WP user base as a whole) is a very effective device for achieving general compliance.

    So in my view, this change opens the path for the end of most theme frameworks and even most powerful individual themes as we currently know them. They’ll be replaced by themes that all have a similar architecture and interface, with a fairly similar options set via the customizer. Hence loss of choice.

    For what it’s worth, I’d add that I don’t think loss of choice should be surprising here. The stated goal of the change is specifically to impose “consistency” across WordPress themes. “Consistency” is the flip side of “loss of choice.”

    Create forum topic from comment

    • Your right.

      But loss of choice is a historical factoid in just about everything that has to do with mass market. With one comes the other, one is that natural progression of the other and it does not matter what the “market” gets coined. Progression happens through innovation. Innovation is then re-ordered and structured. You can look at any technology and find this. Cars, TV’s, Computers on and on. Even food.

      Most consumers want consistency over choice. Of course, they would like nothing better than both.

      They can have this in software or in this case WordPress.

      Windows or Mac OS or Android or iOS have applications. The UI’s to said applications is “built in” and extensible as well as constrained.

      Notice it hasnt slowed forward movement.

      What it has done in make for a consistent experience for users and developers. Has freedom of choices been limited due to it? Yes. Do the users care? Uh uh. They embrace it. Do the developers care? Those that were making dough off being different get pissed and those that realize and seize it as opportunity go “Yee ha”.

      As I said in another post, look at the history of Windows Form applications .vs. Windows Presentation Foundation, the screaming here is far smaller :)

      WordPress needs rich ui “out of the box” front and back end that is consistent. There is just no reason someone who operates a recipe blog site and a country living blog site who then wants create a full blown news site providing a rich experience to their users and those who run the place should get a theme and go, “Golly… There is more to running this theme than WordPress itself”.

      “Oh my gosh, we want make some layout changes and now we have to add a plugin where the user interface is again more complex than that of using WordPress”. These are things that can KILL an application such as WordPress. Right now, WordPress thrives because USING IT IS EASY from the standpoint of WordPress itself. Its extensible so people with small skill sets can do really neat things.

      But WHAT or shall I saw WHO are the competitors? Joomla? Pretty hard learn for a webmaster to cope with. Disaster in as far as usbaility. Disaster in workflows. It is THE DEVELOPERS CMS as no human being that “I can use a computer” will enjoy using it.

      Drupal? Probably the strongest of the three. But making it “all friendly” is like taking a garbage can and sifting through it “Where are those fishbones?”

      WordPress enjoys marketshare because it is easy peasy. It needs to stay that way BUT also be consistent even if that is at the cost of some loss of choice.

      Thus the sensible things to do is provide the user the consistent experience at all levels, themes, plugins, widgets. And provide the developers/designers the rich tool set to do so which customizer currently is not.

      Create forum topic from comment

  41. In reality theme frameworks (even ours albeit also having tightly integrated function providing real workflows in the front end) should not be as prominent as they are. Many options should be in the Theme customiser already and simply be available for use by Theme designers. Rich tools should be part of the wordpress core or a fork off it. This is the same for visual drag drop layout. That should be built in or getting built in as that IS the future.

    There are all sorts of sketchy zones with all of this.

    If such decisions can be made by volunteers and not passed through the WP core and approved, thats a really really bad precedent to set both in community and quite frankly from even a legality standpoint. It would mean from that direction John Q Public sets up a repository lets say, themes, and all of a sudden starts laying down goals and a plan using the precedents WP core allowed as defensible ground, and it is. They could very much so loose control.

    For a user’s end consistency and the ability to readily change their sites be that layouts on pages to colors etc easily and consistently is important, very important. Using a Javascript API built into WP needs to be there. WP can have the most impressive sites on the planet in as far as looks go. Doesnt matter. The future is drag, drop, set properties, make associations and publish. Anything OTHER than that base functionality in scant years will relegate WP to loosing marketshare and eventual extinction.

    That IS the future, like it or not.

    People dont realize whats coming. Windows, Mac OS will be client server, online deals. Devices Smart terminals. Thats a ENORMOUS change. Web Browsers as we know them will completely change as will many web applications. Thats the future, thats where industry is headed.

    I would “Suggest” to the WP core a strategic roadmap along the lines of:

    1. A development team to create a new Customization API for WP. Staying backward compatible for two years time. I am talking the whole shebang. The backend UI of WordPress. In various areas, Themes, Plugins, Widgets, take whats most commonly done in frameworks and some of the better concepts, incorporate those as register enabled features a designer can turn on or off in theme or plugin development. Separating “component design” from function. It needs to be drag and drop friendly across the board with flexible layouts. So a theme creator makes “structure” and a user can build layouts within it.

    2. The customization API’s MUST be extensible.

    3. The php code enabling all this functionality needs be rather “standard” Object Oriented Code as does the core code. Allowing for the customization API to be ported with relative ease to other languages such as C#, Java etc. Having all one’s eggs in one PHP basket is not a good plan for longevity. Other language technologies as the Web moves towards smart device unification will more than likely outpace PHP in significant fashion.

    4. Towards that end get yet another programming crew working on exactly that. Getting WP itself into a object oriented format that can be fairly easily ported and is done to enterprise standards as again, thats whats coming.

    In other words, sort of “suspend” the present product lifecycle and maintain it. But work towards “WordPress 2” and get people on board from the community that are not all self-interest. I for example realize without WP moving towards whats coming down the pike its just dead. Its going to seem like “DOS” .vs. “Windows”. Folks can already see this in web.com, Wix, Weebly and those are MUCH more basic that what is to come from the money players at Amazon, Adobe, MS, probably Google (only one I hear yea’s and neigh’s about). I already saw video of Adobes and believe me, its just no comparison what so ever. ANY person wanting a web presence, business, commerce, blog site will go “I want that for $15 a month” vs Joomla, WP, e107, Magnolia etc.

    5. The key here is how to move WordPress as a product into the future of what is coming which is “Online computing”, not android or iOS phones, tab’s, laptops, PC’s. Its they are smart clients. Nothing more, nothing less and NOT loose marketshare but instead GAIN marketshares. The developer/designer community is ancillary to those goals. Dont want loose them but at the sametime them being around or not does not change the future of smart device unification, cloud based everything and the transition that will happen. Its not an “IF” deal, its when.

    Those that know this (I do, 110%) and realize without changes in that direction WP, designers, developers are dead need set self interest aside and work on getting WP where it needs to be in codebase / function with a codebase that is either rather easily portable to other general purpose languages that can scale, are faster, more robust than PHP or even just start there “out of the box”.

    All this huhbub about customizer is sorta silly. I mean, how hard is it to use? Easy peasy. Its limitation is more one of screen real estate than anything else and thats rather simple to conquer through something as simple as say Modal windows.

    It does NOT solve the user experience problem. The user experience in an application that has 20%+ of all websites running it should be VERY consistent. Period.

    Like I said in another post. How would any of us feel if we changed our Mac or Windows Wallpaper background and our desktop color theme only to find out, “Gee… Now I have to learn how to use my computer all over again” as the UI gets turned upside down with that change. Now tabs become accordians and drop downs become radio buttons on and on. Be pretty upset wouldnt we?

    There are developers/designers that do things freely. There are those with commercial interests. There is WordPress itself and their interests and the user community.

    Without the last two the first two cease to exist.

    Thus its of utmost !important that the first two put the last two FIRST. Not self as that is what is good for “all”.

    That roadmap from where WP is to where WP needs to be in order to position itself for a long life needs to happen now if it has not already. When I heard WP is talking to Microsoft that was the FIRST thought that came to mind. MS is meticulously brilliant at it.

    So instead of us all beating up upon this new situation why dont we instead say, “Ok. INSTEAD of JUST this lets get some folks together that can SET self interest aside to a reasoned degree and talk about how to take this wonderful little WP application and move it forward so it does not end up in wikipedia as a remember when. But instead sets the MARK that other platforms look to trying to play catch up”

    Create forum topic from comment

  42. After spending some time whipping up a customizer page I am left wondering how people consider this easier than the Settings API. You don’t have to write CSS/JS or Object Oriented PHP to use the Settings API but you do in order to use the Customizer? Is this an area of WordPress lacking helper functions?

    Create forum topic from comment

  43. I’m the developer of OptionTree and I’m 100% OK with this specification. All I’m taking away from this is that themes must not include the plugin in their core, and work without the plugin activated. It doesn’t mean you can’t use an options framework. It’s really not the end of the world.

    Create forum topic from comment

  44. In an aside fling. I was stumbling through posts at WP about all this.

    One of the TMT (thats not Teenage Mutant Ninja Turtles, but Theme Management Team) was stating they’ve been trying to define for years what a theme is. And frameworks/plugins dont represent that.

    Really?

    Themes are WRAPPERS that in the world of PHP usually use a template engine (such as Smarty which has been around forever) to KEEP code (logic) and presentation (theme) separated. Simple.

    In the rest of the known universe outside PHP (ASP, Java) Themes are Themes. Not wrappers.

    Razor is a templating language that allows complete separation of code and presentation, its fast.

    WordPress doesnt do that.

    Instead we have hooks, we have filters, we have actions, we have buckets of functions we have “the loop” which immediately breaks all concepts of separating logic from theme wrappers.

    In reality, what we should have is “the data” from a query and all supporting query data on the page. For example, plugins data. We have a rendering engine that feeds a template engine.

    I get all the “lets be consistent for users, again, a theme shouldnt be more complex to use that the platform using it!

    In the same sentence however the codebase that is core does not in any way shape or form lend itself towards separating theme from code/logic. Not in the least. Quite the opposite in fact.

    Customizer doesnt solve that. In fact, it probably makes that particular area worse not better as I am certain some other coders have said.

    Heres what we really have:

    WordPress is in ITSELF a framework.

    Themes are what you see in Windows. Change your desktop color scheme, backgrouns and pluthers of other nifties WITHOUT ever affecting function.

    Themes in WP which probably should not even be called themes but instead, what they are, wrappers, are apparently not in favor of lots of options. Options are fine. Consistency in using them is whats important to end users. If a theme (wrapper) relies on plugins or externals how does that make it any different than WordPress itself which is a Framework essentially.

    This is not the fault of developers. If WP wants to enforce more modern constraints such as separation of code and logic, by all means. But that starts at the Framework that is wordpress .vs. placing it upon designers or developers that never made the decisions or had the input apparently on such issues. Yet, those developers and designers work be it free or commercial are the only reason WP enjoys its #1 market position.

    So lets all be straight on this. Its ok to use pluthers of core code in a theme (wrapper), but its not ok to use your own code that extends what the “Wrapper” can do which is in fact WHY WordPress has become the #1 blog/cms?

    Am I missing something?

    Create forum topic from comment

  45. Looks like the pace of commenting here is slowing down. I have to say that based on replies I’ve seen from Justin, Chip and others – here and elsewhere – I think the discussion is kind of moot anyways. This is pretty much a done deal. They’re managing the reaction a bit and waiting for the initial bump to pass and for others to resign themselves to the new reality.

    For the record, I’ll just say I think this decision does long lasting harm by undermining what’s been a remarkably vibrant WordPress theme ecosystem. It makes me sad.

    Create forum topic from comment

    • To Justin, Chip (whom I’m not sure is still on the TRT), and the rest of TRT – I’ve obviously expressed my disagreement with this particular decision. In case you or others tend to read my words harshly, I just want to reiterate as I did in my first comment above that I know you all log a lot time in a volunteer capacity, and have made huge contributions to WP both via the TRT and in other ways. By dedicating your time and accepting ongoing heavy responsibilities, you’ve also put yourselves in a position to have a bigger say in things than most of us.

      I also know reasonable people can disagree about this particular decision, and I do understand the desire for consistency in user interface. I just happen to think that when you weigh all the factors here, the drawbacks of doing this greatly outweigh the benefits in terms of impact on the WP theme ecosystem. I also disagree, I think, with some of the underlying philosophy that’s driving it.

      Regardless, I hope you don’t take the disagreement on this particular issue personally. You all are good and talented folks who do great things for WordPress and I generally really admire you.

      Create forum topic from comment

    • Yes, this decision is a “done deal” as you say, at least for the moment. We had a unanimous vote among team members to make this change to the existing theme settings guidelines. We’re all still in agreement. We plan to see it through. With that said, nothing is ever set in stone. Guidelines change over time as we see what real-world effects come into play. For example, with the upcoming WP API, a whole new world of possibilities will open up. I’m 100% certain that we’re going to see some innovative ideas that we haven’t accounted for yet. And, that’s OK. We’ll cross that bridge when we come to it.

      This decision was made based on the current evidence we have. That’s why our team agreed to this. We get to see so much more than just a single person or a single company. We’re certainly not “all knowing”, but we do get to see this thing from an entirely different perspective than others. We think this will benefit the themes in the WordPress.org repository.

      I was actually one of the people to fight against this decision three years ago when it was first proposed. I didn’t think it was time. There’s not a single argument in any of the comments that I haven’t either thought of myself or haven’t heard in the last three years. Not a single one.

      Guideline changes are rarely loved by all. This isn’t even the most controversial. It’s probably just the most public since it was broken here on WP Tavern. We regularly have debates (often much more heated than here in the comments) among the team. It’s fortunate that these take place over the Internet. Otherwise, some of them might have resulted in fisticuffs. At the end of the day, we all have one goal in common: we want users to have access to awesome themes from the directory.

      Some of us have to take a little heat personally. It goes with the territory. You’d be amazed at the amount of hate mail sent sometimes (not just for this decision but others as well). That’s one of the reasons we kind of stand back a bit and let things settle down. The other reason is that it’s often a “damned if you do, damned if you don’t” situation. It wouldn’t matter if we said nothing or presented the most rational arguments ever made in a debate. At least saying nothing at all means you’re not fanning the flames.

      Before this turns into an entire essay, I just want to say that we read all comments. No one’s voice is going unheard.

      Create forum topic from comment

      • 1. WordPress is more of a framework and Themes are more wrappers over it.

        2. There is no separation between theme and logic of that framework…

        This really isn’t true.

        WordPress has an API for extensions, but uses two separate means for extension: Themes and Plugins. To be sure, both use the same actions/filters (Hooks) API, but they are intended for two different purposes: Themes define presentation of the front-end, and Plugins define functionality.

        Is the differentiation perfect? Not by a mile. But the differentiation is distinct enough to work.

        The biggest problems surface when a Theme is developed to include functional, rather than presentational, output. Because both Themes and Plugins have access to the same Hooks API (though a Theme only has access to a subset of those hooks, due to the processing order), a Theme is capable of including almost any functionality that a Plugin includes. But ability is not the same as propriety.

        There are areas of overlap (custom post types/taxonomies, drag-drop “builder” Theme UI, etc.), but 95% of issues can be resolved by proper segregation of presentation and functionality.

        Create forum topic from comment

        • I do understand the difference and grey areas Chip. Jooml’r has undergone similar in years past. They define “plugins” as components, Modules as “widgets” (sorta) and Plugins as Filters (sorta) and again, every “theme” that is advanced ends up with its own configuration logic and often interfaces to said components, plugins etc. Thats where the frameworks in Jooml’r arose. RocketTheme’s Gantry, YooTheme and others. If one switched themes, oh my. Roll the dice! LOL.

          The problem is often that of a more propriety oriented nature in as far as commercial interests go. People who are creating free things are just enjoying being part of things and sharing. Thats nice. Some like notoriety, others more wholesome motivations.

          Commercial interests are revenues. Plain and simple at the end of the day. While might voice this and that, reality is, it keep me in clam chowder and a roof to eat it under.

          99.95% of all the commercial entities in Jooml’r or WP creating things are doing so to make a living be it a good one or bad one. At the end of the day. Thats priority #1 and rightfully so.

          If it were as simple as “Here is customizer” and here is the format of the XML files (which by the way IMHO is the right way) to create a rich UI so all they need do is remove code, make XML files, blam. Done. Be no yowling at all. But these are not things to announce. Code gets done, here it is, finny. Required to use it. Any theme that doesnt is rejected, have “n” months.

          But that Rich UI isnt there. And if its atop scriptaculous along with JQ being loaded up. Welp, thats just not very prudent.

          I get separation of code and UI. I do a ton more work in visual studio than I’ve done in PHP. While all that is event driven (which is also the future web thanks to operating systems online) code one really has no choices. Code is separated from UI.

          Anyways… Jeff will get upset it I slide off topic :)

          Point being commercial interests are not albeit to keen on going, “Here’s my theme” and in order to make it work you need download these plugins from the repository.

          First, the user might have no idea, “The theme looked like this”. But even with the plugin since its not configured it doesnt look anything like that! Helpies!”

          Two, commercial interests may not wish to expose their code as a plugin thus affording what they deem competitors to latch unto it.

          Take for example the workflow engine we’d made for our Jooml’r work. It started out as being for political websites. So news authors had a specific work flow. Events planners needed different workflows. CRM people, again different. We in time generalized it so it really became useful to sites, especially not for profits we did pro-bono work for.

          Its sorta tightly integrated. One it was easier to do it that way and two we had no intentions of ever releasing it. Now if we’re theme’n on WP is this workflow code something we want make into a general purpose plugin? Or from a commercial standpoint does it given us a considerable edge over other themes? Thats what it’d do.

          This same facet stands true for those theme developers out there in commercial interests. They may make a theme for general use and slap it into WP.Org. The goal however is to drive the theme user to Envato to buy the full shebang. Thus WP.Org is used as an advertising medium. The hook.

          Is that right? Eh?

          If I were WP.Core I’d be going, “Why is Envato getting rich while we have a product with a 20%+ marketshare and get to capitalize on 2% +/- 1% of that enormous marketshare when we could be taking that dough and investing it to bring our software into the future and stave off the wolfies.

          If theme “A” has a wonderful theme UI thats a plugin on WP.ORG what stops Jimmy from just going, “Ok, Thats saves me a ton of work”. Thats the issues at hand.

          Or are we allowing “This plugin will only work with ‘Bobs Themes’ in the plugin repository” and allowing Bob to protect it?

          This is why I said, certainly there exists this immediate deal. All WP users deserve a common experience when using the software. Certainly the TMT must have a consistent workflow in being able to approve themes.

          That consistent user experience is not only accomplished through themes. Themes tie to plugins, widgets etc.

          The UI experience needs be consistent across the platform. The reason Jooml’r is not more popular than WP is that end user experience.

          I can sit someone down with WP and in a few hours they’re creative juices are flowing.

          I can sit the same person down with Jooml’r and they wont be past user permissions controls and the only creative juices flowing will be down their pant legs.

          This project, WP, needs a roadmap and all parts need to converge at some point in time. I am all for it. I dont know how helpful I can be.

          Some of the biggest advantages in projects like this are that enormous community of people. At the samtime its also a big detriment when the “big boys” start coming out of the locker room. They dont have that diversity to worry about.

          The Adobe planners say, “This is what we want”, money is not an object. Do it.

          Here, well…. You have witnessed what folks have said.

          I am on the outside looking in. When it comes to brain cells mine function most of the time. I try see things from as many angles as I can.

          To the frisky fans they often see that as, “A naysayer or a malcontent”. Nothing of the sort really. To the naysayers at times they think “We have a champion to speak!”. Again, uh uh.

          I believe that all things that succeed do so through mutually beneficial relationships.

          Now I need go to the pub and publicize myself in front of a few Sam Adams.

          Create forum topic from comment

          • The problem is often that of a more propriety oriented nature in as far as commercial interests go.

            That’s really a non-starter in the WordPress community. “Proprietary” and “GPL” simply don’t mix.

            Commercial interests are revenues.

            As they should be! Developers have to eat, and have to feed their families.

            But that Rich UI isnt there. And if its atop scriptaculous along with JQ being loaded up. Welp, thats just not very prudent.

            But that’s the direction the core devs have chosen to take. As a community contributor group, the TRT prioritizes supporting core implementation wherever plausible.

            And I can tell you, in my experience reviewing over 2,000 Themes, and auditing many hundreds more, the custom UI solutions, by and large, do not benefit end users – for several reasons that are outside the scope of this comment.

            Point being commercial interests are not albeit to keen on going, “Here’s my theme” and in order to make it work you need download these plugins from the repository.

            There are some, but very few, legitimate circumstances where that would be required, when presentation is properly separated from functionality.

            First, the user might have no idea, “The theme looked like this”. But even with the plugin since its not configured it doesnt look anything like that! Helpies!”

            This is really a bit of a separate issue, but definitely an area of great opportunity for improvement for WordPress.

            Two, commercial interests may not wish to expose their code as a plugin thus affording what they deem competitors to latch unto it.

            Again, this is a GPL environment. There is no *preventing* of such exposure. And Theme code is every bit as exposed as Plugin code.

            Take for example the workflow engine we’d made for our Jooml’r work.

            *Timeout*

            Workflow? This is Plugin/Functionality territory, that a Theme should not be handling. As such, it would not be impacted in any way by a Theme being required to use the Customizer.

            Its sorta tightly integrated. One it was easier to do it that way and two we had no intentions of ever releasing it. Now if we’re theme’n on WP is this workflow code something we want make into a general purpose plugin? Or from a commercial standpoint does it given us a considerable edge over other themes? Thats what it’d do.

            And that Theme would already not be accepted to be hosted on wordpress.org, regardless of the Customizer requirement, because all of that workflow functionality would violate the existing requirement that Themes limit themselves to presentational, not functional, aspects.

            The new requirement to use the Customizer for Theme options would have no bearing on the decision.

            The goal however is to drive the theme user to Envato to buy the full shebang. Thus WP.Org is used as an advertising medium. The hook.

            The purpose of the directories is for developers to give back to the community, not to promote or to facilitate commercial endeavors. The TRT has no delusions that some Theme developers use this approach, nor do we attempt to prevent such strategies. But in the end, the wordpress.org Theme and Plugin directories exist for the *end users*, and if what benefits end users conflicts with what benefits commercial developers, we will err on the side of benefiting end users.

            In this case, that means not facilitating the conflation of presentation and functionality within a Theme – just as it now means not facilitating the propagation of ad nauseum custom Theme settings page UIs.

            Or are we allowing “This plugin will only work with ‘Bobs Themes’ in the plugin repository” and allowing Bob to protect it?

            I can’t speak for the Plugin Team, but I believe that such code would not be allowed.

            This project, WP, needs a roadmap and all parts need to converge at some point in time. I am all for it. I dont know how helpful I can be.

            A meaningful roadmap is something I’ve been asking for, for years. So we’re on the same page there.

            I am on the outside looking in. When it comes to brain cells mine function most of the time. I try see things from as many angles as I can.

            To the frisky fans they often see that as, “A naysayer or a malcontent”. Nothing of the sort really.

            To many people in the WP community, I probably still have just that sort of reputation. The beauty of the WP project, and its community, is that there’s room for everyone who wants to contribute.

            Create forum topic from comment

      • This is the wrong call, and history will see you all personally as the villains and not as heros or the savors of the community.

        The TRT should not be making business decisions for an entire ecosystem. You guys are completely overstepping your bounds, and are hardly privy to any inside information that isn’t readily available to the rest of us. If you are privy to said inside information, then you failed horribly to educate any of us as to why you should have the authority to destroy everything the community has created.

        This decision is going to destroy years of development time, hundreds of thousands if not millions of dollars of investments, and innovation in a single swoop. You also know the WordPress API is coming anyway, and that better solutions then the Customizer are already in the pipeline. Why you’re pushing an unfinished front-end editor as a theme options framework that the original developer who started it never even completed as the end-all solution to basically purge the repo of all the themes Automattic disagrees with is beyond convoluted and out of touch with the community, and reality.

        This decision effectively eliminates a theme authors ability to communicate with their users, which also eliminates the opportunity to upsell in any meaningful way. You are destroying many theme authors entire livelihoods with this decision that will have rippling effects through the rest of the WordPress community including market places like ThemeForrest.

        Mark my worlds, this decision is the beginning of the end for WordPress.org. The development community will move on, in fact most of us already have. This will be the final nail in the coffin for many of us.

        Create forum topic from comment

      • Hey Justin – thanks for the reply. I definitely know you all take a lot of heat sometimes. Hopefully I didn’t add to it (too much at least :).

        “At the end of the day, we all have one goal in common: we want users to have access to awesome themes from the directory.” => Exactly, though for me I’d extend it to awesome themes outside the repository as well, since that’s an important part of the theme landscape and the value of WordPress, and since I know WP.org guidelines and standards have a big effect on the broader community. I know that’s not technically your mandate, but that’s a big part of my concern too.

        In any case, if we’re going this way anyways, I hope it unfolds smoothly the rest of the way and proves to be a great decision.

        Create forum topic from comment

  47. Hi Chip,

    I was using the workflow component as an example not as an “intent to” per se.

    We have no intentions of public release of it. Our mainstream project we are working on is coded in C#. The application needs great CMS support. Having experience with Jooml’r we began there. It could not handle the expected load. So we coded a smart cache extension for Apache, a DB pooling agent for Apache and a template engine to replace Smarty. While the gains were enormous still not enough. So, thats why WP. As we port the code we may well release some things. The workflow component probably not. Why not? Because that would mean we need maintain it in public consumption. Perhaps some day but wont be anytime soon.

    As I said, I cited it as an example. If we made themes and our edge were that component and we made it a plugin, then its readily available to others defeating a commercial interest in a way if that were our goal. But at present, thats not in the “goals” picture. Or, we’d might just go “here” to the WP.Core and WP with a bit of work would have workflows so a site could be securely maintained by 100 people or 1000. For our current goals that codebase has not been touched to be ported yet. We are still in getting things in order to benchmark whether WP will handle the load we expect to be thrown at it.

    —————————–

    As I said, I completely get what you are saying in as far as separation of theme and function. I am far more adept with Windows, .net, C#, Winforms, WPF that that of my PHP expertise. In event driven environments (which will be the standard on the net too) these separations are simply how its done.

    I completely agree that users should have a consistent interface and users are more important than developers as without users who needs developers?

    When one considers with some of these themes how much “option” lay within them its rather overwhelming. Part of the draw of CMS’s is this component based extensibility. They are sorta like functional web toolkits. On the other side of the coin with that alot ends up rather sorta “cobbled”.

    Cohesive function to an extent to be sure but non-cohesive in user experiences in using things.

    This is why I’d stated producing a standard not just for themes but the whole shebang in as far as UI goes. WP.Core provides that rich UI API and in as far as themes/plugins constrains it under a fixed set of option titles.

    ——————————

    All this requires a roadmap which you and I both agree upon and I am sure the developer community would like as well.

    I get the impression from some posts readings at various sites that Automattic is more tuned to WP.com. If that is the case they should look to Redhat as an example. RedHat several times created problems in internal structuring of how they advanced Redhat. Due to it they ended up with considerable competition that nearly wiped the place out. The public facing CentOS is now the place of public facing product and RedHat Enterprise is the commercial facing release.

    They took what was a loose hierarchy in how internal operations functioned and tightened it bigtime. And to an extent I hear have loosed that now to an extent.

    ———————————-

    With communities as large as WP’s its important to display leadership out to the community. Leadership runs in parallel with direction and roadmap and its important to meet the deadlines that are public facing in a roadmap. If its said, “By December we will have a completely new replacement UI for customizer that will replace both Theme and Plugin options settings/configurations and it must be used” then there is excitement and some fear to community. But it gets delivered, not, “Well we are not done”.

    ———————————-

    One of the bigger questions would be is it all moot. I am not sure under the best of conditions that any CMS on any platform will be able to hang together with the likes of Adobe, Amazon etc entering the market in mass market fashion. For both of these companies its simply a logical progression of existing technologies. Adobe has been the “publishing” entity in software. Amazon a giant reseller of books, media, information and more that already allows digital publishing downloads. What better than interactive publishing where site webmasters can promote accompanying products. Aka: Recipe web site, Affiliate promoting books, cooking supplies on and on and paying them for the privilege. That is to say, for $40 a month create state of the art website and also be able to sell.

    WP’s own popularity in a way showed these entities the market. Before that leap ahead numbers were meaningless. Jooml’r 7%, Drupal 4%, Wp 12%, “Others 76%”. In corporate thats all a “Way iffy” deal to stake hundreds of millions of dollars upon. But as time has gone on those numbers have cleared up. They got a better picture. Web.com, Weebly, Wix didnt help as now traffic is measurable as they are not disbursed sites.

    ———————————–

    In order for WP be that .ORG or .COM to compete this software has a LONG way to go and a short time to get there. Adobe’s “authorized” developers too will have a marketplace and there wont be “others”. Amazon from what I have heard wont have third parties at all. They are working with MS.

    Why when I read about MS and WP I was like, “Oh… lettin’ the woofie in the door like Apple did way back when” and like they did with Apple, “Look at what we can do for you”. Like “Take your market”.

    ————————————-

    While Jeff will be upset as much of this is out of context (I am sure he’d say, “RICK! PARTITION YOUR BRAIN…. PLEASE!!!!!! LOL”

    The points being made DO revolve around the product, WP. Themes, Plugins et el. A standardization of the product needs be mandated and IMHO the community informed. “We have a roadmap. and while we cannot divulge ALL of it, here is what you users and developers need know and this is the reason WHY”. Lets pull together and re-invent this wheel for all of our benefits.

    Beating the big boys can be really hard but Automattic has several advantages, they stare me in the face but in those respects I am not the average fella especially in the idea’s/marketing fronts.

    Coders, dime a dozen. Really. Coders are not the pinnacle of IT success. Its having a highly creative, cohesive team and how that team works.

    For example, “Conflict”. With the TMT team as Mr. Tadlock pointed out there’s been conflict, as you pointed out, often not popular in what you say. In a cohesive team points of conflict are opportunity, not roadblocks. The facilitator of a team has to be not only “director” but also rich in ideas. Thus they see the conflict and use their brains to find OPPORTUNITY in it because WHERE there is conflict there is ALWAYS opportunity.

    Agreeing to disagree is just throwing opportunity under the bus.

    Resolution of conflict on the other hand is done via new ideas. There are ALWAYS many paths. I just happen to be rather good at this. No clue why. Good teachers in life.

    A great facilitator does more work than the team they are charged with directing and in performing that direction always places goals before the entities being directed but has it appear as the entities are foremost equals to the facilitator or more.

    With a project such as WP there is much diversity and in as such many different interests. Those interests are tools. A great facilitator recognizes scope and also why they actually end up doing more work than the team.

    Its the facilitator that goes in to Matt and corporate and displays proposed roadmaps and directions, how to get from here to there etc. Matt then says, “Dont like this here Rick. Lets do lunch. Lets discuss this so you can go back to the team / team leaders and get some more work done on this”. Yes sir.

    Programmers just “Do”. The moment programmers are in a position to define direction everything is a mess. Why? Because they see function. I am one of the lucky ones as I grok marketing. I grok a larger picture than code. Code is code. While programmers like “escalate themselves” as “Without us what is there?” the truth is “without us another programmer is available”. Dime a dozen.

    What are not a dime a dozen are those that can think out of the box, that know what can be done in code but also grok the big picture. Those that can interface in all facets yet independently think.

    Anyways… I’ll leave it there.

    Create forum topic from comment

  48. It seems that members of the TRT have indicated that they will help iterate to add to the customizer where needed and are open to ideas of how to improve it. So, I imagine that this should work out OK and in the long run be a step forward.

    I understand the WP core philosophy of decisions, not choices, and the desire of the TRT to support that, but remember that themes are not core. Themes with lots of options for layouts, colors, and other style tweaks are very popular. In my opinion, saying that lots of options are “bad” seems like a “religious” statement akin to “vi is better than emacs”.

    Two themes with lots of options that I know of: the Make theme has more than a quarter of a million downloads and the Suffusion theme has more than a million. So to make sure I understand correctly, here are two questions about actual themes:

    1) The Make theme is available from the WP theme repository. It is a theme that has over 100 options in the customizer. If you want to understand what that looks like then it is a good example. I did not find any performance issues when making changes, but some of the options panels looked squished or spaced a bit oddly as the options panel in the customizer is kind of thin. Make has a plugin (premium) that is not in the WP plugin repository that adds more options. I assume that is OK (i.e. the plugin does not have to be in the WP repository as @Dovy thought)? For the Make theme, the customizer seems to generally work.

    2) The Suffusion theme has been around a long time and was very popular. It has its own options pages. It has not been updated recently because it has some custom post types in it that need to be removed before an update can be submitted. But anyway, looking at just the options and assuming that the CPTs were put in a plugin, it is hard to imagine that all of the options would fit in the customizer. There are 7 options pages, each with more than a half dozen sub-pages. The author has not wanted to up-sell to a premium plugin or theme. It appears to be a case where the customizer as it is now might not work well. Regardless of whether you like themes with lots of options, I assume that the author, if he wanted to, could make a plugin for the options and have it in the WP repository, correct?

    My understanding from what Justin wrote is that plugins for both of these themes would be OK, but the waters were a bit muddied and so I would appreciate some clarification. Thank you. Rock on.

    Create forum topic from comment

    • It’s not an official TRT policy/opinion that lots of options are bad. Many among the team have different opinions on that. Some dislike many options. Some love it.

      Going from “must use customizer” to “lots of options are bad” is getting into a bit of a slippery slope. That’s not even one of the points of this guideline change. I’ve seen some awesome themes, like Make, that do very well with lots of options. There’s a huge market for these types of themes, one that is not going away anytime soon.

      As to the question of whether plugins are OK — yes, they are. That’s a method we’ve always supported and will continue to do so.

      Create forum topic from comment

      • So it is ok to provide a stand-alone theme and do the options for the theme through a plugin(s) that would sit in the plugins repository and pretty much only be applicable to a theme or specific themes?

        Create forum topic from comment

        • If implemented properly, that approach is perfectly acceptable. As long as the stand-alone Theme (i.e. without Plugin active) uses sane defaults so that it renders properly, then there’s nothing wrong with using a Plugin to expose/extend the Theme options. And as long as the Plugin doesn’t do anything nefarious to prevent itself from being used with other Themes active, then it should be fine, as well.

          I believe that Bruce Wampler has done just this sort of thing, with the Weaver II Theme. You might want to take a look at his implementation.

          Create forum topic from comment

  49. Well, I see my name mentioned by Chip. Just to to clarify, Weaver II is dead thanks to a previous WP TRT edicts – and has been replace by Weaver Xtreme, which now has also received a death sentence due to this new Customizer policy.

    Weaver Xtreme had 600+ options, with thousands of explanatory comments built into the options. It is widely used by thousands and thousands of both end users, but more critically, WP Site Design operations – usually individuals tweaking out a living designing web sites. These people want a theme that is really flexiible, and doesn’t make them design child themes or whatever that requires real PHP expertise. There are also plenty of users who don’t know CSS, PHP, or anything about the internals of WP who build perfectly beautiful looking sites just by using Weaver’s checkboxes.

    But, the options have always been deeply integrated into the actual theme via the formerly standard Appearance menu using the Settings API. My options API is proprietary – none of the nice option framework libraries existed when I started all this. But it is absolutely clear it would not be translatable to the clunky, restrictive, tiny screen space, poorly organized, and highly restrictive Customizer.

    Currently I don’t know what to do next. This new Customizer requirement (and a measly six months off) is simply not doable for the existing Weaver Xtreme. And even if I manage to implement the same options UI via a TGM added plugin, I have zero confidence that TRT won’t add some new requirement that disallows themes from using TGM, or plugins to implement options. They say that is okay now, but there have been all sorts of other broken promises about what would and not be allowed in the future. At one point, for example, it was promised that existing theme would be grandfathered – at least for allowing small bug fixes and updates. Nope, that promise broken. So why should I invest thousands and thousands of development dollars to make a compliant version of Weaver that depends on a plugin for the options that is almost guaranteed to be banned in the future?

    I suspect that this new decision will drive a large number of theme developers away from WP permanently. That is a shame, and the only real losers are the end users.

    If I had even the tiniest belief that providing a custom option interface via a plugin would not ultimately be futile, I might consider that route, but six months is a pretty short time frame for a small theme developer like me.

    I don’t to go down the commercial path, but that may be my only choice, and a likely choice for other theme developers – and likely some of the best and most creative developers at that.

    An alternative I would like to investigate is the development of a theme cooperative that isn’t quite commercial, but will provide a distribution point for creative themes that TRT no longer will allow. It should allow upsells, perhaps provide the infrastructure for upsells as well as free themes. With a tiny bit of oversite, it could serve the role for providing the end user with great, creative themes that WP.org doesn’t want or won’t allow, yet not have some of the down side of the professional commercial theme shops. I’d appreciate hearing from any other developers who feel as stuck and screwed as I do on perhaps following up on this idea. It is clear that the WP TRT has some kind of agenda that totally ignores the huge investment many of us have put into our themes – as well as the real best interest of thousand and thousands of real live users trying to scratch out a living building WP sites for others. You can contact me via the contact page at weavertheme.com.

    Create forum topic from comment

      • Of course they are not well-served by having themes moved out of the repository. I am a huge believer in the WP repository, which is why I’ve continued to adapt to ever more illogical requirements over time.

        I will likely adapt again by moving all the options to a plugin, but that whole strategy of moving things to plugins seems really weird to me. We don’t want this or that in a theme, but it is okay to cheat (and that is what it is, really) and move it to a plugin. And that is why I’m convinced that at some point even using TGM will become disallowed.

        But really, why not let the marketplace decide? Sure, maybe some users are content with the Customizer (or some “future” enhanced version), but if not having theme options in the Cusomizer will drive users away from that theme (as mentioned in another comment), then so be it. But given the really unhappy complaints I hear in my own support forum about how difficult the Customizer is to use (like for picking header images as one specific), it is far more likely that forcing the Customizer will drive users away.

        Create forum topic from comment

        • Bruce, you know I’m someone who believes that there is a legitimate place for Themes such as yours – just as I believe that there is a legitimate place for layout-builder Themes. I also have a similar problem as you, in that without a Theme settings page, I lose what is currently the most appropriate location for extensive Theme documentation (the Contextual Help API). So, I have to rethink some things, as well.

          That said, I think there are some misconceptions.

          First, regarding the alleged limitations of the customizer: the customizer has an API that makes it fully extensible. If it doesn’t work as-needed out of the box, why not experiment with extending it to suit your needs? Core Widgets are extending it. Apparently, core Menus will soon do so, as well.

          As I said above: I share your issue regarding documentation. I need to think that one through, as well. I consider the (user-facing and inline) documentation of Oenology to be one of its most important features.

          Second, regarding layout-builder Themes: maybe the best way to implement those is via post custom meta, rather than Theme options? And if they need to be Theme options (e.g. global layout configuration), I, for one, would be willing to entertain an argument for using a Settings page for that. Or maybe there’s some cool way to use the customizer on a per-post, custom post meta, basis?

          Third, regarding the market deciding between the customizer and settings pages for Theme options: the market really hasn’t been given the chance, for two reasons:

          1. Too many Theme developers still conflate presentation and functionality – that latter usually representing settings that do not lend themselves well to the Customizer

          2. Too many Theme developers use a unique Theme settings page UI as a branding/selling point of the Theme, and are thus are resistant to implementing the Customizer.

          (These issues are among my biggest complaints about marketplaces like ThemeForest. Combine them with the “kitchen sink” approach, and you end up with a Theme-options arms race that’s more about marketing than about what’s actually best for end users. That’s not to say that there’s no place for “kitchen sink” Themes – just that their place is niche, and not mainstream, and it does a disservice to the vast majority of end users to portray them as what is best for their needs.)

          Both of these issues are problematic, both for end users and for Theme reviewers. For .org hosted Themes, we’ve done a pretty good job of handling the former issue; but the latter issue remains. And for far too many of the developers who fall into the latter, the implementation method is just to drop in an options framework library, without having the first clue how that library works.

          How does that inevitably work out? 10,000 lines of “black box” code that the developer doesn’t understand, doesn’t know how to implement the best/most efficiently, doesn’t know how to inspect for potential security issues, etc.? They don’t know how to ensure that their data are sanitized on input, and escaped on output. Theme reviewers have to learn what is usually a very complex options framework library, then teach/explain it to the developer, just to ensure that settings are implemented properly before the Theme can be approved and put in end users’ hands.

          Note that you and Trent are not the kind of developer I’m talking about here. Developers like you try to do things the right way, you write (and understand) the code in your own Themes. If someone (e.g. a reviewer) finds an issue in one of your Themes, you understand it, and know how to fix it.

          Fourth: regarding TGMPA, I would only see something like that library being prohibited for one of two reasons: security issues (there was one recently), or core adopting a dependency workflow – at which time we would require Themes to use the core implementation. I would honestly love to see some sort of core implementation of dependency handling, but I have no idea if it will ever happen. With respect to security issues: in all honesty, TGMPA is WAY more complex than it needs to be for how it is used in Themes. That doesn’t mean that the TRT would move to prohibit it. But it does mean that we might encourage developers to use a leaner approach. (Otto has argued for that, for some time.)

          Fifth, as others have said: the Settings API was really originally intended/designed primarily for Plugins, not for Themes. The path the core team ultimately chose for Theme settings was the Customizer. The Theme Review Team isn’t driving that decision; we’re merely supporting it.

          At this point, what alternative do we really have?

          We’ve petitioned the core team to improve the Settings API, to add core form fields, controls, and sanitization, so that its usage might be simplified for developers. It hasn’t happened – but the core development team did decide to add all of those features – to the Customizer.

          We tried to promote and educate about the Settings API. Four years ago, I wrote a comprehensive guide to incorporating the Settings API into Themes, and the TRT has encouraged/recommended its usage since that time. It hasn’t been effective in propagation of Themes incorporating the Settings API. Three years ago, the Customizer was introduced. Otto wrote three tutorials/guides on incorporating the Customizer in Themes, and the TRT began encouraging/recommending its usage. It hasn’t been effective in propagation of Themes incorporating the Customizer.

          In that time, the only thing that really proliferated was development/usage of third-party options framework libraries, with custom Settings Page UIs. At least the proliferation of Underscores as a “starter” development Theme has started to make a dent in Customizer usage.

          Finally, there is no agenda here on the part of the Theme Review Team. We’re not trying to isolate/eliminate upsell/commercial Themes. We’re not trying to stifle creativity/ingenuity in favor of cookie-cutter, basic-options Themes. We’re not trying to force Themes to reduce/eliminate options.

          We’re trying to support core development decisions. We’re trying to do what’s best for end users. We’re trying to ensure that end users don’t end up with Themes that have potential security vulnerabilities. We’re trying to educate developers and to help ensure that they understand the code they’re using in their themes. And we’re trying to ensure that we can review/approve Themes as expediently as possible. That’s it. There are no ulterior motives.

          Create forum topic from comment

          • Second, regarding layout-builder Themes: maybe the best way to implement those is via post custom meta, rather than Theme options? And if they need to be Theme options (e.g. global layout configuration), I, for one, would be willing to entertain an argument for using a Settings page for that. Or maybe there’s some cool way to use the customizer on a per-post, custom post meta, basis?

            Per-post layout building makes the most sense being stored as post meta. You can do that via the edit post screen in the admin or even via the customizer. There’s actually 4 different methods for storing options with the customizer:

            Theme mods (default)
            Single options
            Serialized options array
            Something custom (e.g., post meta can work here too)

            There’s even PHP and JS conditional checks to show specific controls within the customizer.

            Create forum topic from comment

          • I was told I write too much chip. LOL.

            I messed about with Customizer for 3 or 4 hours, looked at the code. Otto is right. Its not horrid as people say it is at all. Here IS what I noticed in messin’ about with a bit of code.

            While Customizer uses JQ apparently the media related stuff is using Prototype and Scriptaculous is also loaded. Thats basically three JS frameworks in use by WP.

            I did not look at why Prototype / scriptaculous are loaded.I presume its either the media stuff or widget drag/drop etc stuff.

            These are pretty aged.

            But, more so than that. Developers are probably experiencing slowdowns in Customizer with lots of items because they have lots of browser windows open. I noticed that. Normally I use Firefox for looking at my work “live” per se, I use chrome as well, then I use Opera to do whatever web hunting I need do for information, such as pointing at the codex.

            But if I happen to have 15 windows or 20 windows open in FF Customizer got a bit clunky in response with the theme I’d loaded up.

            With 20 windows open shouldnt be happening. This is a core i7 PC. I can have Visual studio up, compiling, photoshop, 3 web browsers, adobe illustrator and VMWare w/ OS/X running and web browser up with no noticeable slowdowns.

            Certainly more than the average web surfer will have open but sitting in WP with Sublime text 2, three browsers open should not make the UI clunky on the back end.

            Create forum topic from comment

          • > With respect to security issues: in all honesty, TGMPA is WAY more complex than it needs to be for how it is used in Themes.

            TGMPA was started in 2011, before some of the classes in WP were as flexible and extensible as they are now. However, development has resumed with a bang in the last few weeks, and we’re working to simplify and reduce our code greatly.

            We also allow plugins to require / recommend other plugins, as it’s not just themes that support dependencies. Of course, should WP core ever come up with equivalent support of registering intent for dependencies, we can all drop TGMPA, or TGMPA can handle the edge cases that Core won’t.

            Create forum topic from comment

        • I hope I’m getting into my own sub-thread – the reply buttons weren’t working quite as expected.

          Chip – I know you have always been very supportive of the various incarnations of Weaver, and I do appreciate it.

          For now, it looks as if my approach will be to make the full option screens part of the existing Theme Support plugin, which already has the Per Page/Post options boxes. But there is a need and a place for both kinds of options – global and per page/post.

          But, really, the main point for me (and obviously for the tutorial/information part of your theme, which, as I recall, was one of your major design goals – to make it very helpful) is that I probably have close to a person-year of coding in my existing options interface. It has evolved over three major revisions of the theme, and I feel I finally got it right.

          And that is really is really my main objection. I’m being forced to switch to a rather awkward requirement for the users to install a plugin to get all the options, rather than a more elegant approach of having the theme ready to go.

          But this requirement (as long as it remains possible to recommend an add-on plugin, using TMG or not) does present an interesting opportunity. By separating the options UI even more than it is now from the core theme engine, it should be possible to really use it as an engine with more than one level of user complexity – from beginner to the site designers who like it so much now. So, I will take this as a positive now that I figured out this levels of options based on the underlying theme engine.

          And anyone who as looked at the free versions of my theme knows, the free version is incredibly functional, and the push for the upsell add-on is really muted. The free version is not simply some minimally functional theme with the sole intent of the upsell. I’ve been writing GPL software for over 25 years, and I simply don’t have it in me to release a teaser theme, and hope I’ve found that line between core functionality and added value in the upsell.

          As for TGM, it is indeed a bit bloated, and at some point I used Otto’s small add-a-plugin example. But what TGM does offer is the ability to easily specify several plugins with a bit of explanation for each, as well as its initial intrusiveness to get the user to actually check out the recommendations.

          Create forum topic from comment

  50. Bit late to the party, but this is very Jobsian of WP. Totally against the spirit of open development. Is WP following Apple now? “Our way or you’re on your own.”

    It wouldn’t be so bad if the customizer didn’t have such poor UI/UX for more than a few settings.

    Didn’t WP folk even think “Folks aren’t using the customizer maybe there’s something wrong with it”? Instead of forcing them to use it.

    (On the other hand, if WP are following Apple now, maybe we’ll finally see some improvement in the UI. Maybe someone will discover some of the principle and elements of design, like visual hierarchy, contrast and colour to name a few lacking in WP admin.)

    Create forum topic from comment

  51. Workflow? What BS! All I can tell you is that if the only way to tweak the theme is the Customizer I move on to the next candidate. As a USER I hate having to use the Customizer. It is WP Lite – dumbed down to the lowest cud-chewing denominator.

    I like WP a lot, because of the amazing variety of choices in themes and they way they are personalized. Consumers say, “Start taking away my choices and we will move on.”

    What theme review needs to pay attention to is all the near spam themes out there with no functionality, but plent of nagware on Admin screens. “Want red? Buy GougeME Pro today!”

    For years the WP community has encouraged theme and plugin inovation to great effect. What’s the WP market penetration? How many people make at least part of their living creating WP powered sites? To now reward people like Brue Wampler and others for their contributions to the community by driving them out of business is simply stupid.

    Creating settings pages in the Admin is not a crime. Requiring themes to have limited cookie cutter options because the Customizer is a required bad piece of software is a felony.

    Wrong decision, and I expect lots of blowback to follow.

    Create forum topic from comment

  52. Many of the comments here are misinformed or unaware of both the full power of and the future importance of the Customizer. I’ve given an overview of my perspective on my blog, and while those views don’t directly represent the views of the WordPress project, I can say that most people working on the Customizer in core would agree with my points. http://celloexpressions.com/blog/the-customizer-is-the-future-for-themes-and-theme-options/. Like it or not, the Customizer is here to stay, and ignoring that fact will eventually cause users to turn against you.

    I’ve also started building a canonical developer tutorial on the Customizer API in the official theme developer handbook: https://developer.wordpress.org/themes/advanced-topics/theme-customizer/. I’ll finish writing that out in the next couple of days, but that should suffice for a broad overview of how to leverage the Customizer in your themes including numerous code examples.

    There is definitely room for improvement in core, but we need help both with identifying paint points and implementing solutions. Please join us in the #core-customize channel in WordPress Core Slack (see https://make.wordpress.org/chat/). Or, submit tickets to the “Customize” component on WordPress Core Trac: http://core.trac.wordpress.org/newticket.

    Create forum topic from comment

    • > Like it or not, the Customizer is here to stay,

      That’s the kind of absolutist thinking I’ve seen take down lots of software products in my 35 years in the “puter bizness.”

      Why not let the consumer decide? Make Customizer an awsome tool and users will draw near like moths to a flame. But to banish by decree a whole category of themes that are popular with lots of users is ill advised.

      As a builder of other people’s web sites, I want options. Lots of options. (Disclaimer: I use Weaver Pro often because it lets me control design to the nth degree from big screen to pocket smartie.)

      I use others as well, but invariably the themes I find that exclusively use Customizer pretty much suck. Is that theme developers not knowing how to use the power, or is it an immature feature that has to be forced on the market by decree?

      Can’t there be a middle ground, where Customizer can be utilized for big changes (color groupings, header, background, widgets) and yet still have an options page for fine tuning?

      A plugin is allowed to create options pages in Admin, but a theme isn’t?
      How dumb is that?

      Do I as a user have to now download a plugin separately to get the options I want?
      That’s anti-competitive and stifles innovation!

      Let the WordPress market decide.

      Create forum topic from comment

  53. A lot of people here don’t realise just how powerful the customizer can be!

    I envision a future in WordPress where there is no admin at all and EVERYTHING is handled from the customizer.
    From post creation to editing plugin options.

    I sincerely hope we see more things move away from wp-admin and into the customizer…

    Create forum topic from comment

  54. It’s interesting to see people upset that the customizer will be required for wordpress.org themes, and claiming that will stifle innovation and force people to other marketplaces where they can do things with custom options pages, while considering the popularity of the X theme on themeforest.net, which is a “kitchen sink” theme if ever I saw one. X does everything in the customizer by choice.

    Create forum topic from comment

  55. Several reasons not that I prescribe to them but I can see a point of view.

    1. For those freely offering themes it means they may have to go back and change them to use customizer, its work.

    2. For those whom put themes up in a limited form wanting “upsell” essentially using wp.org as a sorta “shareware” advertising medium it means they must change their themes if not using customizer.

    A. If they are doing that when they “upsell” and say someone wants to buy a full version it too better be customizer enabled or gonna have one really pissed off customer, so it means they need change their commercial offering as well.

    B. Again, thats work. Working on a pre-existing theme especially when doing so in respect to earning revenues could be time spent making new things.

    3. Some folks beetch about Theme Forest as they’d prefer everything be free. Others because of prices which are set by Envato. Some beetch because Envato in itself is commercial and they dont want see WordPress be commercialized. Webmasters dont tend care either way, its the developers that get all persnickety usually.

    4. Webmasters dont tend to be “tribesman or women” unless commercial interests are at stake. That is to say, its those with commercial interests who always want think “mines best”. Whatever I am using/doing is “best”. Seldom ever the case, self-induced brainwashing is actually one of the absolute worst business traits one can aspire to having as its a easily exploited weakness.

    5..Developers tend to think they are “special” in that “if it were not for us then… who?” type scenario. More common than not I have found. Reality is coders are a dime a dozen now and China is going to make it a nickel a dozen in scant years along with players such as Alibaba who have made it clear, they intend to be #1 globally on the Internet and if their revenue numbers are correct, by 2025 might well be the case. Right now they could buy Amazon and eBay and have alot of change left in their pockets.

    6. Developers making lots of templates are more than likely already using a “framework” interface for all themes. Transitioning that to something more fixed in capabilities can mean back to the drawing boards.

    7. Standards are often resisted by third party developers as it often means “more are on the way”.

    8 Webmasters who like free things always worry about commercial interests (yet are often setting up webs for others and getting paid for it) as commercial interests can entice others to enter into said fray. So, neato plugins come out and developers go, “$80 per installation” or $500 for 10 installations. Money in others pockets isnt in theirs.

    9. Conspiracy theories. I’d imagine when WP.com came along lots of folks went, “Oooo… Automattic is going commercial… What will happen to us poor slobs?”. If Automattic truly wants commercial markets alot need happen, including standards and learning from like RedHat, that the public release (Cent OS) is the testing bed for Enterprise RedHat. aka: Let others do the work for the community edition and reap the rewards into a commercial edition. Unfortunately, PHP stands in the way of this. PHP tribesman often point to Facebook saying, “See, PHP can do big scale, enterprise”. Fact is Facebook had to build a compiler and do considerable modification to PHP and are quite sorry they went that route. I usually say, “Ok, name 10 others” and watch em go, “Ummm… uhhh…,”

    10. Just as now many developers and “root webmasters (tribesman)” will be concerned that WP.Core setting down standards will eventually result in enforcement of standards at say Envato. They are right, and it should. Automattic owns the product. Envato would be stupid (very very stupid) to not follow WordPress lead. “WordPress has standards, we dont” is a very bad position to sit in as entity three comes along and says, “But we do”. Webmasters who buy plugins and themes will do so where they KNOW standards are being maintained.

    A. Thus, developers using Envato may think now they are “off the hook” but will probably find in a lesser given time frame they are not. Envato is unlikely to go, “you have 6 months”. They are more likely to say, “30 days”. So for people selling theme’s at Theme Forest, it would be wise for them to open their eyes and move their UI’s to Customizer as well before they dont have time to do so.

    Create forum topic from comment

  56. I find it deliciously ironic that while a couple years ago the Theme Review process had many rules, thankfully most of those were made optional over the last year, and now we’re beginning to see a reintroduction of innovation-stifling bureaucracy being reintroduced with these new Customiser rules.

    Create forum topic from comment

    • Sven, thanks for the open and honest look at your experiences. You have hit on a very important point: the vast majority of end users don’t understand the meaning, much less the benefit, of separating presentation from functionality. You are absolutely right that the wider (i.e. more than just the developers/insiders/one-percenters) have a very long way to go to educate those users.

      The reality is that, for far too long, commercial Theme developers attempted to add “value” to their Themes by creating Theme+Plugin combinations. But in reality, Theme + Plugin = [something different]. Maybe we need to start calling them “Applications”.

      While there is nothing inherently wrong with creating value by distributing “Applications”, we do users a disservice when we call them “Themes”. Most of the time, the purported value of such “Applications” is really a paper tiger, because the underlying Plugins bundled with the Theme are themselves free. The developer is really only providing the appearance of value – often at a very high price *cough* ThemeForest *cough*.

      Again, I don’t want to disparage that business model. But I have problems with it, when developers who use it call their creations “Themes”, which results in user confusion. Do users get better/more professional Theme design overall at ThemeForest? Yes, I think that’s still true. But it comes with far too much baggage, and the user doesn’t know it until it’s far too late.

      I applaud you for moving your functionality work into a Plugin, and marketing it as a Plugin. I applaud you for supporting the separation-of-presentation-and-functionality model, and doing what you can to educate users. One step at a time.

      The move to the Customizer is but a small part of this much larger issue.

      Create forum topic from comment

  58. Repost of what I wrote elsewhere:

    Aside of the user’s POV: My personal view of the Theme Customizer is .. not so good.

    It might be much better if there was PROPER documentation, and I wouldn’t have to dig through lots of code, jumping to this and the other file just to find out if what I want do is IN THERE at all. Quite some stuff I had to find out by trial and error, and a few things I just ASSUME are done right .. some of them might actually be leading to our current “parts of the customizer are not being saved”-issue, but thanks to having NO real documentation, it’s mostly guessing and fumbling around half-blind in the dark.

    “oh, help us out then” – one says? Why not document your own code first? Including a few PROPER examples, not just some snippets slapped together .. would help a lot of people, and propably get them MUCH MORE convinced to actually use the TC.

    Other things are: A lot of options actually REQUIRE way more space than the smallish TC sidebar offers you. But because there is virtually no documentation about the available UI, eg. jQuery UI Modals, which would fix the space issue more or less instantly,

    And then, there is stuff like the Settings Backup / Reset part I wrote for CC 2. This is a tool, SPECIFICALLY for the theme; this does not fit in the customizer. Regular users definitely WILL NOT grok, that they need to install a plugin first to backup the settings of their theme ..

    Not being merely the CC 2 developer, but having a regular client base as a web developer as well, I also can tell you from my experiences with regular users, who don’t know much about coding (and shouldn’t actually have to!) …

    .. the regular user is actually happy to be NOT overwhelmed with a loooong list of plugins, most of which he doesn’t really know what they do, or why, and why he has to keep them active or updated.

    And no, the concept of having separate users doesn’t work. That’s a nice concept, but reality begs to differ. A regular WP user will ALWAYS use the default admin user created, and even not, he is still going to want to be the MASTER of HIS site. Just as it is in Windows. Does a REGULAR user normally use two different accounts? Naw. That only happens in extremely regulated environments, like the school computer system, or that one company computer network, with the BOFH keeping everything in order.

    cu, w0lf.

    Create forum topic from comment

    • Hmph, maybe I should have structured it a bit more before C+Ping it here. First part is about the issues with the source code documentation, second about the UI itself and the third about the theme vs. plugin zone issue.

      cu, w0lf.

      Create forum topic from comment

  59. So, I’m seeing comments that in order to build / custom-hack themes you need to learn skills such as AJAX and Smarty templating? If this is true then WP is a dead avenue to me.

    I have enough problems remaining current in HTML, CSS and PHP/SQL. It’s bad enough that the webstore software we use at work now needs me to catch-up immediately on XML (which I have never used before).

    I gave up on creating themes from scratch when TwentyTen was released because the code structure in that was unintelligible to me – all those hooks and conditional functions without seeing any recognisable html/php in the theme’s layup files simply turned me off it completely and I went back to the more basic coding of themes from 2007-2009.

    If you’re now saying that it’s all going to become even more arcane and mystical with yet another function layer (the customiser) sitting between the developer/webmaster and the layup code, then no thanks WP … I’m out of here and so are all the sites I own or manage. I suspect you’ll see a lot of site managers saying the same – especially in the business world, where the IT department is already under pressure to streamline and do things ever faster – not demand more time off to learn new skills and code languages.

    The 1990s this ain’t … IT can no longer demand the stars and get them in the budgets of businesses.

    Create forum topic from comment

    • Hi Garry,

      Not quite sure where “smarty templating” comes from, I doubt WP would go to use Smarty. It’d be a mistake. Thats not to say a templating engine would be a bad thing, actually makes life easier in as far as theme’n goes.

      There is a performance hit as variables need be registered (if you will) with the template engines in PHP. It would probably create a rather messy WordPress.

      In as far as Ajax goes, its really no more difficult than Forms, jQuery makes it really easy. Before looking at how WP handles it, look at jQuery basics on Ajax and once you grok it then look at WP.

      For XML, while its a tad more difficult than HTML it is still quite constrained. The problems with it tend to be from software engineers who “over or under think” its structure. Same thing happens with relational databases. In PHP, the XML management via PHP is horrid. Tutorial operations tend “over discuss” XML which makes it more difficult for beginners to understand. If you go to the W3C site it will become easier.

      Basic WP Customizer is really pretty easy to use. Certainly easier than making one owns interface for theme options. Is it done right? Well… thats debatable. The code is very good, but, thats not the question. I am sure that WP will expand customizer to provide it more capability to handle more complex roles with themes. However, towards that end for “non coders” to effectively use it to build or maintain themes, that could be a problem. Its funny you mention XML as actually that is the proper way to do this. XML if perfectly suited towards these types of things, description of forms, description of structured information and a ton easier for non-coders (and coders!) to cope with.

      I would “hope” thats exactly what does get done with Customizer as if it doesnt then yes, your probably right on the money. Alot may jump ship.

      In as far as the web and Javascript (eScript) goes. Well… One either loves it or hates it. Its not going to go away anytime soon. In fact, it will grow more. jQuery is used on just tons and tons of sites and of course AngularJS. In 5-10 years it will wane. It simply depends on how fast the smart device unification process takes. If it happens slow, Javascript lives longer. If however the public at large dives in both hands and feet (and money) as was the case with smart phones then things will change a whole lot faster. Javascript is not well suited towards data transport on a scale (bi-directional) required for things such as video gaming online consoles do now. The game technologies are what will eventually usher in new standards for data transport providing a more dense compressed binary based format and appropriate data integrity/validation.

      Thats the next “big” leap in all this technology. Its not like the players have been secretive about it. All the large IT firms from Microsoft to Amazon and a ton inbetween have stated in one form or another they are working towards anything/anywhere/anytime.

      After that, well… who knows. But more than likely the next revelation will be a enormous slap to the developer community being simple Drag and Drop programming. There have been many early attempts at this over the last 15 years. The bottom line however is one of the entities creating the stuff dont have the staff, engineers, money, money and money to make such a monster viable for broad based “general purpose” programming.

      Create forum topic from comment

    • While the comments might offer up some interesting reading to say the least, it’s probably best to look at the official Make Themes blog for what’s actually changing. To answer your question: no, you’re not going to have to learn skills such as Ajax and Smarty.

      The change that TRT made is to the guidelines for themes hosted on the official repository. The actual guideline change is telling theme authors that they must use the Customization API for theme settings panels instead of the Settings API.

      Create forum topic from comment

  60. I don’t think forcing the Customizer to be a part of every theme is a plus. I don’t like the Customizer at all and prefer to access those options through the theme options set up by the theme creator. I think leaving this as an option for theme creators is nice. Keep WordPress open and diverse.
    Its better. :)

    Create forum topic from comment

  61. I offer both free and commercial themes.So if this is only applying to themes on the repository, then why would I want to put my themes there, when I don’t design for the Customizer?

    I can see the repository having less themes available. Hmmm sounds like a new repository for free themes needs to be developed!!!!

    Create forum topic from comment

    • So if this is only applying to themes on the repository, then why would I want to put my themes there, when I don’t design for the Customizer?

      If you’re a *Theme* developer, then why are you “designing” for any particular options interface, to begin with?

      Create forum topic from comment

      • This discussion is starting to sound very much like all the tech-kerfuffle that surrounded the VHS / Betamax wars for home videotape.

        Look what happened to (both) of those … superseded by compact disks.
        Be careful WordPress and TRT … you’re upsetting people enough that an alternative to your offerings could arise.

        Create forum topic from comment

      • Chip, don’t get distracted by language. It’s not uncommon for people to interchange the words “designing” and “developing”. Don’t get hung up on language, the point was pretty clear.

        I went back and read Justin’s post on the why’s of all this, and can clearly see why it is important to the TRT. It’s not as much about the “user experience” as about the efficiency of evaluating themes and the security of themes.

        I think that has been lost in all the hoo-ha. I think you would have been better off focussing on those two points than trying to make it about “Having a consistent experience for users (most important thing)”.

        I think that one is baloney. User’s are very used to inconsistent experience in WP with a plethora of plugins all doing it their own way.

        I think if you had’ve said, “Look guys, we appreciate your own options pages, but that just makes it so much harder and time consuming to review themes for the WP theme repository that we can now only review and accept themes using the customizer.”

        That was what I really got from that post (here’s the link and recommended reading)

        https://make.wordpress.org/themes/2015/04/22/details-on-the-new-theme-settings-customizer-guideline/

        Yet that has been lost in the “conversation” with the TRT side sounding rather dictatorial, when they would have been better to elicit empathy for their struggle to keep on top of reviews.

        Once I got that message, my antagonism to this decision dissipated.

        Create forum topic from comment

        • Chip, don’t get distracted by language. It’s not uncommon for people to interchange the words “designing” and “developing”. Don’t get hung up on language, the point was pretty clear.

          I’m not arguing semantics, and my point was equally clear: Theme development doesn’t involve designing/developing for the UI used to expose Theme options. Designing/developing for a Settings API-implemented settings page makes no more sense than designing/developing for a Customizer API-implemented settings page.

          I went back and read Justin’s post on the why’s of all this, and can clearly see why it is important to the TRT. It’s not as much about the “user experience” as about the efficiency of evaluating themes and the security of themes.

          The efficacy of evaluating Themes for security is but one reason for the change. It is certainly not the most important reason.

          I think that has been lost in all the hoo-ha. I think you would have been better off focussing on those two points than trying to make it about “Having a consistent experience for users (most important thing)”.

          But that *is* the most important thing, along with supporting core developer decisions regarding API usage.

          I think that one is baloney. User’s are very used to inconsistent experience in WP with a plethora of plugins all doing it their own way.

          I see absolutely no reason for the Theme Review Team to facilitate bad practices by Plugin developers.

          Yet that has been lost in the “conversation” with the TRT side sounding rather dictatorial, when they would have been better to elicit empathy for their struggle to keep on top of reviews.

          Our goal was not to elicit sympathy for doing the activity we have all volunteered to do.

          Here are the reasons I laid out elsewhere, in order, for why the requirement was added. As you can see, the impact on Theme review/approval was way down on the list:

          1 Supporting core dev decisions: the Settings API is woefully incomplete. Rather than improve the Settings API to make it a fully featured API, the core dev team has chosen instead to create, and to flesh out, the Customizer API. It is clear to anyone paying attention to the focus of the core devs that they intend for the Customizer to be an important part of core, and the intended means to expose Theme options.

          1a Supporting core dev decisions: the Customizer is being further built into the user workflow in the WordPress admin. The roadmap will only increase that integration. Theme-installation will incorporate the Customizer. Having Theme options exposed during the Theme-installation process, allowing users to live-preview their settings as part of the install process, will be a big win for users.

          2 Consistent UI/UX: the proliferation of custom settings-page UIs does not help end users. It merely allows Theme-specific branding to interfere with the user experience, and allowing Theme developers to pretend that hours of design work in shiny UIs somehow provides an end-user benefit. By ensuring that all directory-hosted Themes expose Theme options through the Customizer, we ensure that users will have a consistent UX, and will not have a new learning curve with every new Theme they install/try.

          3 Security: the Customizer API is more robust out-of-the-box than the Settings API, and has more built-in data sanitization. The form fields are standardized and consistent. There is therefore less opportunity for custom code to introduce security issues. Further, the ability to learn and to understand the Customizer API further mitigates opportunities for security vulnerabilities introduced as a result of Theme options implementation. Which leads me to:

          4 Lower Developer Barrier-to-Entry: the Customizer API is far easier to learn and to implement than the Settings API. The Settings API is so difficult to learn that the vast majority of new developers, rather than attempt to learn the Settings API, resort to bundling a framework/library that incorporates the Settings API for them. But most never invest the time or effort to study and to understand the code that they’re bundling. The end result is not a more-educated developer, but rather black-box code bloat.

          5 Faster Theme review/approval: the primary reason that the Theme review/approval process takes so long is Theme options implementation. The primary reason that tickets for approved Themes are reopened by admins is Theme options implementation. If developers want a faster, easier, smoother review/approval process, using the Customizer API rather than the Settings API to expose Theme options will be the primary driver for that change.

          6 Further differentiate between Theme and Plugin territory: for some time, the TRT has required that directory-hosted Themes limit themselves to presentation of user content, and not include creation/generation of user content or other non-presentational aspects of site administration. By forcing all Theme options to be exposed via the Customizer, the differentiation between presentation and site functionality becomes much brighter. Presentational options lend themselves naturally to the Customizer, whereas site functionality/administration options do not.

          6a Encourage Design Constraint on Theme Options: while the TRT holds no position regarding the propriety of none, one, or hundreds of options in any given Theme, the WordPress development philosophy of decisions not options is often not considered with Theme development. This change will hopefully raise awareness of that philosophy. Perhaps not everything needs to be exposed as an option – and the things that are exposed as options should be as obvious and self-explanatory as possible. Again, the end user benefits from this consideration.

          Create forum topic from comment

          • I can understand, and agree with most of what you said – except for 6a.

            I think there is a significant number of users (nearly 50,000 people actively using Weaver themes at the moment) who do not want decisions made for them – they want options to make their own decisions. And they do not want to need to know all about the WP API, child themes, or writing PHP. They want the options that allow them to design a site to looks like they want, not based on decisions made by a theme designer.

            I’m the first one to admit that I am terrible at designing a nice looking site, but I’m great at figuring out the options and where to show then in a UI that allows others to build the sites they want.

            Create forum topic from comment

            • I can understand, and agree with most of what you said – except for 6a.

              But 6a isn’t directed at you. You, I’m confident, have considered the core decisions not options philosophy, and have made a conscious, reasoned, and deliberate decision to go a different route, for good reasons, that suit your needs and the needs of your end users. There’s absolutely nothing wrong with that!

              6a is directed at those who have not at least considered that core philosophy, and who provide options merely for the sake of providing options. The exercise of considering the right balance of decisions and options for a given Theme is useful and productive, regardless of the ultimate decision.

              Create forum topic from comment

          • #2 is hilariously ironic! WP has one of the most inconsistent UI/UXs out there. When the theme customizer first appeared, it looked totally out of place (and still does). UI/UX consistency is a big failing of WP (even before you install any themes or plugins).

            Look how many different media screens are there – and each a bit different to the others. Look how different the pull down help is to any other part of WP? And look how different the settings screens are to other data entry screens? The menu editor, the widgets editor, the them browser, the plugin browser etc etc etc.

            It’s like you’ve got 10 different design teams all working on their own part of WP.

            And the customizer is the most out of whack with the rest of WP of any part of the admin. As UI/UX there’s nothing else in WP like it. It’s like you’re using a whole new software.

            So you can’t argue consistency, because those theme devs with their own options page were often much more consistent with the WP UI/UX than customizer is or ever will be.

            So if you want to argue “consistent user experience”, tell WP to clean up their own backyard first.

            Create forum topic from comment

            • #2 is hilariously ironic! WP has one of the most inconsistent UI/UXs out there.

              That’s a fair criticism of WordPress, but not something that the Theme Review Team can single-handedly resolve. We facilitate the resolution to that issue by supporting core UI/UX wherever possible, and we have only enabled a worsening of the problem by facilitating the proliferation of scores of unique settings page UI implementations.

              So you can’t argue consistency, because those theme devs with their own options page were often much more consistent with the WP UI/UX than customizer is or ever will be.

              Look at the sheer number of unique implementations as the Theme Review Team has, and your opinion would likely change. The vast majority have not focused on core WordPress admin UI consistency, but rather the exact opposite.

              So if you want to argue “consistent user experience”, tell WP to clean up their own backyard first.

              That is an argument to make to the core development team and to the various UI teams – not the Theme Review Team.

              Create forum topic from comment

  62. I’m not a developer – I’m a user. I will not contribute code. I will not create a child theme. I come to WordPress to avoid all that. I have a number of friends who fit this same profile.

    I am concerned about ANY loss of theme options. I need the theme to provide everything I need regarding the look and feel of my site, and my needs are specific. The theme I settled on for my primary site took me weeks of browsing the repository to find. I chose it because it allows me to create the site I want. The LAST thing I want is fewer options, even if some are silly.

    This ‘philosophy’ that WP has adopted, insisting that there should be a consistent experience, is misguided. Consistent experience is a reduction in choices. If the default themes are WP’s idea of variety, they are completely clueless. I couldn’t even get started with those. I spent two weeks tweaking one of them for 6 hours a day, only to realize it wouldn’t give me the look I was after. The customizer needs to provide multiple full-screen pages and all the graphical widgets before it will be ready to be the only means for me to customize my themes.

    From the perspective of the end user, this decision is horrendous. WP should carefully consider how many users will be put off by this. Remember, us end users don’t give a crap about development issues, so we don’t care if the failure is the fault of WP folks or the theme developers. They are all the same to us. If WP changes to something that reduces my choices, I’ll simply move to another product.

    Even an open source product has to remember who their customers are.

    Create forum topic from comment

    • The use of the Customizer API in place of the Settings API to expose Theme options does not imply, necessitate, or force/require a reduction in Theme options. The Customizer can handle all the same options and settings fields as a settings page.

      Create forum topic from comment

      • But can it do so in a “nice” layout of options with graphical pre-decision visual clues, tips, and selection grids in the way that a full width choices/options/config page can?

        Yes, we’re back to the earlier argument about a narrow sidebar being unable to house all the choices and supporting user-help that the current system can offer – you still have not satisfactorily addressed that issue.

        Create forum topic from comment

        • But can it do so in a “nice” layout of options with graphical pre-decision visual clues, tips, and selection grids in the way that a full width choices/options/config page can?

          This is a separate question/issue, and should be treated as such. As for graphical, pre-decision visual cues: yes. You have a live preview of your entire site. Might use of the Customizer necessitate some changes in the way that a given Theme’s options are organized and presented? Sure.

          Yes, we’re back to the earlier argument about a narrow sidebar being unable to house all the choices and supporting user-help that the current system can offer – you still have not satisfactorily addressed that issue.

          The Customizer is not limited to a narrow sidebar. The issue is already addressed, in multiple ways: use CSS to modify the appearance of the sidebar; use a fly-out panel the way that Widgets are integrated into the Customizer; use a dialogue the way that the core media manager is integrated into the Customizer. Or try something else. The Customizer API is extensible.

          Create forum topic from comment

          • Visual clues – as an example – having buttons with graphics on them for – left sidebar, right sidebar, two sidebars, three sidebars, etc. etc. Same applies for menu positions, extra header and footer blocks etc, These all work well in an options page layout, but might not do so well in a customiser style side bar.

            Also, the idea is to show not just what the button does but what the effect looks like BEFORE it is applied to the page, therefore the site preview is not the requirement and does not provide the solution sought. The graphic on the button does it far more clearly.

            Flyouts? Pfftt … several people I know would immediately refuse the solution if they had to make use of such frippery. They want basic and solid, at-a-glance, blocks of options, not gizmos for spotty teenagers. We are of course talking about corporates here, though it also applies to sole traders and family businesses.

            Unless you can offer a customiser format where the page is the options and the preview is in a sidebox, you are asking everyone to accept a massive paradigm shift in site admin, and will lose a lot of supporters and users due to it.

            Create forum topic from comment

            • Also, the idea is to show not just what the button does but what the effect looks like BEFORE it is applied to the page, therefore the site preview is not the requirement and does not provide the solution sought. The graphic on the button does it far more clearly.

              I’m going to have to disagree with you on this one. A live preview shows you exactly how the change will look, on your site with your configuration, before being applied to your site. A static image graphic is a poor substitute.

              Flyouts? Pfftt … several people I know would immediately refuse the solution if they had to make use of such frippery. They want basic and solid, at-a-glance, blocks of options, not gizmos for spotty teenagers. We are of course talking about corporates here, though it also applies to sole traders and family businesses.

              I doubt corporates are using directory-hosted Themes, out-of-the-box.

              Unless you can offer a customiser format where the page is the options and the preview is in a sidebox, you are asking everyone to accept a massive paradigm shift in site admin, and will lose a lot of supporters and users due to it.

              And yet, that’s the direction that the core development team has chosen to take. Besides, the WordPress admin has undergone massive changes over the past 10+ years, and somehow the platform has survived.

              Create forum topic from comment

          • “The Customizer is not limited to a narrow sidebar. The issue is already addressed, in multiple ways: use CSS to modify the appearance of the sidebar; use a fly-out panel the way that Widgets are integrated into the Customizer; use a dialogue the way that the core media manager is integrated into the Customizer. Or try something else. The Customizer API is extensible.”

            Doesn’t that mean devs can totally change the customizer look, thereby undermining the whole point of a consistent UI?

            Which then says, this whole thing is a storm in a teacup (by both sides).

            My impression is, no matter what you give devs, they will change it in ways you never imagined, and some cases won’t be comfortable with. For example, it’s why we’ve seen so many creative, unique and left field apps for iPhones that no one at Apple ever imagined.

            We are devs. We push the envelope. Now you’re making us use the Customizer API, that’s fine, but you won’t recognize the customizer in a year’s time! :)

            Create forum topic from comment

  63. A website is the owner’s “face to the world”. People care and want a look and feel that they are comfortable with and that represents them. It is frustrating for users to not be able to achieve the vision they hold. I think that is the reason that good themes with many options are popular: they empower users to make their site look the way they want.

    One way to craft your theme is to target a particular niche or style. If that is done well then you can provide fewer options because of your focus. Themes that do that well garner a lot of respect because there is a refined care and elegance. There may be a bias, because of that appreciation, to think that carefully focusing the theme is “the right way to do it.” In my opinion, creating a well coded theme with lots of options, presented in a way that makes sense and empowers users, requires as much skill and is as worthy of respect.

    There are well coded themes with lots of options and ones with few options. Likewise with poorly coded themes. The presence of poorly coded themes is irrelevant to whether or not lots of theme options can be a good thing.

    I don’t think that the 80% rule applies to themes and plugins. Core can stay mean and lean because we have a wide variety of themes and plugins that allow people to customize their sites to their taste. Also, the non-technically minded majority are those who might find it challenging to create a child theme or who are uninterested in learning how to do so. A significant number of non-technical users like theme options because theme options are easier than creating a child theme and customizing it. Themes and plugins are all about choice. Themes with lots of options are like JetPack. Some people love them and others don’t but that has nothing to do with being “good’ or adhering to the WordPress philosophy.

    Create forum topic from comment

    • JetPack is a classic case in point – if ever there was a plugin that needed to be force-marched into using the customiser (to fit with the philosophy of the topic of the OP) then it is JetPack. Even with 10 years of developing sites on WP under my belt, half the time I still have no idea what is active or inactive in JetPack. Perhaps the wider WP devs community should take a spoonful of their own medicine before dishing it out to others.

      … and yes, I do know JetPack is a plugin not a theme … although when you look at its theme influencing elements (such as carousel, infinite scroll, etc. then you do wonder when it was allowed to cross the line.

      Create forum topic from comment

  65. If it is so much easier to use the Customizer, then why haven’t developer’s used it? There is certainly things that can’t be done with it…

    I have spent probably thousands of dollars on themes, most of the times because they offer advanced customization… Often, they are from individual developers (not a big company) and they will probably spend their time and energy creating new themes than spending a lot of time rewriting most of their older themes…

    What will happen then? Their themes (at least the customization part) will stop working? I’ll have to keep a copy of WP 4.2.2 at hand and not upgrade…

    Create forum topic from comment

    • > If it is so much easier to use the Customizer, then why haven’t developer’s used it?

      Because it’s new and people hate change. That’s why.
      Nothing will stop functioning.
      Themes on w.org will just not be accepted anymore if they use a custom admin panel instead of the WordPress Customizer.

      Create forum topic from comment

  66. If it is so much easier to use the Customizer, then why haven’t developer’s used it? There is certainly things that can’t be done with it…

    What, specifically, cannot be done with the Customizer?

    I have spent probably thousands of dollars on themes, most of the times because they offer advanced customization… Often, they are from individual developers (not a big company) and they will probably spend their time and energy creating new themes than spending a lot of time rewriting most of their older themes…

    Integrating the Customizer does not require a “lot of time”, or “rewriting” Themes.

    What will happen then? Their themes (at least the customization part) will stop working? I’ll have to keep a copy of WP 4.2.2 at hand and not upgrade…

    No. The Settings API is still in core. Themes not listed in the Theme directory are entirely unaffected by this change in requirements for directory-hosted Themes.

    Create forum topic from comment

  67. It is understood that this step is taken to allow a consistent user-experience, and the live reload is really awesome. But still an end-user will wonder – how could there be enough options in one tiny-sidebar ?
    I think the discussion boils down to one particular problem. the sidebar interface. So the next logical step for developers, is to solve the real-estate issue. Simple as that.

    Create forum topic from comment

  68. Well, here it is, a month before the “deadline”, and i’ve just completed a fairly extensive review of the current most popular, featured, and new themes, and guess what? A tiny fraction are Customizer based, and many many continue to use “Theme Options” on the Appearance tab. So, there is clearly strong resistance to this new requirement – or there will be a giant backlog of revised themes in the next month. Look out!

    Perhaps most of these themes plan to us the plugin alternative – put all the options in a plugin. The most interesting reaction I’ve seen to this requirement is with Eclipse 2, which has an almost identical set of options in Customizer and off the Appearance menu.

    But there are still a whole lot of themes Appearance Theme Options based. Sort of a worry since the deadline should be early October.

    Create forum topic from comment

  69. This entire issue is not going to go well for wordpress, developers will just move on to something else, perhaps something better than wordpress, just look back in history and see how being a narrow minded prick can harm your business.

    To be honest with all the bot net attacks, the abuse of xmlrpc.php with no admission that its a bad idea that should be removed, just proves in my mind that wordpress is going in the wrong direction.

    You can warn the guy about to drive over an unsafe bridge that there is a problem don’t go but you can’t stop him from going into the river.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.