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


5

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.


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

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


3

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


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

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

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

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


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

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

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

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

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

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

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


1

My guess is that you have not defined a page.php template in your theme, so pages are being displayed using index.php which includes a sidebar with widgets and comment form. Edit: Looking at the code in your updated question, you can remove the following: // If comments are open or we have at least one comment, load up the comment template. if ...


1

In the link all the content such as calendar, categories, archive, etc. are coming from the sidebar widget which most probabily defined into your page.php layout. something like: <?php get_sidebar( 'content' ); ?> You need to remove this kind of sidebar code from the page.php file to not display that information.



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