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 ...


9

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.


6

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 ...


5

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 ...


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

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 ...


4

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

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

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.


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 ...


3

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' );


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' ), ) ); ...


2

@s_ha_dum is right, the ajax plugin api is the way to go. I ran into this issue myself with a dynamic js file I was generating a little while ago. Basically you would enqueue your style as follows: wp_enqueue_style('dynamic-css', admin_url('admin-ajax.php').'?action=dynamic_css', $deps, $ver, $media); ...


2

AFAIK it shouldn't be a problem to get taxonomy data at the customizer_register hook state. So that problem might have different reasons, but they aren't apparent from your question. Besides I'm not sure what you are trying to achieve, so you might want to fill the information gaps according to @Rarst's questions. Aside from that there are multiple methods ...


2

The issue in this case has to do with how I added the customize.php script. I was loading it inside an is_admin() check (see updated question above where I have included that code branch). After reading Otto's post, I realized that the customizer hook does not fire in this context.


2

Use default values when you fetch the settings. Never store defaults in the database. Example: $defaults = array ( 'foo' => 'bar' ); $options = get_option( 'my_theme_options', $defaults ); echo $options['foo'];


2

Sadly not - all your customize controls are hooked onto customize_register, so they'll only ever come into play when customising the theme for the first time. get_theme_mod() takes a second argument for a "default" value - yes, it means two instances of data in your code, but it's a half-solution. I guess a more DRY approach would be a coupling of globals ...


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.


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( ...



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