WordPress Theme JavaScript Errors: Read the Console, Then Fix the Right Script

Dead buttons and frozen sliders: how a script failure looks

JavaScript runs the moving parts of a theme: the hamburger menu, sticky headers, tabs, accordions, lightboxes, product galleries, AJAX cart updates and most page builder editors. When one script fails, the page still loads and still looks mostly right. It just stops responding in one spot. That is why owners often describe a JavaScript fault as a design problem or a mobile problem, and why so many pages about a mobile menu that will not open end up being pages about scripts.

• A menu, search icon or drawer that does nothing when tapped, or opens empty.
• A slider, carousel or gallery stuck on its first image, or images stacked in a column.
• Forms that never submit, or a checkout button that spins forever.
• A page builder editor stuck on its loading screen, while the public page still works.
• Faults that appear for visitors but not for you while logged in, which points at a cache or an optimizer that only serves logged-out traffic.

That last pattern matters. Many optimization plugins skip logged-in administrators, so the person who checks the site is the one person who never sees the broken version. Always reproduce the fault in a private window before you start.

Two minutes in the browser console

Open the broken page in Chrome or Edge, press F12 (Cmd+Option+J on a Mac in Chrome) and choose the Console tab. Reload. Red lines are errors; yellow lines are warnings and can usually wait. Read the first red error, not the last, because one uncaught error stops the rest of that script from running and often causes the errors that follow it.

Each error ends with a file name and line number. Click it. A path containing wp-content/themes/ names the theme; wp-content/plugins/ names the plugin. If the path points into a cache folder with a long random file name, an optimizer has combined several scripts into one, and the real culprit is hidden inside. Switch combining off and reload to see the original file names. A missing file shows up on the Network tab: a Kadence 1.5.2 user found the Scroll To Top button did nothing because scroll-up.min.js returned a 404.

The usual suspects, most likely first

1. An optimizer rearranged the scripts

Combine, minify, defer and delay settings change the order in which scripts arrive. That is their whole job, and it is also how they break things. A small inline script that calls jQuery on page load fails if jQuery has been pushed to the end of the page or delayed until the visitor scrolls. Check by turning off every JavaScript optimization setting in your caching plugin, clearing all caches and reloading in a private window. Two real cases: OceanWP staff confirmed in August 2026 that the theme's mobile menu fails when SiteGround Speed Optimizer's Combine JS setting is on, and a Neve user traced an iOS Safari hamburger that would not respond to the same plugin.

2. A jQuery dependency nobody declared

WordPress loads scripts in the order their dependencies say. A script registered with jQuery as a dependency always prints after jQuery. A script pasted into a header box, a widget or a builder's custom code field declares nothing, so it runs whenever it lands. WordPress also runs its bundled jQuery in noConflict mode, which means the familiar $ shortcut is not defined globally; code copied from a tutorial written for another platform fails on the first line. Check by searching your custom code areas for $( and for scripts loaded without a dependency.

3. A conflict between two scripts

Two plugins that do the same job, such as two lightboxes, two sliders or two lazy loaders, attach to the same elements and trip over each other. A plugin that loads its own copy of a library can do the same. Check by testing plugins on staging, one at a time, as described in the theme and plugin conflict guide.

4. The theme update itself

Sometimes the theme really did break. Hello Elementor 3.3.0 drew a support thread titled 'Theme 3.3.0 Broke Mobile Navigation', and Customizer header changes failed to save with Hello 3.4.7 and Elementor 4.0.8 while the console showed errors in Elementor's editor scripts. Check the date the fault began against your update history.

Which themes still lean on jQuery

Most popular themes have stopped needing jQuery on the front end, which changes where you should look. When we inspected the source, Astra 4.14.0 declared a jQuery dependency in one WooCommerce-related script only, Kadence 1.5.2 only in WooCommerce-related scripts, GeneratePress 3.6.1 only in Customizer controls, and Blocksy 2.1.58 in none of its scripts. Bricks uses plain JavaScript. On those themes, a 'jQuery is not defined' error almost always comes from a plugin or a custom snippet, not the theme.

