1. Emil Uzelac

    Any theme with that many options will have some type of difficulties and personally I completely understand.

    We definitely need a better education and more tutorials how to “convert” to Customizer.

    As far as the ThemeForest and WordPress.org comparison, I don’t even know why mention, they’re two different “beasts”.

    There should be a basic understanding out there, one offers 100% free themes and most of the times themes are built the way how themer finds it fit, while ThemeForest are tailored to sell, which doesn’t mean it’s better or worse from the other.


    • Dovy

      ThemeForest and WordPress.org are the same community, but different mantras governed by different ideals. It’s a decision the .org admins have made and ThemeForest is more governed by users.

      The question is, which receives more praise? Perhaps a lesson could be learned? ;)


      • Chip Bennett

        It’s a decision the .org admins have made and ThemeForest is more governed by users.

        ThemeForest is governed by revenue. There is absolutely nothing wrong with that. But let’s not conflate “what generates the most revenue for Envato” with “what is best for end users”. Look at Envato’s efforts to improve their Theme quality guidelines (and the major pushback they got from developers), and you will see the very obvious tension between the two objectives.

        (This is not in any way intended to be derogatory toward Envato. They have a very successful business model, yet at the same time, have tried to do things the right way.)


  2. John Locke

    Thoughts on the decision to force .org repo themes to use the Theme Customizer:

    Freemium themes that were in the WP.org repository will lose customers.

    Customers are used to configuring themes one way, then have to learn another. Some themes are broken, because of how options are saved. This will drive people to ThemeForest, which they understand.

    Users want themes to “just work”, even if this means their sites are insecure, because the bundled plugins don’t update. But this is not anything they worry about. They just want to buy a theme and have it work. They do not want to hunt down plugins. This is the whole point in using ThemeForest and not hiring a developer in the first place.

    But I think the powers-that-be in WordPress have a long-term plan.

    They have no interest in launching a commercial theme marketplace to compete with ThemeForest. This would be too much control, and TF is already established as the destination for themes. No, too many problems that direction.

    But to grow WordPress from 25% to 50%, it will be a lot tougher than 0 to 25%.

    The platform will need to seen as secure, reliable, and not buggy.

    ThemeForest themes that are bloated and insecure work against this goal.

    To work on security, they must convince theme authors everywhere to unbundle plugins and themes. The customers have no knowledge of security, they want convenience.

    How to make ThemeForest authors change their coding practices? How to make themes everywhere just a bit more secure?

    Step 1 is change the .org theme repo policies. Free themes that have Premium upgrades must evolve or compete elsewhere. But this is not enough by itself.

    Step 2 has to be educating the customers to the separation of plugins and themes. This is the most difficult step, because they must unlearn what they already know.


    • Otto

      Some themes are broken, because of how options are saved.

      Could you expand on this point? The Customizer is highly extendable, to be capable of managing any type of options. If there’s a perceived way that it can’t handle, then I’d be happy to write a tutorial to demonstrate otherwise.


      • John Locke

        From the comments on the ThemeKraft post:
        “But we did not want to move existing free options to pro and that was the main issue. All premium options can be handled separately.

        The most problematical part was the rewrite from the option framework to the customizer and the different default values if an option was not set. This created messed up layouts for the options people did not used before and got a different default value.

        What I wanted to say is that it’s much more difficult to eliminate all this conflicts as it seems. The users only see the messed up layout and get frustrated.

        It took some updates to eliminate all and people still come with issues related to the option framework customizer switch.”

        I understand that the Customizer is extendable. What I’m pointing out is one bad experience is enough to drive customers from a theme shop and back to marketplace themes.


        • Otto

          Yeah, that doesn’t seem like a valid criticism of the Customizer itself. There’s no reason defaults should change. Defaults can be specified.


        • Chip Bennett

          The most problematical part was the rewrite from the option framework to the customizer and the different default values if an option was not set.

          This is an issue with the options framework itself, not properly handling default option values. It has to do with an incomplete implementation of the Options API (or Theme Mods API), in which the framework either did not define, or did not specify in the get_option()/get_theme_mod() call, the default value for the option being used.

          It has nothing at all to do with the Customizer, which can seamlessly interact with both the Options API and the Theme Mods API, and will use default values, if those defaults are provided.

          This isn’t a problem isolated to ThemeKraft. Several of the options frameworks in wide circulation weren’t properly implementing defaults (what the TRT refers to as “sane defaults”). It was so much of an issue that, some time back, the TRT had to implement a requirement that Themes use sane defaults for all options.

          (As an added bonus for users, part of “sane defaults” implementation is that Themes are required NOT to save option values to the database, unless the user does so, via explicit action to save settings.)

          So, is the Customizer *causing* any new problems? No. But it very well may be *exposing* problems that *already existed*.


    • Dovy

      Perhaps in concept, but it sure is a different experience for the user.

      Yes, you can use the same options and migration to the customizer. It’s just going to take a bit of effort.

      Essentially the customizer in theory is not to blame, but learning a new API, a new way of doing everything, and porting all that code over is going to make every established theme dev cry. :P


      • Chip Bennett

        Essentially the customizer in theory is not to blame, but learning a new API, a new way of doing everything, and porting all that code over is going to make every established theme dev cry. :P

        That really depends on the quality of the underlying code, and the approach taken. Anyone using an options framework library, or who otherwise uses an array-based options development will be able to port those options to the customizer with a couple hundred lines of code. I was able to do it with about 100 lines of code:


        If, on the other hand, options are not array-based? Yeah, that’s going to be quite a bit more difficult. But the real problem there is using inefficient coding practices that don’t scale. And honestly, I don’t think there are many developers at all anymore who would fall into that category.

        And then there are the Themes that are doing non-Theme things with their Theme options.

        As for making established Theme devs cry? I actually enjoyed learning a new API, when I decided to incorporate the Customizer three years ago.


  3. Andre

    It’s going to be tough for existing themes that have a lot of options built in. As one who started to use the customizer in my themes, it’s been very easy for me because I’ve been using the customizer for 2+ years. I can understand the frustration this new direction is going, but I believe this is the right direction for themes that want to exist in the .org repository. Authors do have the choice to not follow suit with their premium themes, but I can only say to each one to realize that more changes will be coming over time.

    Perhaps it might have been better to simply create a new repository at .org for “premium free” based themes that offer better design and initiate the new changes and development guidelines instead of trying to change the one that has been in place for such a long time; only to gradually phase it out.

    In the meantime, theme developers will need to educate their users and potential users of the why’s and benefits of the changes. It’ll ruffle some feathers, but eventually over time, things will balance out.


  4. Justin Tadlock

    Jeff, there’s so much of this discussion that has little-to-nothing to do with the recent theme settings guideline change. Sure, there’s a lot of interesting discussions and things worth talking about (some dealing with TRT, some not), but I tend to be a fan of staying on topic. Otherwise, you get lost in a sea of 175 comments with half talking about things unrelated to the topic at hand. Of course, if that’s what you’re going for…

    I’m sure anyone on the TRT would be more than willing to tackle any questions you have with open and honest answers. All you need do is ask.


  5. Dot 07

    As someone who is a user and helps develop plugins as well as interfaces between developers and users, I don’t find that there is much problem switching users over to using the Customizer for themes. In fact, there is one or two very popular plugins hosted on Codecanyon which provide frontend customizing because there is a growing interest in being able to see what is being modified in a theme.

    That also provides an opportunity to see how some plugins appear after the theme adjustments.

    I welcome the change to using the WP Theme Customizer.

    As a user myself, and switching between themes on a regular basis for testing and setting up sites for others, I like to have something that is more standard when making modifications when I do make changes in different themes. It is a real headache sometimes going from one theme options to another and figuring out how the theme has laid all of those options out when I try a new theme.

    As with everything, there is an adjustment period needed for users. I am quite sure there is also an adjustment for developers as well. But to be quite honest, most users I have run across are aware that things are changing in WordPress, Plugins and Themes. Unless they are a noob, change is something they are well aware of and in most cases they have welcomed it once they understood it. And I’m not afraid to share whatever I know. I think that’s the key. Help the user understand what is happening. It is work, but I think it is worth it.

    I don’t think Themeforest is off topic as it was mentioned in the post. I don’t like a lot of what they offer because of many of their “authors” not following the standards of WordPress. I know many users who feel the same because a lot of those themes don’t work well with a lot of plugins hosted on WordPress. I disagree with the thought that most users want a one off solution. If that were the case, there wouldn’t be a great number of new plugins on WordPress.org adding new users every day by the thousands and I don’t think Codecanyon would be selling thousands of plugins every day. I think theme developer perception may be a little off in that area if they believe one off solution is more desired by “most” users.

    Back to topic, I think the trend is going to be more for seeing what is being modified as it is being modified. And I think the trend more toward mobile devices is encouraging that. So, while it may appear to be a change that may make people look somewhere else for the moment, I believe in the long run, it will work in favor of WordPress Customizer.

    Thanks WordPress.


  6. Dave Chu

    Fascinating article, Jeff.
    I have been experimenting with putting options in the Customizer myself, and I like it. I’m sure many users won’t – the simple fact that it’s quite narrow will put many off. But I digress…

    When I’ve done experimental work with fuller options panels, many of those are available as plugins. So couldn’t someone still “qualify” for being in the repository by breaking their options out into a “recommended plugin” and get the best of both worlds?

    Or is the mothership discouraging non-Customizer options plugins as well?

    Thanks, Dave


  7. Andreas Nurbo

    After working with Customizer a bit I really dont like it. I find it somewhat convoluted. And that is with just minimal stuff in the Customizer. Been working with some free themes I found at wp.com, adding more controllers and what not.
    Its hard to get an overview, its hell to combine it with responsive behaviors, there is a lot of steps just for adding a minor color change. You write the PHP code for the controller, then you need to write the controller for the JS part, then you need to write the code for the actually printing of the CSS code on the frontend. Also some parts does not seem to work with HHVM. Image controller generates ArrayAccess exception (when I try it out atleast).
    From my point of view the Customizer is “broken” from the ground up. I werent claustrofobic before but after making theme changes through the customizer I want to screem and run around on the plains waving my hands in the air.


  8. Terence Milbourn

    Any time a business uses some form of leverage of its dominant market place position to force its market to do what it wants, rather than concentrating its efforts into giving its market what it wants, there will be A) ship-jumpers B) loss of market share and C) unintended consequences .

    But all that pales into insignificance compared with the loss of respect and good will it creates.

    Far better to have your market keep you on the right track than to try and force them onto the straight and narrow.


Comments are closed.

%d bloggers like this: