Stop loading a compatibility patch your site doesn't need
Disable jQuery Migrate removes the compatibility script WordPress loads alongside jQuery on every front-end page, without touching jQuery itself.
- Removed from jQuery's own dependency chain, not just dequeued.
- Deregistered entirely, so nothing can load it directly either.
- Only affects the front end; the admin area is untouched.
- jQuery itself keeps loading and working exactly as before.
What does Disable jQuery Migrate do?
When the remove_jquery_migrate module is active, TOWP_Remove_jQuery_Migrate hooks into wp_default_scripts, a point early enough to modify WordPress's script registry before anything gets enqueued. It removes jquery-migrate directly from the jquery handle's own dependency list, so nothing that requests jQuery pulls Migrate in as a side effect, and then deregisters jquery-migrate entirely so it can't be loaded standalone either. The change only applies to the front end; an explicit check exits immediately for admin requests.
jQuery Migrate exists to keep very old code running
A compatibility layer built for a bygone era of jQuery code still loads on every page, whether anything needs it or not.
It restores behaviour jQuery itself removed
jQuery Migrate exists so that code written for versions of jQuery long superseded keeps working, by patching back in APIs that jQuery's own developers deliberately removed.
It loads on every page, regardless of whether anything needs it
On a site running a current theme and current plugins, that compatibility layer is a file downloaded and parsed on every single front-end page for nothing at all.
Remove the patch, keep jQuery itself
The module removes jQuery Migrate cleanly from WordPress's script dependency chain, without touching jQuery or anything that depends on it.
Removed from jQuery's own dependency list
Migrate is stripped directly out of jQuery's registered dependencies, so nothing that requests jQuery pulls it in automatically.
Deregistered as a standalone script too
Beyond the dependency fix, jquery-migrate is deregistered entirely, closing off any direct attempt to enqueue it by name.
The admin area is never touched
An explicit check keeps the removal scoped to the front end, so any admin-side reliance on Migrate is unaffected.
A clean removal, not a fragile one
Every capability below is present in the supplied PHP class and its settings registration.
wp_default_scripts, before enqueueing
The removal happens on wp_default_scripts, early enough to modify the script registry itself rather than reacting after scripts are already queued.
Removed from jQuery's own deps array
jquery-migrate is stripped out of the jquery handle's registered dependencies, the mechanism that would otherwise pull it in for any script requesting jQuery.
Fully deregistered
The script is deregistered entirely, so a theme or plugin explicitly enqueuing jquery-migrate by handle can't load it either.
Front end only
An is_admin() check exits immediately for admin requests, leaving wp-admin's own script loading completely unaffected.
Effective regardless of load order
Because the fix happens at the dependency-registry level, it works correctly even when other plugins or the theme also request jQuery.
Nothing about jQuery changes
Only the Migrate compatibility layer is removed; jQuery continues to load and function exactly as it did before.
Where removing Migrate helps most
The module supports any site whose theme and plugins no longer need a compatibility patch built for older jQuery code.
Sites on current themes and plugins
Remove a compatibility file that has nothing to patch when everything installed is reasonably current.
General front-end performance cleanup
Pair it with other unused-asset removals for a cumulative reduction in what a typical page downloads.
Confirming no legacy code depends on it
Use it as a practical test: if a page breaks after disabling Migrate, that page relies on jQuery APIs long since replaced.
Less weight, a robust removal
The module combines a genuine performance saving with a technically correct fix that holds under real-world load order.
A request removed, once, cleanly
The verified implementation is a single early hook with no added overhead of its own.
One less request and parse, per page
A file removed from every front-end page load, regardless of whether that page uses jQuery-dependent scripts at all.
A single, early hook
The change happens once, at wp_default_scripts, rather than through a repeated check on every script enqueue.
No effect in the admin
Because the check exits immediately for admin requests, there's no added overhead anywhere the script might still be relied upon.
A registry edit, nothing else touched
The code modifies exactly one dependency list and accepts no input of its own.
A registry-level change, not a runtime filter
The removal happens directly on WordPress's script registry object, using the same API WordPress itself exposes for this purpose.
Administrator-only configuration
Only an administrator with access to TheOneWP settings can enable the module.
No new input surface
The module only edits an existing dependency array and deregisters a script handle; it doesn't accept or process any user input.
Explicitly scoped to the front end
The is_admin() check is a deliberate safeguard against the module ever affecting scripts loaded in wp-admin.
Built around native WordPress script registry APIs
The supplied code integrates through APIs present in WordPress core. No compatibility claim beyond the verified implementation is assumed.
wp_default_scripts
The core action WordPress fires while building its default script registry, before anything is queued for a specific page.
Direct deps array modification
Edits the jquery handle's own registered dependency list, the same structure WordPress uses internally to resolve what a script needs.
WP_Scripts::remove()
The standard method for removing a script from the registry entirely, used here on the jquery-migrate handle specifically.
TheOneWP versus common alternatives
Compare the verified Disable jQuery Migrate implementation with a typical simple-dequeue snippet.
| Capability | TheOneWP Disable jQuery Migrate | Other common solutions |
|---|---|---|
| Removing Migrate cleanly | Removed from jQuery's own dependency list | A simple dequeue can be re-added by anything requesting jQuery |
| Standalone loading | Deregistered entirely, not just dequeued | Often still loadable by a direct enqueue call |
| Admin safety | Front end only, admin explicitly excluded | A poorly-scoped snippet can affect admin scripts too |
| Timing | Registry-level, before scripts are queued | A later hook can miss scripts already queued by then |
| Administration | One toggle, nothing else to configure | Usually the same, when available at all |
Confirm nothing depends on Migrate in four steps
Verify JavaScript-heavy pages after enabling, since that's where a dependency would surface first.
Enable Disable jQuery Migrate
Activate the module from the TheOneWP settings; the script stops loading on the front end immediately.
Check JavaScript-heavy pages
Browse the pages that use the most front-end JavaScript to confirm nothing relies on deprecated jQuery behaviour.
Watch the browser console
Look for any JavaScript error that might point to code still depending on an API Migrate used to restore.
Leave it on
Since there's no ongoing configuration, the module simply keeps working once enabled.
Verify before relying on it fully
A quick check of older scripts is the difference between a safe cleanup and an unexpected error.
Test the pages with the oldest custom scripts first
Legacy jQuery dependencies are most likely to surface on pages carrying older, hand-written JavaScript.
Check third-party plugin widgets too
An older plugin's front-end widget is another common place outdated jQuery usage can hide.
Use the browser console as a quick verification
A jQuery-related error after enabling this module usually points directly at the affected script.
Re-enable it if something genuinely depends on it
If a real dependency turns up, turning the module back off restores Migrate immediately with no side effects.
Avoid assumptions that aren't quite accurate
The scope of what this module actually removes is easy to misjudge at a glance.
Assuming jQuery itself is affected
Only the Migrate compatibility layer is removed; jQuery continues to load and run exactly as it did before.
Not checking older, custom-written scripts
A theme's own hand-written JavaScript from several years ago is the most likely place a Migrate dependency still exists.
Looking for a settings screen that isn't there
Like other single-purpose modules, this one is a toggle by design, with no further configuration screen.
Disable jQuery Migrate FAQ
These answers come directly from the verified class and its settings registration.
What does Disable jQuery Migrate do?
It removes the jQuery Migrate compatibility script from the front end, both from jQuery's own dependency list and as a standalone script.
Does this affect jQuery itself?
No. Only the Migrate compatibility layer is removed; jQuery continues to load and function exactly as before.
Why is jQuery Migrate loaded by WordPress in the first place?
It restores jQuery behaviour that was deliberately removed in later versions, so code written for older versions keeps working.
Will removing it break anything on my site?
Only if a script still depends on jQuery APIs that Migrate restores; checking JavaScript-heavy pages after enabling the module is the practical way to find out.
Does this affect the WordPress admin area?
No. The module only runs on front-end requests and explicitly excludes the admin area.
How is this different from a simple dequeue?
The module edits jQuery's own dependency list directly, so Migrate can't be pulled back in by anything else that requests jQuery, and also deregisters it to block direct standalone loading.
Are there any settings beyond turning the module on?
No. It's a single toggle with no additional configuration.
Will this improve page load performance?
It removes one script download and parse from every front-end page, a small but genuine reduction.
What should I check after enabling this module?
Browse pages with significant custom JavaScript and watch the browser console for any error that suggests a Migrate dependency.
Who can turn this module on?
Only an administrator with access to the TheOneWP settings screen.
Stop loading a patch for jQuery code nobody's writing anymore.Keep jQuery, remove the compatibility layer.
Use Disable jQuery Migrate to remove the compatibility script from the front end, cleanly, without touching jQuery itself.