Why is there a constant notice,

JQMIGRATE: Migrate is installed, version 1.4.0

that points to load-scripts.php in my console when I updated my theme to WordPress 4.5, and how can it be removed?

It's not an error, but it's always present in my console, and I really don't see what's the point of it. Should I update something, or make some changes to my code?

Maybe I have a bit of OCD, but usually when I inspect the site, I like to see errors and real notices that point to an issue in my console...


WordPress 5.5 removed jQuery Migrate script, as a preparation step for updating jQuery to the latest version in 5.6. So the notice should be gone.


  • +1 to your very useful OCD. This probably come from the jquery migration/backward compatibility script. Any chance you use unminified/dev version of it? Apr 24, 2016 at 10:12
  • Unminified version of migrate? Not to my knowledge no, it could be some plugins, but upon inspection I don't see any of it :\
    – dingo_d
    Apr 24, 2016 at 11:40
  • 1
    note both versions are in WP dirs: /wp-admin/js/jquery/jquery-migrate.js and /wp-admin/js/jquery/jquery-migrate.min.js
    – majick
    Apr 25, 2016 at 9:40

7 Answers 7


WordPress uses the jQuery migrate script to ensure backwards compatibility for any plugins or themes you might be using which use functionality removed from newer versions of jQuery.

With the release of WordPress 4.5, it appears they have upgraded the version of jQuery migrate from v1.2.1 to v1.4.0 - Having a quick scan through the code reveals that v1.4.0 logs that the script is loaded regardless of whether or not the migrateMute option is set, in both the uncompressed and minified versions.

The only way to remove the notice is to ensure all your plugins/theme code don't rely on any old jQuery functionality, and then remove the migrate script. There's a plugin out there to do this, but it's quite a simple method that can just be placed in your theme's functions file or similar:

