Themekraft’s Difficult Experience Switching to the WordPress Theme Customizer

Sven Lehnert, CEO of Themekraft, published his company’s experience migrating from a custom theme options page to the theme customizer. He describes how difficult it was to move between the two and how it caused user frustration.

“I’m sorry for the trouble some users are experiencing. We receive positive as well as frustrated feedback and I understand how users feel this way,” Lehnert said.

Custom Theme Options Page
Custom Theme Options Page
Using the Customizer
Using the Customizer

Themekraft is migrating to the customizer because of a new requirement that forces themes hosted in the WordPress theme directory to use it to build theme options. The requirement has sparked controversy and with 175 comments, is the most discussed article in Tavern history.

Consequences of Doing the Right Thing

Although Themekraft believes the requirement is the right decision, it’s come at the price of losing users. Lehnert expressed frustration that doing the right thing has caused users to jump ship, “I think it’s really frustrating, that our choice to use the customizer to create better themes has made users switch to a different theme. Our decision to use the customizer has pushed users to Themeforest.

A lot of users have told us they moved to Themeforest and gave up on themes hosted on WordPress.org. To them, Themeforest does the job of WordPress.org and WordPress.org themes are outdated with limited functionality.”

Two to three years ago I would have agreed with the opinion that themes in the WordPress theme directory leave a lot to be desired. I’ve read enough reviews of great looking free themes that I’ve nearly erased this mindset. I used to discourage users from browsing for themes on the directory, now I encourage them.

The Educational Problem

Chalkboard Learning
photo credit: Clint Gardnercc

For years, the WordPress community has discussed and educated users on why it’s important to separate presentation from functionality. Lehnert thinks it’s something normal users can’t understand, “They want to buy solutions and base their purchasing decisions from a graphical point of view. The separation from design and functionality is not understandable for the normal user.”

In a recent comment on the Tavern, Chip Bennett explains his perspective on the educational part of the problem, “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.”

There’s been some movement on this front with some theme authors moving theme functionality back into plugins.

Part of the problem is explaining the difference between themes and plugins. If you ask 10 WordPress developers where the line is drawn, you’d likely get at least five different answers. Since plugins can do everything a theme can do, it can easily become a never-ending debate between presentation and functionality.

The Balancing Act

Creating a WordPress product that balances user and developer needs is tricky. The main impetus for requiring the theme customizer is to provide a standardized experience between all the themes hosted in the directory. It will also help the Theme Review Team review themes more efficiently.

Lehnert trusts the Theme Review Team’s decision but feels the change is geared towards developers. “I really believe in the WordPress community and I trust there will be a solution to the problem some day. At the moment however, the theme review guidelines only make sense from a developer’s perspective.”

He suggests that the WordPress theme directory add support for better theme previews with customizer access. This way, users can see how flexible and customizable a theme is.

Food for Thought

Based on Lehnert’s experience, there is a perception problem between WordPress.org hosted themes and those on Themeforest. It will be interesting to see if other theme authors and companies have a similar experience when they make the switch.

It was disheartening to read this statement by Lehnert, “In the case of a theme business, staying outside of the community is easier!” Developers and users have at least one thing in common, they don’t like change, especially when it comes to requirements or guidelines. Developers have always had two choices:

  1. Abide by the requirements and guidelines to have a plugin or theme hosted on WordPress.org
  2. Do things on your own terms through your site and GitHub

Outside of WordPress.org, it’s the wild west. You can use whatever custom options page or framework you want without anyone telling you what to do.

Theme developers and companies are going to experience growing pains meeting the new requirement, but I think users of themes hosted on WordPress.org will be better off in the long run. They’ll know what to expect thanks to a standardized interface and eventually get used to interacting with the customizer.

16 Comments


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

    Report


    1. 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? ;)

      Report


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

        Report


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

    Report


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

      Report


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

        Report


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

        Report


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

        Report


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

      Report


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

        https://github.com/chipbennett/oenology/blob/master/functions/options-customizer.php

        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.

        Report


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

    Report


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

    Report


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

    Report


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

    Report


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

    Report


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

    Report

Comments are closed.