The new “Customize” theme screen is a welcome addition in WordPress 3.4, however, I find it conflicts with my method of loading scripts loaded in the footer:
In functions.php
if(!is_admin())
{
/* GET PUBLIC FUNCTIONS
*************************************************************/
require_once(TEMPLATEPATH . '/functions_public.php');
}
In functions_public.php
/* Move scripts to the footer, speeding up page loading time as per http://yhoo.it/IAL94Z
*************************************************************************/
if ( isset($_GET['page']) && $_GET['page'] == 'customize.php') echo "in customize.php"; else echo "NOT in customize.php";
if(!get_option('my_scripts_head')){
remove_action('wp_head', 'wp_print_scripts');
remove_action('wp_head', 'wp_print_head_scripts', 9);
remove_action('wp_head', 'wp_enqueue_scripts', 1);
add_action('wp_footer', 'wp_print_scripts', 5);
add_action('wp_footer', 'wp_enqueue_scripts', 5);
add_action('wp_footer', 'wp_print_head_scripts', 5);
}
This code branch moves those scripts from wp_head to wp_footer. When this option (my_scripts_head) is enabled, the “Customize” screen shows my theme preview without the scripts that are loaded in the footer.
I find that when I disable this option, the “Customize” screen loads fine, including my scripts.
When themes are previewed in customize.php, does wp_footer not fire?
Okay, first, let’s set things up properly, with a callback hooked into an appropriate action hook:
We’ll put all of our code in to this callback.
The next step is to add our
if ( ! is_admin() )
conditional wrapper:Now, let’s add in your original code:
So, at this point, we should be back to where you were before. Now, let’s account for the Customizer. The easiest way is to check for the
$wp_customize
global being set:By the way: out of curiosity, why are you moving all of the script enqueueing to the footer? I would imagine that has a very high likelihood of breaking things, and/or causing unintended consequences.