WordPress’ native customizer has evolved considerably since its early days when it when it was introduced for adding live previews to themes. WordPress 3.9 added widgets to the customizer and the 4.0 release is set to expand the role of the feature into other aspects of WordPress with support for a wider array of controls.
Developers are eager to find new ways to harness the power of the customizer without getting caught up in writing a ton of code. Devin Price, co-owner of DevPress, is working on a new project to create a Customizer Library. The library is designed to abstract out some of the complexity of working with the customizer so that developers can easily add options by defining a simple array.
Price describes the Customizer Library as “a collection of classes and functions that make it a bit easier to develop for the WordPress Customizer.” The library currently includes helper functions for Google fonts and inline styles, but he’s considering removing them into their own repositories in order to keep the project more focused for general use.
The library can be included in a theme or plugin as a git submodule, according to the installation instructions. Price has built in only one custom control, for textarea, but he plans to add additional custom controls as the library matures. It currently supports the following options:
- Checkbox
- Select
- Radio
- Upload
- Color
- Textarea
- Select (Typography)
An example theme can be found in the Customizer Library Demo repository, which shows how to use the library to create options such as logo, primary and secondary colors, textareas, checkboxes, etc.
The Customizer Library project is somewhat similar to the Kirki plugin, which aims to provide a framework for adding advanced controls. Although the projects are constructed differently, they both abstract the Customizer API to make it easier to add options. As the customizer evolves to become more powerful with more controls, libraries/frameworks like these provide an entry point for developers who want a quick way to build options.
If you want to use the customizer in your projects but are having trouble getting a handle on it, the Customzer Library might be a reasonable starting place. Price is looking for feedback and suggestions as he continues to develop the library as a standalone project. You can help shape its future by joining the discussion on the post where he introduces the library.
I don’t think that this framework really makes it much easier to use the Customizer. Ultimately, you’re just passing it arrays of options which is exactly how the Customizer API itself works, and you won’t end up saving many lines of code. While it removes the need to create settings and controls separately, on the other hand it raises the barrier to entry for anyone who starts looking to do more advanced things with the Customizer, as they must then learn the actual API, which is only slightly more complicated. Removing the direct ability to do things like set capabilities doesn’t actually simplify the API, since you can just leave those parameters out if you don’t need them. The core Customizer API is actually very well-designed and is easy to pick up as you start with it, even if you’re just copying & pasting for a while.
The other issue with Customizer frameworks is that they’ll ultimately move slower than, or miss out on, improvements to the Customizer in core. The textarea control type is in core in 4.0, along with support for arbitrary types, control descriptions, and much more. Frameworks would have to implement new features as well, and looking through the code here it really doesn’t make it any easier to develop for the Customizer (and I also see some pretty fundamental bugs in it).
Of course, the exception to all of this is specialized controls like a typography select or advanced color palates like WordPress.com uses. But those should just be distributed as custom controls, not entire frameworks, and could eventually be added to WordPress core if they have broad enough use cases.