Enqueuing Scripts & Styles Properly

WordPress Intermediate/Advanced

Chapter 7 · Enqueuing Scripts & Styles Properly

WordPress Intermediate/Advanced 1's header.php called wp_head() so plugins could inject their own output — but that hook alone doesn't stop a theme from loading its own CSS and JavaScript the wrong way. This chapter covers the correct mechanism, and the real conflicts it exists specifically to prevent.

The Wrong Way — Hardcoding Tags Directly

<!-- inside header.php — don't do this --> <link rel="stylesheet" href="/wp-content/themes/my-theme/style.css"> <script src="/wp-content/themes/my-theme/js/main.js"></script>

This works, in the narrow sense that the browser will load the files — but it has real, concrete problems: no dependency management, no way to prevent the same library being loaded twice by a theme and a plugin that both need it, and no way for WordPress or anything else to know these files were loaded at all.

The Right Way — wp_enqueue_script() / wp_enqueue_style()

<?php function my_theme_scripts() { wp_enqueue_style( 'my-theme-style', get_stylesheet_uri(), array(), '1.0' ); wp_enqueue_script( 'my-theme-script', get_template_directory_uri() . '/js/main.js', array( 'jquery' ), '1.0', true ); } add_action( 'wp_enqueue_scripts', 'my_theme_scripts' ); ?>

Note the hook — wp_enqueue_scripts, a dedicated action specifically for this purpose, distinct from the init hook Chapters 4 and 5 already used for post types and general setup.

ParameterWhat it does
HandleA unique name identifying this specific file — how WordPress and other plugins refer to it
Source URLWhere the file actually lives — get_stylesheet_uri()/get_template_directory_uri() reference the active theme's own files correctly, rather than a hardcoded path
DependenciesAn array of handles that must load first — the actual mechanism preventing the wrong-way problems above
VersionAppended to the URL for cache-busting — bump it when the file changes so browsers don't serve a stale cached copy
In footer (scripts only)Loading JavaScript near the end of the page rather than the head — directly relevant to Performance & Core Web Vitals's own material

Dependencies — Where the Real Conflict Prevention Happens

jQuery is already registered — use it, don't reload it
WordPress core ships with jQuery already bundled and registered under the handle jquery. Listing array( 'jquery' ) as a script's dependency does two things at once: it guarantees jQuery loads before your script regardless of enqueue order, and — critically — if jQuery is already enqueued by anything else (another plugin, the theme itself), WordPress won't load a second copy. This is the concrete, code-level fix for exactly the kind of resource-duplication conflict WordPress Fundamentals 6 only ever described as a symptom to troubleshoot.
What the hardcoded version actually risks
Two plugins each hardcoding their own <script src="jquery.js"> tag, with no shared handle and no dependency system involved, can genuinely load two separate copies of jQuery on the same page — wasted bandwidth at best, and real, hard-to-diagnose JavaScript conflicts at worst, since two independently-loaded copies of the same library don't share state with each other.

Referencing Theme Files Correctly

get_stylesheet_uri() returns the active theme's own style.css URL, and get_template_directory_uri() returns the theme folder's own base URL — both resolve correctly regardless of what the site's actual domain or folder structure happens to be, unlike a hardcoded path that would break the moment the site moved or the folder structure changed.

Hands-On Exercises

Exercise 1

A theme hardcodes its own jQuery-dependent script tag directly in header.php, and a separately installed plugin also enqueues jQuery properly via wp_enqueue_script(). Explain what happens on the page as a result, using this chapter's own material.

📄 View solution
Exercise 2

Explain why a developer would bump a script's version parameter from '1.0' to '1.1' after editing the file, and what would go wrong for returning visitors if they forgot to.

📄 View solution
Exercise 3

Explain why wp_enqueue_scripts, not init, is the correct hook for enqueuing scripts and styles, based on what this chapter says about dedicated hooks.

📄 View solution

Chapter 7 Quick Reference

  • Never hardcode <link>/<script> tags directly — no dependency management, real risk of duplicate-library conflicts
  • wp_enqueue_style()/wp_enqueue_script(), hooked to wp_enqueue_scripts (not init)
  • Handle, source URL, dependencies array, version (cache-busting), in_footer (scripts) — the five real parameters
  • jQuery ships pre-registered under the handle 'jquery' — depending on it avoids duplicate loads across theme and plugins
  • get_stylesheet_uri()/get_template_directory_uri() reference theme files correctly, unlike a hardcoded path
  • Next chapter: Security Hardening