Tag Info

Hot answers tagged

12

The premise of the question is flawed. The Customizer API is not an options API, but rather an options preview API. The Customizer API relies on either the Settings API or the Theme Mods API to register controls for existing settings added via either of the two APIs. The Customizer does not - and cannot - define/register new settings that have not already ...


10

Our journey starts here with the WP_Customize_Background_Image_Control class, which is a WP_Customize_Image_Control. I'd imagine offering these built-in backgrounds in a new tab alongside the existing Upload New and Uploaded tabs. There are at least two ways of achieving the following: either creating your own modified class based off of the ...


9

There's a few bits here that apply, but the short of it is this code in customize-preview.js: this.body.on( 'click.preview', 'a', function( event ) { event.preventDefault(); self.send( 'scroll', 0 ); self.send( 'url', $(this).prop('href') ); }); The event.preventDefault prevents the links from actually working. The following code then sends a ...


8

Example and class for usage You can see on my current theme, how it's possible to use this. Also you can usage the class. See this class on Github an check the functions.php for include this. Start & init You can register your custom settings for the theme customizer via the customize_register hook: add_action( 'customize_register', ...


8

This drove me mad for a while, but I got it to work by adding them with the full arguments that are used in the admin script loader rather than just referencing the handle. When I print the $wp_scripts global on the front end, iris and wp-color-picker are nowhere to be found, though all of their jQuery UI dependencies work. Anyway, not sure this is right, ...


7

If you need them in a specific order, then give a priority value to the controls. Otherwise, their order is not defined and cannot be guaranteed. If you don't define a priority, then the control gets the default priority of "10". When two controls have the same priority, then the resulting order is undefined, because that's how PHP works.


5

Okay, first, let's set things up properly, with a callback hooked into an appropriate action hook: <?php function wpse55227_enqueue_scripts() { // Enqueue code goes here } add_action( 'wp_head', 'wpse55227_enqueue_scripts' ); ?> We'll put all of our code in to this callback. The next step is to add our if ( ! is_admin() ) conditional wrapper: ...


4

