![\"Theme](\"https:\/\/wpmudev.com\/blog\/wp-content\/uploads\/2014\/11\/theme-customizer.png\")
<\/a>Building Our Foundation<\/h2>\n
The key to the customization API is the The recommended way of creating theme settings is to encapsulate them in a class. In our initial examples, I will not<\/em> be adhering to this recommendation to make sure it is clear what\u00a0is part of the customization API and what isn’t. I will complete the article with a class-based implementation.<\/p>\n Let’s begin by creating a function in our theme’s Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div><\/span><\/p>\n As mentioned in the example, each item you add to the customizer consists of three parts:<\/p>\n If the separation between a control and a setting seems confusing, think of it like this: When you create a setting you tell WordPress that there is indeed a setting for font color and the default value for this is #444444. In itself, this already means that this setting can be used.<\/p>\n However, the theme customizer needs to know how to manipulate this setting. You could create a text field for it where the user enters new colors manually as “#ff9900” but you could also specify a color control, which would output a color selector. On a database level it will all still boil down to a hex color, but the user-facing side is different.<\/p>\n The Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div><\/span><\/p>\n Most of this is pretty self-explanatory. Note the priority, though! This determines the order of the section on the screen. I like to increment my options in tens. If I need to insert a section between two existing sections I won’t need to re-index everything, I can just assign the new one 95.<\/p>\n Note that sections will not<\/em> show up when empty. You must add a setting and a control to them before they are shown.<\/p>\n Settings are created with the Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div><\/span><\/p>\n There are a bunch of options we could add here but for now this will do just fine. Note that settings are not tied to section. As I mentioned settings are simply registered with WordPress. It is up to controls, which are tied to sections to manipulate them.<\/p>\n Controls are put in place with the Here’s how I created the control which modifies the footer background color:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n I’ve passed a control object to the Note that the control is where it all comes together. Once all three have been set up, you should be able to reload the customizer and see your work.<\/p>\n By default, settings are saved in a theme_mod. Theme_mods are an alternative to the Settings API, they provide an easy way of handling theme-specific settings. All you need to do to retrieve the value of a setting is use the Let’s add some dynamic CSS to our website by hooking into Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div><\/span><\/p>\n Live previews for settings are not enabled by default. To use them you must do three things:<\/p>\n The only irregular thing about this step is that we need to use the Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div><\/span><\/p>\n This one is pretty easy. In the arguments for our settings we need to define a Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div><\/span><\/p>\n We’ll need to use the Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div><\/span><\/p>\n Out of all that we only need to write a line, use this copy-paste template for live preview writing speed:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div><\/span><\/p>\n Encapsulating in a class is a good idea because it allows you to write better function names and to make your code more cross-theme compliant, should you have multiple themes in the works. Here’s how I did it for our example above.<\/p>\n WP_Customize_Manager<\/code> class, which can be accessed through the $wp_customize<\/code> object. We will be using various methods defined in this class to add settings sections and controls within them.<\/p>\nfunctions.php<\/code> file, which will allow us to include our additions in the customizer. This function needs to be hooked to customize_register.<\/code><\/p>\nThe Components Of A Theme Setting<\/h2>\n
\n
Creating A Section<\/h3>\n
add_section()<\/code> is used to create sections. It takes two parameters, a section slug and an array of arguments. Here’s an example of how I set up a section for footer options in a theme.<\/p>\n![\"Custom](\"https:\/\/wpmudev.com\/blog\/wp-content\/uploads\/2014\/11\/sections.png\")
Adding Settings<\/h3>\n
add_setting()<\/code> method. They, too, take a slug as the first parameter and an array of arguments as the second. Take a look below for an example of adding a background color to our section above.<\/p>\nCreating A Control<\/h3>\n
add_control()<\/code> method. This method takes a slug and an argument array or it can also receive a dedicated control object. A control object is used for more complex controls such as color selectors or file uploaders.<\/p>\nadd_control()<\/code> method. This object should be constructed by passing the $wp_customize<\/code> object as the first parameter, a unique ID\u00a0for the control as the second and an array of arguments as the third.<\/p>\nsection<\/code> is set to the id of the section we created and settings<\/code> is set to the id of the setting.<\/p>\n![\"Some](\"https:\/\/wpmudev.com\/blog\/wp-content\/uploads\/2014\/11\/customizer-controls.png\")
Using Setting Values<\/h2>\n
get_theme_mod()<\/code> function with the id of the setting passed to it.<\/p>\nwp_head<\/code> and using our saved setting:<\/p>\nLive Previews<\/h2>\n
\n
Enqueueing The Live Preview Script<\/h3>\n
customize_preview_init<\/code> and we must<\/em> make sure that ‘jquery’ and ‘customize-preview’ are loaded before our script. Other than that it’s a standard enqueue pointing to a javascript file in our theme:<\/p>\nAdd live preview support for setting<\/h3>\n
transport<\/code> key and set its value to postMessage<\/code>. Let’s revise our code from before:<\/p>\nCreate the Javascript code to take care of each setting<\/h3>\n
wp.customize()<\/code> function in Javascript. This function should be given the id of the setting as the first parameter, the second is a callback function. Inside we bind a function to the change of the setting and write our code which will take care of the change.<\/p>\nEncapsulating In a Class<\/h2>\n