Older and heavier themes are different. Hestia enqueues Bootstrap's JavaScript, which depends on jQuery, and its support staff suspected plugin script conflicts when mobile sub-menus opened only on desktop. Divi defers jQuery to the footer by default but moves it back to the header when a header script needs it. Avada can defer jQuery too, and its documentation warns that doing so can break scripts. Newspaper combines and minifies its own JavaScript, so its errors need their own approach: see Newspaper JavaScript errors.

Repair the script order without losing the speed gains

1. 1

   Reproduce it logged out

   Open the page in a private window on the device where it fails. Note the exact action that breaks: the tap, the scroll, the click.

2. 2

   Capture the first error

   Copy the first red console error with its file path and line number. Screenshot it. This is the evidence every later step depends on.

3. 3

   Switch off JavaScript optimization

   Disable combine, minify, defer and delay settings in the caching or optimization plugin, then clear the plugin cache, server cache and CDN. If the fault disappears, the optimizer is involved.

4. 4

   Exclude, do not abandon

   Turn the settings back on one at a time. When the fault returns, add the failing script, or jQuery itself, to that setting's exclusion list rather than disabling the whole feature.

5. 5

   Fix the snippet if it is yours

   Wrap custom code in a jQuery ready function that passes $ in, or rewrite it without jQuery, and load it with a declared dependency from a child theme or a code snippets plugin.

6. 6

   Test plugins on staging

   If optimization was not the cause, disable plugins on a staging copy and re-enable them one by one until the error returns.

7. 7

   Roll back or report

   If a theme or plugin update caused it, restore the previous version from backup and send the vendor the console error, the versions and the steps to reproduce.

Exclusion lists are the fix most people miss. Turning off an optimizer entirely makes the error go away and the page slower, and someone switches it back on a month later. A documented exclusion keeps both the speed and the menu. For the speed side, see our guide to themes that ship the least CSS and JavaScript.

Theme pages for errors with a known cause

If you know your theme, start with the page written for it. These use the theme's real settings and known issues rather than general advice.

• Astra mobile menu not working, for the off-canvas menu that opens empty on real phones while emulation works.
• OceanWP mobile menu repair, including the Combine JS conflict.
• Neve mobile menu not working and Hello Elementor mobile menu not working.
• Elementor not loading, when the editor spinner never stops and the console names a script.
• WooCommerce checkout not working, when a script error blocks the Place Order button.

Keeping the console clean after the next round of updates

JavaScript errors return because the things that cause them keep changing: plugin updates, theme updates and optimizer settings that someone tweaks to chase a speed score. A short routine catches most of them before customers do.

• Run one optimization plugin, not two. Two tools combining and delaying the same files multiply the ways script order can go wrong.
• Keep a written list of every exclusion you add and why, so the next person does not remove it.
• After any update, open the home page, a product or service page and the contact form in a private window with the console open. It takes five minutes.
• Put custom code in a child theme or a snippets plugin with declared dependencies, never in a header box.
• Update on staging first, especially the theme, the builder and the optimizer.

Our hosting and maintenance plans run tested updates with a backup taken first, and our theme troubleshooting service handles the cases where the console points somewhere you cannot follow. For plugin-led faults, see plugin repair.

When the script pile is the real problem

A WordPress page often loads scripts from the theme, the builder, an add-on pack, a slider, a form plugin, a cookie banner and an analytics tag, each written by a different team. An optimizer then rearranges them all to win back the speed they cost. Every update reshuffles that deck. If you fix a script conflict every quarter, the fault is the arrangement, not any single file.

A Next.js site works differently. Its JavaScript is written and bundled as one project, its packages are pinned, and the build fails loudly on a developer's machine instead of quietly on a visitor's phone. It costs more to build and needs a developer for layout changes, so it is not for every site. To weigh it fairly, read about responsiveness and INP on WordPress vs Next.js and plugins vs a single codebase, then see what a move to Next.js involves. More symptoms live in the troubleshooting section.