Full URL of the script, or path of the script relative to the WordPress root directory.
Default empty.
$depsstring[]optional
An array of registered script handles this script depends on.
Default:array()
$verstring|bool|nulloptional
String specifying script version number, if it has one, which is added to the URL as a query string for cache busting purposes. If version is set to false, a version number is automatically added equal to current installed WordPress version.
If set to null, no version is added.
Default:false
$argsarray|booloptional
An array of additional script loading strategies.
Otherwise, it may be a boolean in which case it determines whether the script is printed in the footer. Default false.
strategystring
Optional. If provided, may be either 'defer' or 'async'.
in_footerbool
Optional. Whether to print the script in the footer. Default 'false'.
fetchprioritystring
Optional. The fetch priority for the script. Default 'auto'.
Links a script file to the generated page at the right time according to the script dependencies, if the script has not been already included and if all the dependencies have been registered. You could either link a script with a handle previously registered using the wp_register_script() function, or provide this function with all the parameters necessary to link a script.
This is the recommended method of linking JavaScript to a WordPress generated page.
As of WordPress 6.3, the new $args parameter – that replaces/overloads the prior $in_footer parameter – can be used to specify a script loading strategy. See the sections to follow for more information.
Supported strategies are as follows:
defer
Added by specifying an array key value pair of 'strategy' => 'defer' to the $args parameter.
Scripts marked for deferred execution — via the defer script attribute — are only executed once the DOM tree has fully loaded (but before the DOMContentLoaded and window load events). Deferred scripts are executed in the same order they were printed/added in the DOM, unlike asynchronous scripts.
async
Added by specifying an array key value pair of 'strategy' => 'async' to the $args parameter.
Scripts marked for asynchronous execution — via the async script attribute — are executed as soon as they are loaded by the browser. Asynchronous scripts do not have a guaranteed execution order, as script B (although added to the DOM after script A) may execute first given that it may complete loading prior to script A. Such scripts may execute either before the DOM has been fully constructed or after the DOMContentLoaded event.
Following is an example of specifying a loading strategy during script enqueuing:
When applying a loading strategy via either the wp_register_script() and wp_enqueue_script() functions, the scripts dependency tree is taken into consideration and the most eligible loading strategy is applied.
While the intended (delayed) strategy passed by the code author may not be the final one, it will never be a stricter one, thus maintaining the integrity of the dependency tree.
The function should be called using the wp_enqueue_scripts action hook if you want to call it on the front-end of the site, like in the examples above. To call it on the administration screens, use the admin_enqueue_scripts action hook. For the login screen, use the login_enqueue_scripts action hook. Calling it outside of an action hook can lead to problems, see the ticket #11526 for details.
If you try to register or enqueue an already registered handle with different parameters, the new parameters will be ignored. Instead, use wp_deregister_script() and register the script again with the new parameters.
jQuery UI Effects is not included with the jquery-ui-core handle.
This function relies on the use of wp_head() and wp_footer() by the active theme. This means that it may not work with a few very old themes that do not call these functions. This is useful to keep in mind when debugging ancient themes.
By default, WordPress installation includes many popular javascript libraries and scripts commonly used by web developers besides the scripts used by WordPress itself. Some of them are listed in the table below.
For a detailed list of names that can be used in place of the $handle parameter, see wp_register_script().
The list is far from complete. For a complete list of registered files inspect $GLOBALS['wp_scripts'] in the admin UI. Registered scripts might change per requested page.
When you enqueue script that is dependent on jQuery, note that the jQuery in WordPress runs in noConflict mode, which means you cannot use the common $ alias. You must use the full jQuery instead. Alternately, place your code using the $ shortcut inside a noConflict wrapper.
jQuery( document ).ready( function( $ ) {
// $() will work as an alias for jQuery() inside of this function
[ your code goes here ]
} );
JavaScript files included in themes often require another JavaScript file to be loaded in advance to use its functions or variables. Using the $deps parameter, the wp_enqueue_script() and wp_register_script() functions allows you to mark dependencies when registering a new script. This will cause WordPress to automatically link these dependencies to the HTML page before the new script is linked. If the handles of these dependencies are not registered, WordPress will not link the new script. This example requires the jQuery library for the custom_script.js theme script:
/**
* Enqueue a script with jQuery as a dependency.
*/functionwpdocs_scripts_method(){
wp_enqueue_script( 'custom-script', get_stylesheet_directory_uri() . '/js/custom_script.js', array( 'jquery' ) );
}
add_action( 'wp_enqueue_scripts', 'wpdocs_scripts_method' );
The following is an example of basic usage which links the script.aculo.us library already included and registered by WordPress with the scriptaculous handle.
/**
* Enqueue script.aculo.us.
*
* Tha callback is hooked to 'wp_enqueue_script' to ensure the script is only enqueued on the front-end.
*/functionmy_scripts_method(){
wp_enqueue_script( 'scriptaculous' );
}
add_action( 'wp_enqueue_scripts', 'my_scripts_method' );
The above example links the script.aculo.us library only on the front-end. If the library was needed within the administration screens, you could use the admin_enqueue_scripts action hook instead, however, this would enqueue it on all the administration screens, which often leads to plugin/core conflicts, ultimately breaking the WordPress administration screens experience. Instead, you should only link it on the individual screens you need it, see the Link Scripts Only on a Plugin Administration Screen section for an example of that.
after the hook “wp_enqueue_scripts” and before the footer, eg when rendering shortcodes or rendering a post’s body.
Enqueueing stylesheets (css) in this same method has some issues though.
Scribu gave an example of a shortcode enqueueing a script here: http://scribu.net/wordpress/conditional-script-loading-revisited.html
An example of how to enqueue multiple styles and scripts which include the SRI (sub-resource integrity) tag. This is loosely based on this article, but I’ve tried to simplify the code somewhat, particularly given I may want to include and manage many scripts/styles.
The important thing to note, is the handle specified when enqueuing a style/script, needs to match the handle referenced in the my_add_sri function. Also note, aside from the obvious SRI tag difference, the str_replace method used on scripts in the my_add_sri function, is different to that used on styles.
As I was trying to use the ‘new’ recommended CDN for Bootstrap 4.5.X (jsDelivr) and stumbled upon how exactly to figure out how to add the SRI tag, I can only commend your solution and the simplification you did to the original code. Thank you!
This is not documented, but calling this function with $in_footer being `false` actually registers the script in general as a dependency that should be resolved and output, not just for header. Then, when outputting scripts enqueued for the footer, only the scripts that have not been included yet will be output. This leads to behaviour where a script that is enqueued supposedly in the header will appear in the footer if enqueued after the header has already been process. Therefore, $in_footer should actually read and be understood as $in_footer_only.
Because this and wp_enqueue_style usesWP_Scripts::enqueue(), which can take an array of handles as it’s first argument, you can also pass an array of handles into wp_enqueue_script/style:
This example is using the new technique of defer or async a script. Also one good practice for versioning of the file is to use the filemtime php native function in order to pass the last modified time of the file as a parameter to the cache.
In some cases, you might want to add scripts as a module. In that case type="module" needs to be added to the tag. This can be done using the script_loader_tag filter hook.
Modules are a newer feature of JS introduced in ES6 and has many advantages over conventional JS files especially if you are working on a large project. You can read about modules in official documentation.
Since WordPress 6.5, the best way to enqueue script modules is through the wp_enqueue_script_module() function. No tag filtering needed! Do note that wp_enqueue_script_module() requires a slightly different dependency array structure, so it’s not merely a rename-and-done operation.
wp_register_script()::
Registers a script with WordPress.
Does not load the script on the page.
Useful when you want to define a script for later use with specific conditions or dependencies.
Takes arguments like script handle (unique identifier), script path (URL or relative path to the file), and optional arguments like version number and dependencies on other scripts.
wp_enqueue_script()::
Enqueues a script that need to be loaded on the page.
Can also register the script if it hasn’t been registered before.
Useful for including scripts you need on a specific page or based on certain conditions (e.g., only on the front-end).
Takes arguments like script handle (same as used with wp_register_script) and optional arguments like version number, dependencies, and placement (in the header or footer).
Here’s a key difference:
wp_enqueue_script can handle both registering and loading a script in one call.
wp_register_script only registers the script for later use with wp_enqueue_script or another function that might need it.
wp_localize_script()::
Does not register or enqueue a script.
Used to localize a registered script, meaning it injects PHP variables into the script as JavaScript objects.
Useful for passing data from WordPress (PHP) to your JavaScript code.
Takes arguments like script handle (of an already registered script), a variable name to hold the data in JavaScript, and the actual PHP data (array or object) you want to pass.
In short,
Use wp_register_script to define scripts for later use.
Use wp_enqueue_script to load scripts on the page (can also register if needed).
Use wp_localize_script to pass data from PHP to your registered JavaScript code.
This documentation should really do a better job defining what a “script” is… Because: is this function meant for enqueueing a .php or html script? No!
That may seem obvious to a lot of developers, but if you are looking at this documentation, you should be getting some clarity as to what this function should be used for, so I’m writing this to help.
Apparently, in this case, the term “script” is being used as a program that is not being evaluated by the server, but rather a program that needs to be passed to the client (and evaluated by the browser). Thus in this case, a PHP file that is expected to be evaluated by the server would not be considered a script (even though a lot of people might call it one) and thus it should not be included with wp_enqueue_script() , but included using require_once() or possibly include_once() instead.
Link a Plugin Script That Depends on script.aculo.us
This example is intended to be used within a plugin file to register and link a new plugin script that depends on the script.aculo.us library. See the example above for information about dependencies.
/**
* Enqueue script with script.aculo.us as a dependency.
*/functionmy_scripts_method(){
wp_enqueue_script( 'newscript', plugins_url( '/js/newscript.js' , __FILE__ ), array( 'scriptaculous' ) );
}
add_action( 'wp_enqueue_scripts', 'my_scripts_method' );
Link Scripts Only on a Plugin Administration Screen
This example links a script only on a specific administration screen, as opposed to the scenario described in the paragraph below the code of the first example.
<?php/**
* Register the plugin script.
*/functionwpdocs_plugin_admin_init(){
// Register our script.
wp_register_script( 'my-plugin-script', plugins_url( '/script.js', __FILE__ ) );
}
add_action( 'admin_init', 'wpdocs_plugin_admin_init' );
/**
* Add Administration screen for the plugin.
*/functionwpdocs_plugin_admin_menu(){
/* Add our plugin submenu and administration screen */
$page_hook_suffix = add_submenu_page( 'edit.php', // The parent page of this submenu.
__( 'My Plugin', 'my-textdomain' ), // The submenu title.
__( 'My Plugin', 'my-textdomain' ), // The screen title.'manage_options', // The capability required for access to this submenu.'my_plugin-options', // The slug to use in the URL of the screen.'wpdocs_plugin_manage_menu'// The function to call to display the screen.
);
/*
* Use the retrieved $page_hook_suffix to hook the function that links our script.
* This hook invokes the function only on our plugin administration screen,
* see: <a href="https://developer.wordpress.org/reference/hooks/admin_print_scripts-hook_suffix/" rel="ugc">https://developer.wordpress.org/reference/hooks/admin_print_scripts-hook_suffix/</a>
*/
add_action( "admin_print_scripts-{$page_hook_suffix}", 'wpdocs_plugin_admin_scripts');
}
add_action( 'admin_menu', 'wpdocs_plugin_admin_menu' );
/**
* Enqueue registered script in the admin.
*/functionwpdocs_plugin_admin_scripts(){
// Link our already registered script to a page.
wp_enqueue_script( 'my-plugin-script' );
}
/**
* Display callback for the plugin Administration screen.
*/functionwpdocs_plugin_manage_menu(){
// Display our administration screen.
}
When enqueuing a custom script file that you later want to add some inline JS to using wp_add_inline_script() . It’s always best that you have the custom script enqueuing in the footer by setting the last parameter in the function to true
The list of libraries seems to be incomplete. For example `lodash`, `react` exists in WordPress vendor scripts but not list in this page, and there are more.
The $deps parameter may also be null, you don’t have to pass an empty array. See the _WP_Dependency class constructor in wp-includes/class-wp-dependency.php
The action hook used for loading scripts (wp_enqueue_scripts) is called in the head section of the document, so in order for the script to be loaded on the page, you MUST include the following on your page template:
get_header();
This comment on the action hook stating you must include:
get_header();
This is inaccurate. This code fetches the header.php file. What must actually be included in the template is:
wp_head();
The confusion here is that most header files contain the wp_head(); hook.
var wporgFunctionReferenceI18n = {“copy”:”Copy”,”copied”:”Code copied”,”expand”:”Expand code”,”collapse”:”Collapse code”,”sourceFile”:”wp-includes/functions.wp-scripts.php”};
//# sourceURL=wporg-developer-function-reference-js-extra
var quicktagsL10n = {“closeAllOpenTags”:”Close all open tags”,”closeTags”:”close tags”,”enterURL”:”Enter the URL”,”enterImageURL”:”Enter the URL of the image”,”enterImageDescription”:”Enter a description of the image”,”textdirection”:”text direction”,”toggleTextdirection”:”Toggle Editor Text Direction”,”dfw”:”Distraction-free writing mode”,”strong”:”Bold”,”strongClose”:”Close bold tag”,”em”:”Italic”,”emClose”:”Close italic tag”,”link”:”Insert link”,”blockquote”:”Blockquote”,”blockquoteClose”:”Close blockquote tag”,”del”:”Deleted text (strikethrough)”,”delClose”:”Close deleted text tag”,”ins”:”Inserted text”,”insClose”:”Close inserted text tag”,”image”:”Insert image”,”ul”:”Bulleted list”,”ulClose”:”Close bulleted list tag”,”ol”:”Numbered list”,”olClose”:”Close numbered list tag”,”li”:”List item”,”liClose”:”Close list item tag”,”code”:”Code”,”codeClose”:”Close code tag”,”more”:”Insert Read More tag”};
//# sourceURL=quicktags-js-extra
var wporg_note_preview = {“ajaxurl”:”https://developer.wordpress.org/wp-admin/admin-ajax.php”,”nonce”:”4f43700f72″,”preview”:”preview note”,”preview_empty”:”Nothing to preview”,”is_admin”:””};
//# sourceURL=wporg-developer-preview-js-extra
Skip to note 30 content
Andrija Naglic
Never worry about cache again!
This is a little trick I’ve picked up along the way.
The version of the .js and .css files is made from the time of it’s last update.
/** * Never worry about cache again! */ function my_load_scripts($hook) { // create my own version codes $my_js_ver = date("ymd-Gis", filemtime( plugin_dir_path( __FILE__ ) . 'js/custom.js' )); $my_css_ver = date("ymd-Gis", filemtime( plugin_dir_path( __FILE__ ) . 'style.css' )); // wp_enqueue_script( 'custom_js', plugins_url( 'js/custom.js', __FILE__ ), array(), $my_js_ver ); wp_register_style( 'my_css', plugins_url( 'style.css', __FILE__ ), false, $my_css_ver ); wp_enqueue_style ( 'my_css' ); } add_action('wp_enqueue_scripts', 'my_load_scripts');That way, you will always use the cached versions, except in case the files were changed in the meanwhile, which is the most optimum scenario.
Skip to note 31 content
bcworkz
When you enqueue script that is dependent on jQuery, note that the jQuery in WordPress runs in noConflict mode, which means you cannot use the common
$alias. You must use the fulljQueryinstead. Alternately, place your code using the$shortcut inside a noConflict wrapper.jQuery( document ).ready( function( $ ) { // $() will work as an alias for jQuery() inside of this function [ your code goes here ] } );Skip to note 32 content
Barbara Ford
Using a Hook
Enqueue both scripts and styles from a single action hook.
/** * Proper way to enqueue scripts and styles. */ function wpdocs_theme_name_scripts() { wp_enqueue_style( 'style-name', get_stylesheet_uri() ); wp_enqueue_script( 'script-name', get_template_directory_uri() . '/js/example.js', array(), '1.0.0', true ); } add_action( 'wp_enqueue_scripts', 'wpdocs_theme_name_scripts' );Skip to note 33 content
Barbara Ford
Link a Theme Script Which Depends on jQuery
JavaScript files included in themes often require another JavaScript file to be loaded in advance to use its functions or variables. Using the $deps parameter, the wp_enqueue_script() and wp_register_script() functions allows you to mark dependencies when registering a new script. This will cause WordPress to automatically link these dependencies to the HTML page before the new script is linked. If the handles of these dependencies are not registered, WordPress will not link the new script. This example requires the jQuery library for the custom_script.js theme script:
/** * Enqueue a script with jQuery as a dependency. */ function wpdocs_scripts_method() { wp_enqueue_script( 'custom-script', get_stylesheet_directory_uri() . '/js/custom_script.js', array( 'jquery' ) ); } add_action( 'wp_enqueue_scripts', 'wpdocs_scripts_method' );Skip to note 34 content
Andrei Surdu
I want to add a note to bcworkz comment. When using jquery, in general, this is how the code in a file should be formatted:
(function( $ ) { "use strict"; // javascript code here. i.e.: $(document).ready( function(){} ); })(jQuery);It’s a common practice that ensures jQuery runs in no conflict mode and in strict mode.
Strict mode helps out in a couple ways:
Skip to note 35 content
Barbara Ford
Link the script.aculo.us Library
The following is an example of basic usage which links the script.aculo.us library already included and registered by WordPress with the scriptaculous handle.
/** * Enqueue script.aculo.us. * * Tha callback is hooked to 'wp_enqueue_script' to ensure the script is only enqueued on the front-end. */ function my_scripts_method() { wp_enqueue_script( 'scriptaculous' ); } add_action( 'wp_enqueue_scripts', 'my_scripts_method' );The above example links the script.aculo.us library only on the front-end. If the library was needed within the administration screens, you could use the admin_enqueue_scripts action hook instead, however, this would enqueue it on all the administration screens, which often leads to plugin/core conflicts, ultimately breaking the WordPress administration screens experience. Instead, you should only link it on the individual screens you need it, see the Link Scripts Only on a Plugin Administration Screen section for an example of that.
Skip to note 36 content
Pratik Shrestha
When registering and enqueueing scripts, you don’t need to call
wp_register_script()andwp_enqueue_script(). Just callwp_enqueue_script().This:
wp_register_script ( 'custom-script', get_template_directory_uri() . '/js/custom-script.js' ); wp_enqueue_script ( 'custom-script' );Should simply be:
wp_enqueue_script ( 'custom-script', get_template_directory_uri() . '/js/custom-script.js' );Only register if you don’t know if you’re going to load it immediately.
Skip to note 37 content
cgastrell
Unmet dependencies will *NOT* be warned
If dependencies (3rd argument) are not met, the script tag is just not printed and no warnings nor errors are shown.
This doesn’t seem like a bug, just expected behavior. A mention about this on the docs would suffice to prevent misunderstandings.
This example will never load
/js/example.js/** * ... enqueue plugin scripts. */ function load_plugin_scripts() { wp_enqueue_script( 'script-name', plugin_dir_url( __FILE__ ) . '/js/example.js', array('not-existant'), '1.0.0', true ); } add_action( 'wp_enqueue_scripts', 'load_plugin_scripts' );Skip to note 38 content
Michael Nelson
Because of the work on https://core.trac.wordpress.org/ticket/9346, it’s actually safe to call
after the hook “wp_enqueue_scripts” and before the footer, eg when rendering shortcodes or rendering a post’s body.
Enqueueing stylesheets (css) in this same method has some issues though.
Scribu gave an example of a shortcode enqueueing a script here: http://scribu.net/wordpress/conditional-script-loading-revisited.html
Skip to note 39 content
Bink
An example of how to enqueue multiple styles and scripts which include the SRI (sub-resource integrity) tag. This is loosely based on this article, but I’ve tried to simplify the code somewhat, particularly given I may want to include and manage many scripts/styles.
The important thing to note, is the handle specified when enqueuing a style/script, needs to match the handle referenced in the
my_add_srifunction. Also note, aside from the obvious SRI tag difference, thestr_replacemethod used on scripts in themy_add_srifunction, is different to that used on styles./** * Load custom CSS and JavaScript. */ add_action( 'wp_enqueue_scripts', 'wpdocs_my_enqueue_scripts' ); function wpdocs_my_enqueue_scripts() : void { // Enqueue my styles. wp_enqueue_style( 'wpdocs-bootstrap-style', 'https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.5.2/css/bootstrap.min.css' ); wp_enqueue_style( 'wpdocs-datatables-bootstrap-style', 'https://cdnjs.cloudflare.com/ajax/libs/datatables/1.10.21/css/dataTables.bootstrap4.min.css' ); // Enqueue my scripts. wp_enqueue_script( 'wpdocs-bootstrap-bundle-script', 'https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.5.2/js/bootstrap.bundle.min.js', array(), null, true ); wp_enqueue_script( 'wpdocs-datatables-bootstrap-script', 'https://cdnjs.cloudflare.com/ajax/libs/datatables/1.10.21/js/dataTables.bootstrap4.min.js', array(), null, true ); wp_enqueue_script( 'wpdocs-jquery-datatables-script', 'https://cdnjs.cloudflare.com/ajax/libs/datatables/1.10.21/js/jquery.dataTables.min.js', array(), null, true ); // Add filters to catch and modify the styles and scripts as they're loaded. add_filter( 'style_loader_tag', __NAMESPACE__ . 'wpdocs_my_add_sri', 10, 2 ); add_filter( 'script_loader_tag', __NAMESPACE__ . 'wpdocs_my_add_sri', 10, 2 ); } /** * Add SRI attributes based on defined script/style handles. */ function wpdocs_my_add_sri( $html, $handle ) : string { switch( $handle ) { case 'wpdocs-bootstrap-style': $html = str_replace( ' />', ' integrity="sha512-MoRNloxbStBcD8z3M/2BmnT+rg4IsMxPkXaGh2zD6LGNNFE80W3onsAhRcMAMrSoyWL9xD7Ert0men7vR8LUZg==" crossorigin="anonymous" />', $html ); break; case 'wpdocs-datatables-bootstrap-style': $html = str_replace( ' />', ' integrity="sha512-PT0RvABaDhDQugEbpNMwgYBCnGCiTZMh9yOzUsJHDgl/dMhD9yjHAwoumnUk3JydV3QTcIkNDuN40CJxik5+WQ==" crossorigin="anonymous" />', $html ); break; case 'wpdocs-bootstrap-bundle-script': $html = str_replace( '></script>', ' integrity="sha512-kBFfSXuTKZcABVouRYGnUo35KKa1FBrYgwG4PAx7Z2Heroknm0ca2Fm2TosdrrI356EDHMW383S3ISrwKcVPUw==" crossorigin="anonymous"></script>', $html ); break; case 'wpdocs-datatables-bootstrap-script': $html = str_replace( '></script>', ' integrity="sha512-OQlawZneA7zzfI6B1n1tjUuo3C5mtYuAWpQdg+iI9mkDoo7iFzTqnQHf+K5ThOWNJ9AbXL4+ZDwH7ykySPQc+A==" crossorigin="anonymous"></script>', $html ); break; case 'wpdocs-jquery-datatables-script': $html = str_replace( '></script>', ' integrity="sha512-BkpSL20WETFylMrcirBahHfSnY++H2O1W+UnEEO4yNIl+jI2+zowyoGJpbtk6bx97fBXf++WJHSSK2MV4ghPcg==" crossorigin="anonymous"></script>', $html ); break; } return $html; }Skip to note 40 content
Xedin Unknown
This is not documented, but calling this function with
$in_footerbeing `false` actually registers the script in general as a dependency that should be resolved and output, not just for header. Then, when outputting scripts enqueued for the footer, only the scripts that have not been included yet will be output. This leads to behaviour where a script that is enqueued supposedly in the header will appear in the footer if enqueued after the header has already been process. Therefore,$in_footershould actually read and be understood as$in_footer_only.Skip to note 41 content
Manny Fleurmond
Because this and
wp_enqueue_styleusesWP_Scripts::enqueue(), which can take an array of handles as it’s first argument, you can also pass an array of handles intowp_enqueue_script/style:/** * Enqueue multiple handles */ function enqueue_multiple() { wp_enqueue_script( array( 'backbone', 'jquery', 'iris' ) ); } add_action( 'wp_enqueue_scripts', 'enqueue_multiple' );Skip to note 42 content
Yakovos Frountas
This example is using the new technique of defer or async a script. Also one good practice for versioning of the file is to use the filemtime php native function in order to pass the last modified time of the file as a parameter to the cache.
$url = get_template_directory_uri() . '/js/functions.js'; $time = filemtime( get_template_directory() . '/js/functions.js' ); $args = array( 'in_footer' => true, 'strategy' => 'defer', ); wp_enqueue_script( 'wpdocs-functions', $url, array(), $time, $args );Skip to note 43 content
Mário Valney
For who have the same question of @damiankaelgreen:
In this case script is the file called in one HTML tag script which is used to define a client-side script (JavaScript).
For include PHP files, please use get_template_part().
Skip to note 44 content
indithemes
In some cases, you might want to add scripts as a module. In that case
type="module"needs to be added to the tag. This can be done using the script_loader_tag filter hook.Modules are a newer feature of JS introduced in ES6 and has many advantages over conventional JS files especially if you are working on a large project. You can read about modules in official documentation.
function wpdocs_load_module( $tag, $handle ) { if ( 'wpdocs-script-handle' === $handle ) { $tag = str_replace( '<script ', '<script type="module" ', $tag ); } return $tag; } add_filter( 'script_loader_tag', 'wpdocs_load_module', 10, 2 );wp_enqueue_script_module()function. No tag filtering needed! Do note thatwp_enqueue_script_module()requires a slightly different dependency array structure, so it’s not merely a rename-and-done operation.Skip to note 45 content
Parth Dodiya
Clearing confusion between all three functions. wp_enqueue_script() , wp_register_script() , and wp_localize_script()
wp_register_script()::
Registers a script with WordPress.
Does not load the script on the page.
Useful when you want to define a script for later use with specific conditions or dependencies.
Takes arguments like script handle (unique identifier), script path (URL or relative path to the file), and optional arguments like version number and dependencies on other scripts.
wp_enqueue_script()::
Enqueues a script that need to be loaded on the page.
Can also register the script if it hasn’t been registered before.
Useful for including scripts you need on a specific page or based on certain conditions (e.g., only on the front-end).
Takes arguments like script handle (same as used with wp_register_script) and optional arguments like version number, dependencies, and placement (in the header or footer).
Here’s a key difference:
wp_enqueue_script can handle both registering and loading a script in one call.
wp_register_script only registers the script for later use with wp_enqueue_script or another function that might need it.
wp_localize_script()::
Does not register or enqueue a script.
Used to localize a registered script, meaning it injects PHP variables into the script as JavaScript objects.
Useful for passing data from WordPress (PHP) to your JavaScript code.
Takes arguments like script handle (of an already registered script), a variable name to hold the data in JavaScript, and the actual PHP data (array or object) you want to pass.
In short,
Use wp_register_script to define scripts for later use.
Use wp_enqueue_script to load scripts on the page (can also register if needed).
Use wp_localize_script to pass data from PHP to your registered JavaScript code.
Skip to note 46 content
Anthony Hortin
See Also:
wp_enqueue_style
Skip to note 47 content
damiankaelgreen
This documentation should really do a better job defining what a “script” is… Because: is this function meant for enqueueing a .php or html script? No!
That may seem obvious to a lot of developers, but if you are looking at this documentation, you should be getting some clarity as to what this function should be used for, so I’m writing this to help.
Apparently, in this case, the term “script” is being used as a program that is not being evaluated by the server, but rather a program that needs to be passed to the client (and evaluated by the browser). Thus in this case, a PHP file that is expected to be evaluated by the server would not be considered a script (even though a lot of people might call it one) and thus it should not be included with wp_enqueue_script() , but included using require_once() or possibly include_once() instead.
Skip to note 48 content
Rabby
This example link of custom stylesheet and script with file version version
function custom_enqueue(){ //wp_enqueue_style('string $handle', mixed $src, array $deps, mixed $ver, string $meida ); wp_enqueue_style('customstyle', get_template_directory_uri() . '/css/fatblog.css', array(), '1.0.0', 'all' ); //wp_enqueue_style('string $handle', mixed $src, array $deps, mixed $ver, bol $in_footer ); wp_enqueue_script('customjs', get_template_directory_uri() . '/js/fatblog.js', array(), '1.0.0', 'true' ); } add_action('wp_enqueue_scripts', 'custom_enqueue');Skip to note 49 content
turnipforest
The required CSS for
jquery-ui-dialogdoes not come automatically!You must separately call
wp_enqueue_style()with the registered handle “wp-jquery-ui-dialog”.Skip to note 50 content
Hache_raw
Replace a parent theme JS (or CSS) entirely:
function wpdocs_child_enqueue_scripts() { if ( wp_script_is( 'parent-pagination-infinite', 'enqueued' ) ) { wp_dequeue_script( 'parent-pagination-infinite' ); wp_enqueue_script( 'child-pagination-infinite', get_stylesheet_directory_uri() . '/pagination-infinite.js', array( 'child-theme-js' ), '1.0.0', true ); } } add_action( 'wp_enqueue_scripts', 'wpdocs_child_enqueue_scripts', 15 );Skip to note 51 content
Barbara Ford
Link a Plugin Script That Depends on script.aculo.us
This example is intended to be used within a plugin file to register and link a new plugin script that depends on the script.aculo.us library. See the example above for information about dependencies.
/** * Enqueue script with script.aculo.us as a dependency. */ function my_scripts_method() { wp_enqueue_script( 'newscript', plugins_url( '/js/newscript.js' , __FILE__ ), array( 'scriptaculous' ) ); } add_action( 'wp_enqueue_scripts', 'my_scripts_method' );Skip to note 52 content
Barbara Ford
Link Scripts Only on a Plugin Administration Screen
This example links a script only on a specific administration screen, as opposed to the scenario described in the paragraph below the code of the first example.
<?php /** * Register the plugin script. */ function wpdocs_plugin_admin_init() { // Register our script. wp_register_script( 'my-plugin-script', plugins_url( '/script.js', __FILE__ ) ); } add_action( 'admin_init', 'wpdocs_plugin_admin_init' ); /** * Add Administration screen for the plugin. */ function wpdocs_plugin_admin_menu() { /* Add our plugin submenu and administration screen */ $page_hook_suffix = add_submenu_page( 'edit.php', // The parent page of this submenu. __( 'My Plugin', 'my-textdomain' ), // The submenu title. __( 'My Plugin', 'my-textdomain' ), // The screen title. 'manage_options', // The capability required for access to this submenu. 'my_plugin-options', // The slug to use in the URL of the screen. 'wpdocs_plugin_manage_menu' // The function to call to display the screen. ); /* * Use the retrieved $page_hook_suffix to hook the function that links our script. * This hook invokes the function only on our plugin administration screen, * see: <a href="https://developer.wordpress.org/reference/hooks/admin_print_scripts-hook_suffix/" rel="ugc">https://developer.wordpress.org/reference/hooks/admin_print_scripts-hook_suffix/</a> */ add_action( "admin_print_scripts-{$page_hook_suffix}", 'wpdocs_plugin_admin_scripts'); } add_action( 'admin_menu', 'wpdocs_plugin_admin_menu' ); /** * Enqueue registered script in the admin. */ function wpdocs_plugin_admin_scripts() { // Link our already registered script to a page. wp_enqueue_script( 'my-plugin-script' ); } /** * Display callback for the plugin Administration screen. */ function wpdocs_plugin_manage_menu() { // Display our administration screen. }Skip to note 53 content
Miguel Torres
Not sure if this is the place to report it, but I believe that the Tiny MCE handle that appears on the “Default Scripts Included and Registered by WordPress” table is incorrect. It says
tiny_mce, but according to the code that registers the Tiny MCE scripts (https://core.trac.wordpress.org/browser/trunk/src/wp-includes/script-loader.php?rev=45138#L56-L64) should bewp-tinymce.Skip to note 54 content
Uriahs Victor
When enqueuing a custom script file that you later want to add some inline JS to using wp_add_inline_script() . It’s always best that you have the custom script enqueuing in the footer by setting the last parameter in the function to
truewp_enqueue_script( $handle, $src, $deps, $ver,
true);Skip to note 55 content
vee
The list of libraries seems to be incomplete. For example `lodash`, `react` exists in WordPress vendor scripts but not list in this page, and there are more.
To see full list, go to wp-includes/script-loader.php page.
Skip to note 56 content
Jan Prazak
The $deps parameter may also be null, you don’t have to pass an empty array. See the _WP_Dependency class constructor in
wp-includes/class-wp-dependency.phpSkip to note 57 content
ilovecats7
The action hook used for loading scripts (wp_enqueue_scripts) is called in the head section of the document, so in order for the script to be loaded on the page, you MUST include the following on your page template:
This is inaccurate. This code fetches the header.php file. What must actually be included in the template is:
The confusion here is that most header files contain the
wp_head();hook.Skip to note 58 content
Drew Jaynes
This is the place to report it. I’ve updated the table with your changes. Thanks!