Here is one way to do it by extending the control you want to use. Below is an example where we extend the text control and add an extra description like the one seen here on the screenshot: function mytheme_customizer( $wp_customize ) { class Custom_Text_Control extends WP_Customize_Control { public $type = 'customtext'; public ...


4

Not sure what you try to accomplish, but you can get a value by key using the wp.customize object: wp.customize.value('show_on_front')(); wp.customize.value('blogname')(); .... sorry no jQuery here, just javascript, and yes, the extra () are intentional. Edit: Full overview of all settings: wp.customize._value; console.log(wp.customize._value); Edit ...


4

As simple as things can sometimes be: The Settings API is not the Theme Customizer. Both are different things for different tasks. Settings API You're either writing a plugin or have a theme that doesn't have options that won't need any visual feedback? Go with this option. Theme Customizer You need to have options that have a visual impact that the user ...


3

While this might not a be the perfect solution but this should work. You can set an interval to check against the preview iframe, like this: var previewDiv = $('#customize-preview'); previewDiv.prepend('<div class="loading-overlay"></div>'); var loadingOverlay = previewDiv.find('.loading-overlay'); setInterval(function(){ if( ...


3

The answer that yes, the theme_mod functions will be slower, but not significantly, and the benefits outweigh the differences. Theme mods are stored as options. So, in essence, the theme_mod functions are wrappers around the options functions. First, understand that theme_mod settings are stored as an array in a single option, keyed to the specific theme ...


3

Yes. wp.customize( 'header_textcolor' )(): ( function( $ ) { //Update site background color... wp.customize( 'background_color', function( value ) { value.bind( function( newval ) { $('body').css('background-color', newval ); var text_colour = wp.customize( 'header_textcolor' )(); // ... now do something ...


3

Step 1: Register the setting in the customizer Add this to your wptuts_theme_customizer() function, which will register a new "Pagination" section, as well as a "Pagination Style" setting: /* Section: Pagination */ $wp_customize->add_section( 'themeslug_pagination', array( 'title' => __( 'Pagination', 'themeslug' ), ) ); ...


3

Check for global variable $wp_customize: if ( empty ( $GLOBALS['wp_customize'] ) ) { // show something } Update: in WordPress 4.0, you can use is_customize_preview().


3

Ok, here's how to do this. Seperate your control class(es) to one or more new files. You have a function or method hooked on customize_register, right? In that function or method require once your new files just before adding your custom controls. Then PHP won't complain about redefining classes. Note: This will not work out of the box, but shows the ...


3

As in this question: How to execute conditional script when on new customize.php (Theme Customize) screen global $wp_customize; if ( isset( $wp_customize ) ) { // do stuff }


3

You're never using your class. Try passing a new instance of your class to the add_control method: $control_args = array( // your args here ); $my_control = new WP_Customize_Palette_Control( $wp_customize, 'themename_color_scheme', $control_args); $wp_customize->add_control($my_control); Also, I don't think WP knows that the option ...


3

I found out the WP_Customize_Manager class has a function called remove_section(). In your function hooked to customize_register you can just do: $wp_customize->remove_section('nav'); $wp_customize->remove_section('static_front_page'); You can find the ID of the section (i.e. 'nav') if you inspect the accordion title bar of the section. Look ...


2

Accoring to OTTO One final thing you can add to a section is a “theme_supports” option. This will make the menu not appear unless the theme supports something. If you’re putting this code in a theme itself, then you already know what the theme supports, so it doesn’t make much sense. The core uses this to not show the header and background ...


2

If your settings are stored as Theme Mods, rather than as a Settings API option, then you need to pass the appropriate value to the type parameter to $wp_customize->add_setting(): 'option': Settings API option (get_option()) 'theme_mod': Theme Mods API option (get_theme_mod()) Try changing this: $wp_customize->add_setting( $this_theme . ...


2

The color picker thing is registered as a jQuery UI widget, so you could modify its prototype object before the widget is used in the page: add_action('customize_controls_print_footer_scripts', function(){ ?> <script> jQuery(document).ready(function($){ $.wp.wpColorPicker.prototype.options = { border: false, // ...


2

Thanks to @chip_bennett to point it out! I registered the settings using settings api and I was trying to add the settings on customize api by the type of theme_mod that's why it was showing the error. After changing the 'type' => 'theme_mod' to 'type' => 'option', it worked :)


2

Late to the party but this will do the trick: $wp_customize->remove_control('blogdescription'); You want to remove just that control, not entire section as suggested above.


2

Couple points: The customize_register action hook actually passes your function the $wp_customize variable, you don't need to declare it as the global. Just put it as the first argument in your function declaration. The reason your code doesn't run on the front end of the site is that the customize_register action hook only runs when the customizer is ...


2

Got it! Here's the code that worked for me. -- Theme Customizer settings and controls (mine are in a separate customizer.php file): function themename_customize_register( $wp_customize ) { ... $wpcustomize->add_setting( 'themename_skin', array( 'default' => 'light', ), ); $wp_customize->add_control( ...


2

My answer might come a bit late for you, but as I had the same problem today, here's what I found out: 1) First of all, if you set 'type' => 'option' for your custom settings, you should use the get_option() function to retrieve the values. If you set 'type' => 'theme_mod' (or don't set a type at all as it defaults to theme_mod), you can retrieve the ...


2

It appears that 'customize_controls_enqueue_scripts' also works and may be the intended function. function theme_customize_style() { wp_enqueue_style('customize-styles', get_template_directory_uri() . '/customize.css'); } add_action( 'customize_controls_enqueue_scripts', 'theme_customize_style' );


2

If you need a specific ordering of the input fields, then add "priority" values to the controls in the add_control calls, same as you already have for the sections. If you don't have a priority, then no particular order is guaranteed and you get whatever PHP happens to order your arrays as.



Only top voted, non community-wiki answers of a minimum length are eligible