The basic concept of including and/or adding resources (scripts and stylesheets) to any website is to add it to the <head></head> section of the HTML document. But what happens when you have a dynamic content management system like WordPress where multiple different systems (WordPress core, plugins, and themes) may all be attempting to add the same scripts and/or styles? Unless there is a management to control how assets are added to the site, the site will have nothing but trouble.
WordPress solved this issue early in its history by standardizing the method in which all assets are handled and processed on the site. Almost everything added to a WordPress site runs through the hook wp_enqueue_scripts. This article will talk about how the hook works in order to add stylesheets and scripts to the site, how dependency management works, and some advanced tips and tricks.
So how does this wp_enqueue_scripts work?
Basically, there are two steps taken when adding a script of stylesheet. (Though there is a shortcode where it will appear only one step is taken… more on that later.)
- We need to register the script… i.e inform WordPress where the script is located.
- We need to enqueue the script and connect it to the WordsPress hook that understands whether to place the script into the site’s header or right before the closing <body> tag.
PRO TIP: So why are there two steps? Because there may be times you want to “register” the script, but you may only want to conditionally load or use that script in one or two locations of the site. The two-step process provides modularity.
Basics of enqueuing
As mentioned earlier in the article, everything revolving around the enqueuing of assets to a WordPress site is going to run through the wp_enqueue_scripts hook. If you are interested in learning more about WordPress hooks, I recommend starting here. Inside the wp_enqueue_scripts hooked function, we use four different WordPress functions that handle the registering and enqueueing of the assets.
In the above code example, you can see that script is first registered using the wp_register_script function and then later in the function the same identifier (‘custom-script’) is called inside the wp_enqueue_script function. And the same is done for the style.css file using the wp_register_style and wp_enqueue_style functions.
One of the major benefits of using the WordPress enqueueing system is that it already has built-in support for dependency management. (What is dependency management? Let’s say you are adding a jQuery tooltip script and in order for the tooltip script to function it needs jQuery to load BEFORE the tooltip script. Dependency management takes care of all that to make sure everything that is required to load happens in the right order.) In fact, because the WordPress wp_enqueue_script function has dependency management, we have the option of simply enqueueing the script and not run a separate registration function. Here is an example:
In the above example, the dependent.js file is given a script ID (custom-dependency), declared the location (plugins_url( ‘/js/dependency.js’), and then tells WordPress that this dependent.js script file requires (depends upon) jQuery to be loaded.
Load a Script in the Header or Footer
Sometimes you MUST load a script and/or stylesheet in the header in order for the site to function properly. But sometimes you can have the script load right before the closing of the </body> tag. There are many benefits of loading a script at the end of a page, but one of the key ones is it improves the speed of a site and helps eliminate “render-blocking scripts” that you’ll see in lots of website speed measurement reports.
This is where another benefit of the enqueueing functionality in WordPress comes into play. Using the fifth parameter in the wp_enqueue_script function (note: the fourth parameter is an optional version number of the script/stylesheet), we can specify whether or not to load the script in the header or the footer.
In the fifth parameter, by stating the argument to be true, the script will be loaded in the footer. If you state the fifth parament to be false, the script will be loaded in the header. (NOTE: if you leave off this fifth parameter, the script will automatically be loaded in the header.) This header/footer option as a fifth parameter is only utilized in a script enqueue process (wp_enqueue_script). If you are dealing with a stylesheet (wp_enqueue_style), there is a different parameter used in this location.
Only Load a Stylesheet on a Specific Media Type
If you are familiar with writing Media Queries in CSS, you will be right at home with utilizing the fifth parameter in the wp_enqueue_style function. The fifth parameter for those function allows you to control the stylesheet will be loaded based upon which media type is in use. (Example: screen, print, handheld, etc). For more about Media Types, you can read this article.
To dig deeper into wp_enqueue_script function, you can head over to developer.wordpress.org.
wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
- $handle = The name of the script. Should be unique
- $src = Full URL of the script, or path relative to the WordPress root directory
- $deps = An array of registered script handles this script depends upon.
- $ver = String specifying a script version number
- $in_footer = Whether or not to enqueue the script in the header or footer (true/false)
To dig deeper into wp_enqueue_style function you can head over to developer.wordpress.org.
wp_enqueue_style( $handle, $src, $deps, $ver, $media );
- $hanlde = The name of the stylesheet. Should be unique
- $src = Full URL of the stylesheet or path relative to the WordPress root directory
- $debs = An array of registered stylesheet handles this stylesheet depends upon.
- $ver = String specifying stylesheet version
- $media = The media for which this stylesheet has been defined.
wp_enqueue_scripts (plural) is the WordPress hook that we connect a PHP function containing our wp_enqueue_script() and wp_enqueue_style() functions in order to connect all our assets (scripts and stylesheets) in WordPress.