add_action('wp_default_scripts', function ($scripts) {
    if (!empty($scripts->registered['jquery'])) {
        $scripts->registered['jquery']->deps = array_diff($scripts->registered['jquery']->deps, ['jquery-migrate']);

Please note that this is not considered best practice for WordPress development and in my opinion the migrate script should not be removed just for the sake of keeping the developer console clean.

  • So basically one of my plugins is depending on a functionality that was a part of the old jQuery version? Is there a way to find out what that functionality is? Or am I safe to just mute the migrate script?
    – dingo_d
    Apr 24, 2016 at 12:24
  • 1
    I can't say for sure whether any of your plugins depend on old functionality, WordPress just includes the migrate script as a safe default in case your install has any plugins which haven't been updated in a while. If it were me I'd remove the migrate script on a local install of the site and then check everything still works as expected, ensuring there are no errors in the console etc.
    – Andy
    Apr 24, 2016 at 12:29
  • 3
    @majick It's beyond the scope of this answer to discuss whether removing the script is a good idea or not, this specifically addresses the issue of how to remove the message in the console. FWIW, I think removing the script is a bad idea also. I think the downvote is uncalled for, as my answer perfectly answers the OPs question.
    – Andy
    Apr 25, 2016 at 8:49
  • 1
    sorry I don't downvote often, but felt it was needed here as there is no warning that this may not be a good idea and is the opposite of best practice in development (add a warning and i'll remove the downvote.) I believe the question is asking how to remove just the console message not how to remove jquery migrate itself. if someone asked how to remove the update nag message in WordPress you wouldn't answer "just uninstall WordPress."
    – majick
    Apr 25, 2016 at 9:10
  • 1
    no probs, downvote removed. for myself, if it really annoyed me, I'd prefer to just comment out the message in the migrate js file each WP upgrade over removing it entirely anyway. just because javascript is pretty temperamental, sometimes one thing out of place and almost everything breaks.. that is just too much of a risk with no gain when this is specifically in place to avoid that.
    – majick
    Apr 25, 2016 at 9:27

You could change the log message text to blank in jquery-migrate.min.js but this will not be preserved on core update.

The alternative is to add passthrough/filter function copy of console.log to just before the migrate script is loaded, and tell it to ignore logging messages that contain 'Migrate is installed'. Doing it this way will preserve other Migrate warnings too:

// silencer script
function jquery_migrate_silencer() {
    // create function copy
    $silencer = '<script>window.console.logger = window.console.log; ';
    // modify original function to filter and use function copy
    $silencer .= 'window.console.log = function(tolog) {';
    // bug out if empty to prevent error
    $silencer .= 'if (tolog == null) {return;} ';
    // filter messages containing string
    $silencer .= 'if (tolog.indexOf("Migrate is installed") == -1) {';
    $silencer .= 'console.logger(tolog);} ';
    $silencer .= '}</script>';
    return $silencer;

// for the frontend, use script_loader_tag filter
add_filter('script_loader_tag','jquery_migrate_load_silencer', 10, 2);
function jquery_migrate_load_silencer($tag, $handle) {
    if ($handle == 'jquery-migrate') {
        $silencer = jquery_migrate_silencer();
        // prepend to jquery migrate loading
        $tag = $silencer.$tag;
    return $tag;

// for the admin, hook to admin_print_scripts
function jquery_migrate_echo_silencer() {echo jquery_migrate_silencer();}

The result is a one line of HTML script added to both frontend and backend that achieves the desired effect (prevents the installed message.)

  • 2
    +1 for the idea, but if it is your site, it is probably better to just make sure all your scripts are compatible to the latest version and remove the migrator ;) Apr 25, 2016 at 9:11
  • yes but I just don't agree with removing the migrator as a practice at all because it doesn't take into account installing themes/plugins which may not be compatible with the latest jQuery yet. as a parrallel there are plenty of plugins that still work fine even though they may not have realized a WordPress function here or there is "officially" deprecated. backwards compatibility is prevention and better than a cure when it comes to both cases and well, software in general.
    – majick
    Apr 25, 2016 at 9:18
  • 2
    You are right, but not supporting the latest jquery version is a bug IMO. 4.5 went into RC about a month ago, and if code wasn't tested to work with all the changes it introduced, then the theme/plugin are not truly compatible. In the world outside wordpress deprecation messages turn into actual deprecation at some point, and you don't want to leave handling them to the time where you have to upgrade ASAP. The migrator IMO should be a temporary solution, not a permanent feature. Apr 25, 2016 at 9:29
  • 2
    I disagree on principals here, the internet is a fast moving target and the landscape is changing all the time. (by the time it took to get the site logo feature to 4.5 for example, sites had move on from the idea of having only one logo). Old is good only when applied to very specific and stable niches but jQuery for example is know to be a relatively moving target. Apr 25, 2016 at 9:46
  • 1
    A theme is not an isolated product. If a theme was packaging wordpress and jquery etc, then the age of the theme would have been totally relevant. As no theme does that, if the theme was not tested against the version of wordpress being used, then it is not clear enough what kind of bugs will be discovered. This is just another manifestation of the static vs dynamic linking dilemma. In a static linking world your claim is mostly true, but wordpress is dynamic linking and just because something had worked with 3.5 do not mean it will work with 4.5 even with the attempt to be backcompatible Apr 25, 2016 at 10:54

Just a little test here.

I peeked into jquery-migrate.js and noticed this part:

// Set to true to prevent console output; migrateWarnings still maintained
// jQuery.migrateMute = false;

so I tested the following with the newly wp_add_inline_script(), introduced in version 4.5:

add_action( 'wp_enqueue_scripts', function()
        'jquery-migrate', 'jQuery.migrateMute = true;',
} );

This will change:

JQMIGRATE: Migrate is installed with logging active, version 1.4.0


JQMIGRATE: Migrate is installed, version 1.4.0

So it doesn't actually prevent all console output, like this part in jquery-migrate.js:

// Show a message on the console so devs know we're active
if ( window.console && window.console.log ) {
    window.console.log( "JQMIGRATE: Migrate is installed" +
        ( jQuery.migrateMute ? "" : " with logging active" ) +
        ", version " + jQuery.migrateVersion );
  • 1
    So the bottom code just removes the message, right? I mean, the migrate stays but the message is supressed, right? This is better than removing the migrate definitely
    – dingo_d
    Apr 25, 2016 at 9:47
  • 1
    no, that is a copy of the code producing the console log message that does output. it shows that migrateMute is only tested for the second half of the console message - the first half is output regardless... removing this code block will remove the console message, but you would need to redo that each WP update.
    – majick
    Apr 25, 2016 at 9:56
  • 2
    Thanks for the research and details! IMO the best option, since removing JQmigrate is not always a good idea, because many WP plugins depend on deprecated jQuery functions. This solution helps to clean up the console output a bit!
    – Philipp
    Apr 28, 2017 at 17:39
  • 1
    If you also want to remove them in the admin, you can give the anonymous function a name, and call it on both wp_enqueue_scripts and admin_enqueue_scripts.
    – Ian Dunn
    Jan 28, 2021 at 17:23
  • Thanks for the additional info @IanDunn
    – birgire
    Jan 28, 2021 at 23:20


add this to functions.php:

function remove_jquery_migrate_notice() {
    $m= $GLOBALS['wp_scripts']->registered['jquery-migrate'];
    $m->extra['before'][]='temp_jm_logconsole = window.console.log; window.console.log=null;';
add_action( 'init', 'remove_jquery_migrate_notice', 5 );

It works when jquery-migrate is called with standard hook (which outputs <link rel=stylesheet....>) and not with load-scripts.php in bulk (like in admin-dashboard).

  • 2
    This works fine for me. Thank you!
    – Didierh
    Jan 31, 2020 at 22:21

Just modify your Inspector Console when needed

Instead of hardcoding anything in your website, most inspectors give you method to edit the console output locally.

For Chrome and Opera

Using inspector console you can right click on the JQMIGRATE ... Warning and click 'Hide messages from jquery-migrate.js'.

Console Filter

This will add '-url:<YOUR_WORDPRESS_URL>/wp-includes/js/jquery/jquery-migrate.js?ver=3.3.2' to the console filter. Effectively subtracting this url from the console output.

Note: if you copying the above to the filters change out <YOUR_WORDPRESS_URL> for your wp url

This console filter is persistently applied to new tabs and windows as well.


For Safari you can create an inspector Response Local Override pretty easily.

Right click on the jquery-migrate.js:line to the right of the console log outputs, then select 'Create Response Local Override'.

Which means you edit the file locally for dev purposes. So to remove these migrate notices add this to the top of the jquery-migrate.js file in your Response Local Override.

 * Response Local Override
jQuery.migrateMute = true;


Local overrides not supported currently. https://support.mozilla.org/en-US/questions/1331771

Tab/Window Based Filter Console output

type -jquery-migrate.js into the 'Filter Output' bar and Jquery migrate notices will disappear even on reload of tab.

Caveat: this console filter will need to be applied each time you open a new firefox tab or window.

Hope this helps!


Had the same problem, and found out you just need to set SCRIPT_DEBUG to false in your wp-config.php. Hope this helps someone

  • 3
    That did not work for me.
    – Serj Sagan
    Oct 4, 2018 at 8:19
  • This absolutely does not work. Enabling it to true will show which errors/logs will make it into the console, just in case someone is curious.
    – alphazwest
    Mar 10, 2022 at 22:48


This comment from here:

Here's something that disables all the console.trace-ing:

function _jqmigrate_mute() {
  wp_add_inline_script('jquery-migrate', 'jQuery.migrateMute = true;', 'before');
add_action('wp_enqueue_scripts', '_jqmigrate_mute');
add_action('admin_enqueue_scripts', '_jqmigrate_mute');

It doesn't silence the initial announcement, but it saves a heck of a lot of space otherwise.

Not the answer you're looking for? Browse other questions tagged or ask your own question.