wp_enqueue_scripts is the proper hook to use when enqueuing scripts and styles that are meant to appear on the front end. Despite the name, it is used for enqueuing both scripts and styles.
do_blocks() is called before wp_enqueue_scripts so if you are correctly registering scripts and only enqueuing on pages it’s needed on (which most developers do not seem to do), keep in mind that if you use something like wp_localize_script, it will not work if you’re registering your script in wp_enqueue_scripts hook and enqueueing it from some kind of trigger generated by content, shortcode, template files, or something else that could be loaded by do_blocks.
This will result in javascript errors saying XYZ variable is not defined
I had a lot of plugin clients report issues because of this, as my call to wp_enqueue_script is normally triggered by a template file or something that now gets loaded in do_blocks() (like a shortcode), which is BEFOREwp_enqueue_scripts action is triggered, meaning the script is not registered yet.
The solution for me in this situation was to create a conditional check before calling wp_localize_script and then wp_enqueue_script, to see if the script has been registered already, and if not, make sure to call wp_register_script first.
This actions passes an argument $hook that is handy when for example to prevent the script from loading on certain pages;
function wpdocs_enqueue_scripts( $hook ) {
// Load only in add new post page
if ( is_admin() && 'post-new.php' !== $hook ) {
return;
}
// rest of your code here..
}
add_action( 'wp_enqueue_scripts', 'wpdocs_enqueue_scripts' );
This is not true for the wp_enqueue_scripts action, however, it does apply for the admin_enqueue_scripts action.
Basic Example
Instead of this Action, use ‘admin_enqueue_scripts’ for Admin pages and ‘login_enqueue_scripts’ for the login page.
If you want to add dynamic inline styles.
Selectively load JS files into specific pages like so:
do_blocks()is called beforewp_enqueue_scriptsso if you are correctly registering scripts and only enqueuing on pages it’s needed on (which most developers do not seem to do), keep in mind that if you use something likewp_localize_script, it will not work if you’re registering your script inwp_enqueue_scriptshook and enqueueing it from some kind of trigger generated by content, shortcode, template files, or something else that could be loaded bydo_blocks.This will result in javascript errors saying
XYZ variable is not definedI had a lot of plugin clients report issues because of this, as my call to
wp_enqueue_scriptis normally triggered by a template file or something that now gets loaded indo_blocks()(like a shortcode), which is BEFOREwp_enqueue_scriptsaction is triggered, meaning the script is not registered yet.The solution for me in this situation was to create a conditional check before calling
wp_localize_scriptand thenwp_enqueue_script, to see if the script has been registered already, and if not, make sure to callwp_register_scriptfirst.This actions passes an argument
$hookthat is handy when for example to prevent the script from loading on certain pages;wp_enqueue_scriptsaction, however, it does apply for theadmin_enqueue_scriptsaction.