Philip Newcomer

<p>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.</p>
<p>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.</p>
<p><em>This plugin is currently in beta, and may be subject to major changes as it matures.</em></p>
<h4>Issues and Support</h4>
<p>Contribute to the project <a href="https://github.com/philipnewcomer/Customizer-Framework" rel="nofollow ugc">on GitHub</a>.</p>
<h4>Why a Framework for the Customizer?</h4>
<p>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.</p>
<p>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.</p>
<h3>Usage</h3>
<p>Activate the plugin, or <code>include</code> it in your theme.</p>
<p>Before creating any settings, you need to create any new Customizer <a href="https://codex.wordpress.org/Class_Reference/WP_Customize_Manager/add_section" rel="nofollow ugc">sections</a> that you wish to use. Any custom sections need to exist before you can add settings to them.</p>
<p>Finally, initialize a new <code>CustomizerFramework</code> class, and add your settings:</p>
<pre><code>function mytheme_register_settings( $settings ) {

    $settings[] = array(
        'id'      => 'example_setting',
        'label'   => 'Example Setting Label',
        'section' => 'example-section',
        'type'    => 'text', // Optional, defaults to 'text'
        'default' => 'Example section default text', // Optional
    );

}
add_filter( 'customizer_framework_settings', 'mytheme_register_settings' );
</code></pre>
<h4>Setting Types</h4>
<p>Here are the currently available setting types:</p>
<ul>
<li><code>checkbox</code></li>
<li><code>color</code></li>
<li><code>dropdown-pages</code></li>
<li><code>image</code></li>
<li><code>radio</code></li>
<li><code>select</code></li>
<li><code>text</code></li>
<li><code>textarea</code> (requires WordPress 4.0)</li>
</ul>
<p>The <code>radio</code> and <code>select</code> types require an additional <code>choices</code> parameter, containing an array of the valid choices:</p>
<pre><code>'choices' => array(
    'choice_1' => 'Choice 1',
    'choice_2' => 'Choice 2',
    'choice_3' => 'Choice 3',
),
'default' => 'choice_1',
</code></pre>
<p>In addition, on WordPress 4.0, you can specify any additional HTML5 input types, such as <code>url</code> or <code>date</code>. You can also include an <code>atts</code> parameter, containing an array of additional input attributes which should be applied to the input:</p>
<pre><code>'type' => 'url',
'atts' => array(
    'placeholder' => 'http://',
    'class'       => 'a-custom-css-class',
),
</code></pre>
<h4>Sanitization</h4>
<p>All settings are sanitized automatically, based on the setting type. If you wish to specify your own sanitization function for a setting, add a <code>sanitize_cb</code> parameter, containing the function name to be called, which should return the sanitized value.</p>
<pre><code>'sanitize_cb' => 'my_custom_example_setting_sanitization_function',
</code></pre>


Customizer Framework

A lightweight and easy-to-use framework for the WordPress Customizer.

pootlepress

shramee

Jamie Marsland

<h4>Storefront Pro Skins</h4>
<p>Allows you to save instances to customizer settings and appy later on demand.</p>
<p><iframe loading="lazy" title="Storefront Pro Skins" src="https://player.vimeo.com/video/201163462?dnt=1&app_id=122963" width="750" height="422" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write"></iframe></p>


Customizer Framework vs Storefront Pro Skins