In child theme I created a functions.php file that loads scripts and style files, the code is below. The section that loads libraries and scripts to all pages other than admin, in other words the first two functions, works as expected. However, the third function, which is designed to load a script for a specific page does not load. It appears that my problem has to do with specifying the page condition. The rest of the code for register and enqueue works if it is placed in the general function that loads scripts for any page other than admin pages. I've researched this can can't find any examples showing why the approach I've used is not working. I've swapped the page id with the name of the page but to no avail.

Any suggestion on the source of the problem would be much appreciated.



function scripts () {
    if ( !is_admin() ) { 
        wp_register_script('jqueryUI', "path", array('jquery')); //register custom UI library
        wp_register_script('popUp1', ("path"), array('jquery', 'jqueryUI'));
        wp_register_script('popUpText', 'path', array('jquery', 'jqueryUI'));

add_action('init', 'scripts');

//INSERT CSS    files into the header
function styles () {
    if ( !is_admin() ) {
        wp_register_style('jqueryUIcss', "path");
        wp_register_style('valuecss', "path");
    add_action('init', 'styles');

//Add scripts for pop ups on "how to estimate value" page
function pagePopUps1 () {
    if ( is_page(16)) { 
        wp_register_script('popUpVideo1', "path", array('jquery', 'jqueryUI'));


add_action('init', 'pagePopUps1');  

//End of file

Note for the sake of brevity I removed the src's but these have been validated and are not the source of the problem.


2 Answers 2


I'd suggest moving the script registering into the init action, and moving the enqueue(s) into a callback hooked onto wp_print_scripts.


add_action( 'init', 'register_those_scriptsNstyles' );

function register_those_scriptsNstyles() {
    wp_register_script( .. your script params .. );
    wp_register_style( .. your style params ..  );


add_action( 'wp_print_scripts', 'enqueue_those_scriptsNstyles' );

function enqueue_those_scriptsNstyles() {

    if( !is_page( 'some-page' ) ) // If it's not the given page, stop here

    wp_enqueue_script( .. your script params .. );
    wp_enqueue_style( .. your style params .. );


NOTE: Despite the hook name, i'm pretty sure wp_print_scripts should also be fine for enqueuing styles to. The important factor is to just ensure the hook you use occurs late enough for the conditional template tags to be set, ie. is_page, is_category and so on..
If not, try wp_head instead.. eg. add_action( 'wp_head', 'your-callback' )

EDIT: For styles, just like the admin side, the public facing side has an action for styles to.. which is wp_print_styles..(hook enqueues for styles to there).

Hope that helps..

  • In some cases wp_print_scripts might be too late for enqueues (without playing with priorities), because it has some script localization stuff hooked to it. Codex strongly recommends running enqueues on init only. Also conditional tags are documented as available at init, it shouldn't be an issue.
    – Rarst
    Feb 1, 2011 at 11:18
  • Rarst would you mind linking to the specific page(s) or sources please so i can have a read of the information?
    – t31os
    Feb 1, 2011 at 11:24
  • @t31os see wp_enqueue_script() in Codex and wp_just_in_time_script_localization() that is hooked to wp_print_scripts. I am not sure it will break something, but Codex recommends init and I think it makes sense to stick with that for consistency.
    – Rarst
    Feb 1, 2011 at 12:06
  • I'm not convinced there's a valid argument to not hook onto wp_print_scripts when used correctly. Have you looked at what wp_just_in_time_script_localization actually does, it's a callback that localizes the autosave.js script? If concern is with hooking onto it to early, then the fix is simple.. add_action( 'wp_print_scripts', 'enqueue_those_scriptsNstyles', 11 );. This hook was designed for enqueues, it's the equivalent of admin_print_scripts, just for the public facing side of the site..
    – t31os
    Feb 1, 2011 at 12:32
  • @t31os This hook was designed for enqueues I am fuzzy on historical reasoning, but I disagree on functional. Printing and enqueueing are distinctly different actions that are often decoupled. I see no particular reason that enqueues should be hooked there, especially when documentation explicitly recommends to use other hook. Overall it's nothing major but as above - I believe sticking with init for this is best practice kind of thing.
    – Rarst
    Feb 1, 2011 at 13:18

The first things to check in such cases:

  • is hooked function firing properly;
  • is condition being evaluated to expected result.

Add var_dump( is_page(16) ); to your function and see if these are working as expected.

  • Thanks for the guidance. This confirmed that the returned result is false.
    – dorich
    Feb 1, 2011 at 19:14
  • @dorich see our huge messy comment discussion on other answer, it seems that (on the contrary to documentation) init hook is too early for is_page() to work.
    – Rarst
    Feb 1, 2011 at 19:20
  • Ah, thanks. I did wonder why the "!is_admin" works with "init" when the page specific won't. I'm naive on the use of php, conditional tags and action hooks so this is a learning experience. Is this just a case of changing the "add action" to a different hook (say wp or wp_head) or is there more to it?
    – dorich
    Feb 1, 2011 at 19:32
  • @dorich yep, move it to another hook, again - see other answer for details
    – Rarst
    Feb 1, 2011 at 19:35
  • Thanks. I tried wp_head to no avail but using wp appears to be loading the script as needed.
    – dorich
    Feb 1, 2011 at 19:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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