I'm loading some JavaScript files in the parent theme. The path in the parent theme is:

scripts > custom.js

In the child theme, I'm creating the same path (scripts > custom.js) and changing some of the jQuery inside the custom.js file.

The problem is that the changes are not being applied. Is this the wrong way to make changes to these files in the child theme?

  • 1
    What is the parent Theme? How are the scripts being called by the parent Theme? – Chip Bennett Aug 24 '11 at 22:17
up vote 42 down vote accepted

Child themes only override php files (like header.php) that are included with functions like get_template_part or get_header, etc.

The correct way to add scripts to WordPress is with wp_enqueue_script. If your parent theme uses this, you can override the JS files by using wp_dequeue_script and enqueuing your own.

Like so...

<?php
// hook in late to make sure the parent theme's registration 
// has fired so you can undo it. Otherwise the parent will simply
// enqueue its script anyway.
add_action('wp_enqueue_scripts', 'wpse26822_script_fix', 100);
function wpse26822_script_fix()
{
    wp_dequeue_script('parent_theme_script_handle');
    wp_enqueue_script('child_theme_script_handle', get_stylesheet_directory_uri().'/scripts/yourjs.js', array('jquery'));
}

If the parent theme isn't using wp_enqueue_script, it's probably hooking into wp_head (or wp_footer) to echo out the scripts there. So you'd use remove_action to get rid of those functions echoing the scripts out, and then enqueue your own script.

If the script is hard coded into the template file, you'll just need to replace that template file in your child theme without the script tag.

If they used wp_enqueue_script calls that utilize get_stylesheet_directory_uri, then you shouldn't have to do anything. Since this isn't happening, you'll just have to poke around and see what the theme author did.

  • 2
    if the parent theme uses get_stylesheet_directory_uri to enqueue scripts, then the child theme will have to duplicate all scripts thus enqueued, because otherwise they woun't be found. There is no fallback mechanism in get_stylesheet_directory_uri to check if an individual file exists in the child theme and fall back to the parent theme's file if necessary. – user18579 Jul 26 '12 at 13:20
  • From the Codex: “wp_print_scripts should not be used to enqueue styles or scripts on the front page. Use wp_enqueue_scripts instead. ” codex.wordpress.org/Plugin_API/Action_Reference/… – Christian Lescuyer Aug 13 '13 at 14:53
  • Keep in mind when this was written: two years ago. Before wp_enqueue_scripts could be used to only enqueue scripts on the front end. Updated. If you see something out of date, feel free to edit. – chrisguitarguy Aug 13 '13 at 15:02
  • 3
    Please note that you may have to set a late priority (for instance 100) to make sure your dequeue happens after the parent theme enqueue. add_action( 'wp_enqueue_scripts', 'wpse26822_script_fix', 100 ); from codex.wordpress.org/Function_Reference/wp_dequeue_script – Spone Sep 4 '14 at 5:18
  • 4
    Update for 2016: according to stackoverflow.com/questions/23507179/… we also have to use wp_deregister_script('parent-script-handle'); to completely remove the parent script. Indeed, it didn't work for me without it. WP 4.6.1 – PhiLho Nov 30 '16 at 9:58

In some cases it is important to prioritize both the add_action and the wp_enqueue_script function calls like so:

add_action('wp_enqueue_scripts', 'wpse26822_script_fix', 20120207);
function wpse26822_script_fix()
{
    wp_dequeue_script('storefront-navigation');
    wp_enqueue_script('my_storefront-navigation', get_stylesheet_directory_uri().'/js/navigation.min.js', array('jquery'),20151110,true);
}

In this case, wp_enqueue_scripts was called by the parent with a priority of 20120206 (the date) and so this action is added with a priority just barely greater so that it will immediately be dequeued. Then, the enqueue statement that follows that follows is actually prioritized after that to ensure that it loads after the old one was dequeued. The true, in this case is also important because that specifies that it is to be enqueued in the footer, which is where the parent script was first enqueued.

Also, I can't quite explain it entirely, but I notice that if you are careful with dequeuing the initial script immediately after it being enqueued, it seems you can effectively prevent it from loading in the first place.

  • 1
    The function wp_enqueue_script doesn't have a priority parameter, it's only a version number which is concatenated to the end of the path as a query string. This parameter is used to ensure that the correct version is sent to the client regardless of caching [...] – Emile Bergeron Jan 18 '16 at 14:51

call wp_deregister_script before register your own version

  • Why? This is only needed when you are using the same handle – something you don't have to do. You probably even shouldn't, because it is easier to debug code whose source is clear. – fuxia Dec 25 '16 at 18:14

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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