A lightweight and easy-to-use framework for the WordPress Customizer. Provides a simple and intuitive API for registering Customizer settings, including advanced control types. Automatically sanitizes settings based on the control type. Eliminates the tedious task of registering a setting, control, and sanitization function for each individual Customizer setting.
The framework may be used by both plugins and themes, although since at this time the settings are saved as theme mods, any plugin settings will be specific to the active theme. Support for option type settings is planned.
This plugin is currently in beta, and may be subject to major changes as it matures.
Issues and Support
Contribute to the project
on GitHub.
Why a Framework for the Customizer?
The recent WordPress Customizer API suffers from some of the same issues afflicting the old Settings API. The Settings API was overcomplicated, unintuitive, and confusing. The result was a crop of theme option frameworks that have sprung up to make it easier for developers to create theme options. The Customizer API is a bit better, but it's still more complicated than necessary, and registering Customizer settings is still a convoluted mess of settings functions, controls functions, and sanitization functions. Now, the ease of use which the theme option frameworks have provided for the Settings API is available for the Customizer, in the Customizer Framework plugin.
The Customizer Framework aims to be a lightweight wrapper around the convoluted Customizer API, which makes it fun to be a WordPress developer again. Developers can now focus their time on creating great themes that utilize the Customizer, not on writing 500 lines of code in order to create 10 Customizer settings. Okay, so I might be exaggerating a bit. But not by much. Do you really want to spend your time registering a Customizer setting, then registering a control for that setting, and then writing a sanitization function for that setting? And that's only for one setting! And then there's the advanced controls, such as image or color, that require you to instantiate their own control class, requiring even more convoluted and unintuitive code. And why should you even have to care about the differece between a setting and a control? Don't you have better things to spend your time on, like creating great WordPress themes? I thought so.
Install like any other plugin. If you're a theme developer, then you already know how to install a plugin, and I won't bore you with the details. See
Other Notes for usage instuctions.
If you're creating a theme for public release, I recommend that you consider using the
TGM Plugin Activation library to make it easy for your users to install the Customizer Framework after activating your theme.
You could also
include the plugin it in your theme, but remember to check for the existince of the plugin version first to avoid conflicts.