2

I'm trying hook the customizer_preview_init action in order to trigger live preview of the changes I'm making in the customizer. However, my first test is failing. I'm just trying to get an alert to fire inside the .js

Any ideas what I'm doing wrong?

//Add customizer.php to admin:
if ( is_admin() ) :
require_once( GENESIS_ADMIN_DIR . '/customizer.php' );

customizer.php:

function mytheme_customizer_live_preview()
{
    wp_enqueue_script(
            'mytheme-themecustomizer',  //Give the script an ID
            get_template_directory_uri().'/framework/admin/customizer.js',//Point to file
            array( 'customize-preview' ),   //Define dependencies
            '', //Define a version (optional)
            true //Put script in footer?
    );
}
add_action( 'customize_preview_init', 'mytheme_customizer_live_preview' );

customizer.js

alert('customizer.js loaded!'); 

( function( $ ) {

    alert('Customizer!');
    //Do Stuff

} )( jQuery );

Update: It appears that my enqueue is failing. The customizer.js file is nowhere to be found in the dev tools resource panel.

I've verified that the footer.php does in fact have a wp_footer() call as expected. This is Genesis theme, perhaps some filter affecting the enqueue?

  • Why didn't you simply update/edit your other question? – kaiser Mar 19 '14 at 23:49
  • It was too convoluted. I rewrote it to get to the essence of the problem I'm having. – N2Mystic Mar 19 '14 at 23:51
  • Why don’t you use customize_controls_enqueue_scripts to enqueue scripts for customize controls? – fuxia Mar 20 '14 at 0:20
  • @toscho I guess because it's not explained on the relate Codex entry. I searched for it too and couldn't find it. – kaiser Mar 20 '14 at 0:21
  • 1
    @kaiser You should really memorize my posts better. I’m disappointed. – fuxia Mar 20 '14 at 0:22
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.

1

I wrote a quick plugin to reproduce your problem with a nearly vanilla multisite/network install, running the plugin on a sub site with the TwentyForteen theme. It consists out of two files, both residing in the same directory: plugin.php and theme-customizer.js:

Main plugin file:

<?php

namespace WPSE;

/** Plugin Name: (#138550) Theme Customizer Register Script */

# add_action( 'customize_preview_init', 'WPSE\registerScript' );
add_action( 'customize_controls_enqueue_scripts', 'WPSE\registerScript' );
function registerScript()
{
    wp_enqueue_script(
        'wpse-theme-customizer',
        plugin_dir_url( __FILE__ ).'theme-customizer.js',
        array(
                'jquery',
                'customize-preview',
            ),
        filemtime( plugin_dir_path( __FILE__ ).'theme-customizer.js' ),
        TRUE
    );
}

JavaScript test file:

/*globals jQuery */
( function( $ ) {
    "use strict";

    alert( 'Here we go!' );
} )( jQuery );

Above works like a charm :)

Hint: You can use plugin_dir_path() in themes as well.

EDIT

After @toscho comment above and his link to his answer here, I decided to test one vs. the other hook. And surprise!!1! not, customize_controls_enqueue_scripts shoots earlier and from a look up in core seems to be much more reliable due to the fact that it's not hidden in a massive Singleton/Poor-Mans-Namespace in some random method.

Conclusion: Go with customize_controls_enqueue_scripts and forget about customize_preview_init. The former btw runs exactly after customize_controls_init callbacks were triggered, so there's less chance for interference of other code.

  • 1
    Although I do now get the alert, the scope of the jquery DOM appears to point to the parent document that holds the iframe, not the iframe document itself. Therefore, I cannot get a reference to the theme document to apply live CSS changes. In your theme-customizer.js, are you able to get $('body').attr('class') to reflect your document's body class? – N2Mystic Mar 20 '14 at 4:45
  • @N2Mystic Now it's time to undelete your other question and rework it. Or just ask a new one :) – kaiser Mar 20 '14 at 10:36
  • 2
    No problem. However, just want to clarify. Is customize_controls_enqueue_scripts bound to the customizer forms DOM or iframe preview window DOM? If the latter, we are good. If the former, I believe we need to make that distinction in your answer (and codex - more importantly). – N2Mystic Mar 20 '14 at 13:06
  • Here's the followup: wordpress.stackexchange.com/questions/138630/… – N2Mystic Mar 20 '14 at 14:16
  • 4
    The customize_preview_init action is the correct one for loading JS code into the preview frame for receiving postMessage events. The customize_controls_enqueue_scripts action would be used for JS code that goes into the control frame, for changing how the controls work. Different use cases for them both. – Otto Mar 20 '14 at 16:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.