With the recent change to WordPress.org requiring themes to use the WordPress Theme Customizer in their work, WordPress designers and developers have been talking about it and discussing it for several weeks now.

And rightly so: Many of us are fans of the customizer, many are not, some fall in between, and some wish that there was a compromise.

As far as I’m concerned, that’s fine (though maybe I’m biased because I tend to be a fan of the Customizer), but whatever the case, this doesn’t change the fact that there’s a lot of education that needs to happen around how to use the API – which isn’t terribly difficult (in comparison, to say, the Settings API) – and how to make the transition over to it.

WordPress Theme Customizer Resources

A few days ago, Justin Tadlock shared a terrific post on the Theme Review Team blog that lists out 20-some-odd resources to get you up and running with the the Customizer.Customizer ResourcesIf you’re new to the Customizer, then I highly recommend reading this article as well as those that are linked in the post. Additionally, I wanted to include some of the resources that I’ve shared in the past in order to further the educational component of this particular transition.

My WordPress Theme Customizer Resources

Technically, the WordPress Theme Customizer is going to be called “The Customizer” and many people are already referring to it as such; however, many of the articles and resources I’m going to provide are done so prior to when that language transition took place.

Regardless, many of the things still stand.

  1. A Guide To The WordPress Theme Customizer. This is a five-part series that I wrote for Tuts+ that covers what it is, why it matters, understanding sections, settings, and controls, a methodology for working with them, and advanced controls.
  2. Maintainability of WordPress Theme Customizer Code. Earlier this year, I published a post that covers several things that I do that make sure that Customizer-based code is as maintainable as possible.
  3. Theme Customizer Example. This is a GitHub repository that is an installable theme for WordPress that uses the Customizer to introduce a couple of new settings into the Customizer. This is intended to demonstrate the practicality of the details as outlined in series in the first link.

Again, these are meant to be shared in addition to to the links as shared by Justin on the Theme Review Team’s blog and not mean to replace them by any means.

There are fantastic resources available on that page and I don’t recommend skipping them – I simply wanted to share my personal contributions to this particular feature of WordPress in hopes of making the adoption of this requirement just a little bit easier.

Category:
Resources
Tags:

