WordPress JavaScript Errors: Fixing Plugin and Theme Issues

How WordPress loads JavaScript

Well-behaved themes and plugins do not print script tags directly. They register each file with wp_enqueue_script(), giving it a handle (a short name), an address, a list of other handles it depends on, a version and loading options. WordPress then prints the tags in the right order, once each, in the head or the footer. That system is what makes it possible to reorder, remove or defer scripts safely, because you can target a script by its handle.

Problems start when code sidesteps it:

• Hard-coded script tags in header.php, footer.php or a "header and footer scripts" box cannot be dequeued, ordered or deferred by WordPress.
• Plugins that bundle their own copy of a library, such as jQuery or a slider, can load it twice or overwrite the version other plugins expect.
• Missing dependencies. A plugin that uses jQuery but does not list jquery as a dependency may run before jQuery exists, which works by luck until something changes the order.

Since WordPress 6.3, wp_enqueue_script() accepts a strategy of defer or async. WordPress checks the dependency tree and only applies the strategy where it is safe, which makes it the cleanest way to defer scripts on a WordPress site.

Seeing who loads what

The JavaScript Checker loads the page in headless Chromium and lists each script with its size and execution time, the console errors and the render-blocking files. That tells you what the visitor's browser has to deal with. Two free plugins then connect each file to its source inside WordPress:

To make errors in core WordPress scripts readable, add define( 'SCRIPT_DEBUG', true ); to wp-config.php on staging. WordPress then loads the unminified versions of its own files, so line numbers point at readable code. Switch it off again afterwards.

The jQuery problems behind most WordPress conflicts

WordPress still ships jQuery, and many themes and plugins use it. Three mistakes account for a large share of WordPress console errors:

1. Using $ without wrapping the code

WordPress loads jQuery in no-conflict mode, so the global $ shortcut is not set. Code copied from a tutorial that starts with $(document).ready fails with $ is not a function or $ is not defined. Pass $ in instead:

jQuery(function ($) {
  $('.faq-toggle').on('click', function () {
    $(this).next('.faq-answer').slideToggle(150);
  });
});

2. Relying on removed jQuery functions

WordPress moved to a modern jQuery version several years ago. Old plugins and themes that call long-removed methods such as .live(), .size() or .andSelf() fail with messages like jQuery(...).live is not a function. Update the plugin or theme, or replace the call (.on(), .length, .addBack()) in your own code. Relying on jQuery Migrate to hide such errors only postpones the fix.

3. Inline scripts that run before jQuery loads

If jQuery is moved to the footer or deferred, any inline script in the page body that calls it will fail. Attach the code to the right handle with wp_add_inline_script() so WordPress prints it after the file it needs:

wp_add_inline_script( 'example-booking', 'window.exampleBooking.init();', 'after' );

The fix, step by step

Example: enqueueing and trimming scripts correctly

This goes in a child theme's functions.php or a small site-specific plugin. The handles example-gallery and example-forms are placeholders; take the real handles from Query Monitor.

add_action( 'wp_enqueue_scripts', function () {
    // Our own script: deferred, in the footer, loaded only on single posts.
    if ( is_singular( 'post' ) ) {
        wp_enqueue_script(
            'example-gallery',
            get_stylesheet_directory_uri() . '/js/gallery.js',
            array(),
            '1.4.0',
            array( 'strategy' => 'defer', 'in_footer' => true )
        );
    }
}, 20 );

add_action( 'wp_enqueue_scripts', function () {
    // A form plugin's script is only needed on the contact page.
    if ( ! is_page( 'contact' ) ) {
        wp_dequeue_script( 'example-forms' );
    }
}, 100 );

Page builders, block themes and optimisation plugins

• Page builders. Elementor, Divi, Beaver Builder and similar tools load scripts for animations, sliders and popups that must run early. "Delay JavaScript until interaction" settings often break them, and some break only in the editor. Use the exclusion lists your optimisation plugin provides, and switch off builder widgets you do not use in the builder's own settings.
• Combining files. Merging all scripts into one file was useful before HTTP/2. Today it often causes errors by changing load order and makes caching worse, since any change invalidates the whole file. Turn combining off unless testing shows a clear gain.
• Block themes. Block themes can load the styles and scripts for core blocks only on pages that use them. Third-party block plugins vary, so check whether their files appear on pages without their blocks.
• Newer WordPress APIs. Recent releases add a script modules API and the Interactivity API used by some core blocks. If you see type="module" scripts from /wp-includes/, they are part of WordPress and already load without blocking.
• WooCommerce. Cart fragment scripts and checkout scripts are needed on shop pages. Test the basket, mini-cart and checkout after any change that touches them.

Keeping WordPress scripts under control

• Update on staging first, then run the JavaScript Checker on your key templates before updating live.
• Remove plugins you do not use, rather than just deactivating and forgetting them.
• Keep custom code in a child theme or site plugin, enqueued properly, never pasted into header boxes.
• Record your dequeue rules and optimisation exclusions in one place with the reason for each.
• Watch real-user errors. A single test load misses errors that only happen for logged-in users, specific browsers or after a form submission.

For loading speed and layout shift on WordPress, see the WordPress Core Web Vitals guide.