When to use add_action(‘init’) vs add_action(‘wp_enqueue_scripts’)

1 Views

In my theme’s functions.php, I’m calling an add_action in order to gain a measure of control on where jquery is loaded (in the footer along with my theme’s other scripts).

The problem I’m having is that when I use add_action(‘wp_enqueue_scripts’), it only appears to fire if no plugins are loaded. However, the add_action(‘init’) method works in all cases.

Read More

I can’t recall why, but I believe that add_action(‘wp_enqueue_scripts’) is preferred in this case. If that’s true, how can I get it to work in all cases?

In functions.php 

//if(!is_admin()){add_action('init', 'my_theme_init');} //THIS WORKS ALL THE TIME
//add_action('wp_enqueue_scripts', 'my_theme_init'); //THIS ONLY WORKS WHEN NO PLUGINS PRESENT

if(!is_admin())
{
    require_once(TEMPLATEPATH . '/functions_public.php');   
}

In functions_public.php 

function my_theme_init()
{

/* PREVENT DUPLICATE COPIES OF JQUERY FROM PLUGINS
**************************************************/
wp_deregister_script('jquery');

/* LOAD THE LOCAL WORDPRESS COPY OF JQUERY AND THEME CUSTOM SCRIPTS IN THE FOOTER
***********************************************/
wp_register_script('jquery', get_bloginfo('template_directory').'/scripts.mythemescripts.js',false,false,true);

wp_enqueue_script('jquery');

}

The 2nd method, using add_action(‘wp_enqueue_scripts’) apparently does not get executed in conditions where a plugin is present that writes out script dependencies to the theme.

Post Views: 1

Related posts

Leave a Reply

3 comments

  1. A lot of plugin developers don’t do things the right way. The right way is to hook on to wp_enqueue_scripts like you’re trying to do.

    However, here’s the order of the hooks run in a typical request:

    • muplugins_loaded
    • registered_taxonomy
    • registered_post_type
    • plugins_loaded
    • sanitize_comment_cookies
    • setup_theme
    • load_textdomain
    • after_setup_theme
    • auth_cookie_malformed
    • auth_cookie_valid
    • set_current_user
    • init
    • widgets_init
    • register_sidebar
    • wp_register_sidebar_widget
    • wp_default_scripts
    • wp_default_stypes
    • admin_bar_init
    • add_admin_bar_menus
    • wp_loaded
    • parse_request
    • send_headers
    • parse_query
    • pre_get_posts
    • posts_selection
    • wp
    • template_redirect
    • get_header
    • wp_head
    • wp_enqueue_scripts
    • wp_print_styles
    • wp_print_scripts
    • … a lot more

    The thing is, several developers were originally told to hook on to init for enqueue-ing their scripts. Back before we had a wp_enqueue_script hook, that was the “correct” way to do things, and tutorials perpetuating the practice are still floating around on the Internet corrupting otherwise good developers.

    My recommendation would be to split your function into two parts. Do your wp_deregister_script/wp_register_script on the init hook and use the wp_enqueue_scripts hook when you actually enqueue jQuery.

    This will keep you in the world of “doing it right” for enqueue-ing your scripts, and will help protect you from the hundreds of developers still “doing it wrong” by swapping jQuery for your concatenated version before they add it to the queue.

    You’ll also want to add your init hook with a high priority:

    add_action( 'init', 'swap_out_jquery', 1 );
function swap_out_jquery() {
    // ...
}

  2. There are multiple issues here, that are inter-related.

    1. The correct action hook to use to enqueue scripts is wp_enqueue_scripts
    2. To print scripts in the footer via wp_enqueue_script(), set the $footer parameter to true
    3. Your add_action( $hook, $callback ) calls should not be wrapped in anything; let them execute directly from functions.php
    4. You should put your is_admin() conditional checks inside your callback
    5. You shouldn’t deregister core-bundled scripts from a Theme, for any reason. Even if your purpose is script concatenation, that’s Plugin territory.
    6. If you must deregister jquery, then wp_enqueue_scripts is too late. Split your deregister/register code into a callback hooked into init.
    7. Calling some other script “jquery” is also probably not a good practice. Your better bet would simply be to dequeue jQuery, and then load your custom script.
    8. Be sure to put a low priority on your callback, so you override Plugins
    9. Use get_template_directory() rather than TEMPLATEPATH

    Putting it all together:

    <?php
function wpse55924_enqueue_scripts() {
    if ( ! is_admin() ) {

        // Dequeue jQuery
        wp_dequeue_script( 'jquery' );

        // Register/enqueue a custom script, that includes jQuery
        wp_register_script( 'mythemescripts', get_template_directory_uri() . '/scripts.mythemescripts.js', false, false,true );
        wp_enqueue_script( 'mythemescripts' ); 
    }
}
add_action( 'wp_enqueue_scripts', 'wpse55924_enqueue_scripts', 99 );

    But again: this is really not the best approach. Your better bet is simply to remove plugin add_action() callbacks that deregister core jQuery – or use Plugins that don’t do something so reckless as replacing core-bundled jQuery.

  3. This answer is not for your question exactly but there is one other issue in your code.

    You never need to use and should not use:

    wp_enqueue_script('jquery');

    If you want to use the jquery provided by WordPress then the best way to do is, when you enqueue your own javascript file, pass jquery as a dependency, this way, it will be handled by WordPress itself and you don’t need to enqueue it manually.

    Example:

    wp_enqueue_script( 'myjslib-handle', get_stylesheet_directory_uri() . '/js/myfile.js', array('jquery'), '1.0.0', true );

    array(‘jquery’) in the above code is the parameter we need to load jquery as a dependency.