Join the conversation! 10 Comments

  1. Tom, The customizer is a great idea, almost regardless of whether one likes its UX.

    Problem is, it isn’t being implemented CONSISTENTLY (http://wordpress.answerguy.com/making-wordpress-easy-theme-customizer/2015/04/30), and absent that, it’s of no “real value”.

    Genuine pity that WP has chosen to mandate its use, but other than “use it or go away” hasn’t given any useful reason TO use it. :-(

    • Problem is, it isn’t being implemented CONSISTENTLY

      The example given is orders of magnitude more consistent than the myriad custom settings page UI implementations that we see today.

      but other than “use it or go away” hasn’t given any useful reason TO use it.

      This statement is patently untrue. The TRT have discussed the reasons for use of the Customizer, on the Make/Themes site, on Slack, in the comments of the WPTavern post. Have you read them there? I could repeat them here.

      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.

      That’s just a few – and focusing on the benefits of the Customizer, and not on the potential detriments of using custom settings pages using the Settings API.

      • Chip, it may be “true” that guidelines for good use of the customizer have been suggested, or even “mandated”.

        HOWEVER, to my understanding the only real mandate is that developers use it if they wish to remain eligible to be in the repository moving forward. And there’s no consistent set of things to “use the customizer for”.

        Now of course that’s unavoidable at some levels. Sure “make a color picker for each of the following elements” would be easy. But what about developers who keep adding and adding and adding things to themes, thereby making the customizer itself look different? I think of Theme.co’s “X”, and Themify’s “Ultra”; both are superb in their way and both pack way more in there than other developers do. And each does it very differently.

        So we end up with a mandate to use a “standardized tool” that’s already nothing of the sort. At that point, one might as well move over the the Elegant Themes model where they just barely use the Customizer (BUT THEY USE IT!!!!), but also keep much of the customization action outside the Customizer, in their own interface.

        No standard. Speaking pragmatically, none (really) possible. And as such, no real value in the mandate.

        • Jeff Yablon http://wordpress.answerguy.com >

          Chip, it may be “true” that guidelines for good use of the customizer have > been suggested, or even “mandated”.

          HOWEVER, to my understanding the only real mandate is that developers use > it if they wish to remain eligible to be in the repository moving forward.

          And there’s no consistent set of things to “use the customizer for”.

          The only thing that the Customizer API is required to be used for is to expose Theme options for user configuration. If a Theme does not have Theme options to expose, then it is not required to use the Customizer API.

          Just to be perfectly clear: directory-hosted Themes are NOT REQUIRED to use the Customizer. Rather, directory-hosted Themes are required to expose Theme options via the Customizer API, rather than via the Settings API.

          The required use of the Customizer API is tied solely and directly to Theme options.

          Now of course that’s unavoidable at some levels. Sure “make a color picker > for each of the following elements” would be easy.

          The Theme Review Team is not in the business of telling Theme developers the elements of their Themes that must be user-configurable via Theme options. If a Theme developer doesn’t want to have any Theme options at all, that’s perfectly acceptable.

          But what about developers who keep adding and adding and adding things to > themes, thereby making the customizer itself look different? I think of > Theme.co’s “X”, and Themify’s “Ultra”; both are superb in their way and > both pack way more in there than other developers do. And each does it very > differently.

          So we end up with a mandate to use a “standardized tool” that’s already > nothing of the sort.

          And how is that any different from the status quo? At least, by requiring use of the Customizer API for exposing Theme options, the UI will be consistent, even if different Theme developers organize the options for their Themes differently.

          At that point, one might as well move over the the Elegant Themes model > where they just barely use the Customizer (BUT THEY USE IT!!!!), but also > keep much of the customization action outside the Customizer, in their own > interface.

          Except that’s exactly what we intend to avoid. Any and all Theme options, if present, must be exposed to the user using the Customizer API, and not the Settings API.

          No standard. Speaking pragmatically, none (really) possible.

          Again: how is that any different from the status quo? How do end users benefit from having scores of unique, different settings page UIs?

          And as such, no real value in the mandate.

          I just listed 6 examples of very real value, to developers, end users, and the TRT. That solving a presently unsolvable problem isn’t one of them doesn’t diminish their inherent value.

          • Chip, I never said, nor meant to imply, that there wasn’t inherent value to either the customizer or your points. ll I’m saying is that the way the new rule has been implemented isn’t good ENOUGH.

            We can agree to disagree if that’s the way this falls out. Thank you sincerely for taking the time/expending the effort to express yourself vis a vis what I’ve said!

            • So, if the way the new requirement has been implemented isn’t enough, what would you consider to be enough? Serious question, and I appreciate your input.

              And related (I think?): would whatever you consider to be “enough” apply only to the implementation of the Customizer API, or would it apply equally to implementation of the Settings API?

              • Chip, my problem here goes to what is feeling more and more like an (almost) unsolvable problem.

                As much as I like the idea (ideal?) of open-source, and as much as I appreciate the tireless efforts of folks who contribute to the cause, it’s becoming more and more apparent to me that the decentralized nature of the WordPress model is becoming a problem.

                With no one “steering the ship” (and kudos to great people like Andrew Nacin taking charge of versions, but I’m talking bigger picture), there’s by definition no central strategy for where this puppy “goes”. As another example, I’ve commented on the REST API (http://wordpress.answerguy.com/should-wordpress-rest-the-wordpress-rest-api/2015/05/11), and I see a similar problem; great idea, great execution by the people executing it technically speaking, but ultimately counterproductive to the platform.

                So with the Customizer, my feeling is that short of developing a far-reaching, must-be-adhered-to standard (umm … is that counter-open-source? dunno; probably) and enforcing it (“you’re out of the repository, dude”), all we have is the ever-problematic “best practices”.

                And I think best practices make for great guidelines, but ultimately are a load of hooey.

                So, I’m taking you seriously, too: can you think of a way to “stay with open source”, but also exert more—and more meaningful, pragmatically—control?

                • I agree with most of your concerns, Jeff. I’ve raised those issues over several years. But they’re not problems that the Theme Review Team is ever going to be in a position to resolve. I don’t think we’re trying to tackle those problems directly, with the Customizer requirement, or with anything else we do.

                  That said, we do our best to ensure that review requirements align with core-development direction, as best as we can. That means that we require directory-hosted Themes to use core implementations of features if such exists, rather than creating a new/different implementation of that feature (e.g. comments, nav menus, custom backgrounds, custom header images, widgets, etc.)

                  I wish we had a roadmap; I really do. It would really make decisions much easier. As it is with the Customizer, it is a decision three or four years in the making, because we had to infer core development intent by watching the progress of the Settings and Customizer APIs. If, three years ago, the core development team had given us some heads-up that the Customizer was intended to be so tightly integrated in the user Theme experience, and that the Settings API was going to be left to wither on the vine, we wouldn’t be having this discussion today.

                  I don’t see the TRT review requirements as in any way contrary to open source development or principles. The TRT reviews and approves Themes to be hosted in the wordpress.org Theme directory; no more, no less. Themes not hosted in the directory are under no obligation to follow any of the TRT review requirements. Anyone can do anything they want to do with WordPress Themes.

                  So, our approach with the Customizer API will be the same as our approach to any other core API: Themes will need to implement it by using that API properly. Will there be “best practices” around API implementation?

                  Perhaps. Sometimes there are, sometimes there are not. We got almost no traction with “best practices” for Settings API implementation. Many of the options framework developers basically said, “Sane defaults? Ain’t nobody got time for that!” until the TRT made use of sane defaults a requirement.

                  Over the past five years, I’ve seen some wins and some losses in TRT’s efforts to define and to propagate various “best practices”. Sometimes it works, and sometimes it doesn’t. We’ve learned to pick our battles. One of the main reasons that I spent a lot of time speaking at WordCamps was for that very purpose: to educate about various “best practices”. Overall, I do think TRT’s efforts have borne fruit.

                  And I think that’s really the way to stay true to open source principles, yet exert more “control”: educate people about what “best practices” are, show them why, and teach them how to implement them.

  2. Thanx tom to sharing g8 info. I m also web designer and recently started worked on wordpress theme. I sure it will be helps me in lot of things..

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.