#37110 closed task (blessed) (fixed)
Update to jQuery 3.*
Reported by: | jorbin | Owned by: | SergeyBiryukov |
---|---|---|---|
Milestone: | 5.6 | Priority: | normal |
Severity: | critical | Version: | |
Component: | External Libraries | Keywords: | early has-patch needs-testing needs-screenshots has-dev-note |
Focuses: | javascript | Cc: |
Description
jQuery 3.0 has been released. There are a number of breaking changes and the browser minimums have been updated, so we need to figure out how to handle the update as it won't be the normal straight forward update.
Attachments (15)
Change History (228)
#3
in reply to:
↑ 2
@
8 years ago
Replying to ocean90:
Previously: #24132
The biggest difference between 2.0 and 3.0 and why I think the decision should be different is that 1.x and 2.x were both actively developed while 3.0 is the only actively developed version now. To quote the jQuery 3.0 release post "While the 1.12 and 2.2 branches will continue to receive critical support patches for a time, they will not get any new features or major revisions. jQuery 3.0 is the future of jQuery."
This ticket was mentioned in Slack in #core-customize by helen. View the logs.
8 years ago
#7
@
8 years ago
Any chance someone will make a decision in this before 4.8? The benefits of the newer version of jQuery outweigh waiting on a security updates only version of the library.
#9
@
7 years ago
- Keywords needs-patch added
- Milestone changed from Future Release to 4.9
Is this something someone wants to own for 4.9?
It seems the jquery-migrate plugin has been updated to preserve pre-3.0 behaviors to eliminate or at least minimize breaking changes. Upgrading to jQuery 3.x would involve upgrading jquery-migrate, as well as potentially updating core usage of jQuery to make use of 3.x aspects once to lessen any notice that would be raised.
I'll milestone it to 4.9 for now, but it depends on a contributor to own it. Liable to punt to future release at any time.
#10
@
7 years ago
- Keywords early added
In any case, it will need to be committed early
in a release cycle to give it time to bake. That would mean in the next couple weeks.
#11
@
7 years ago
- Keywords has-patch needs-testing added; needs-patch removed
In 37110.diff:
- Upgrade jQuery to 3.2.1, upgrade jquery-migrate to 3.0.0
#12
@
7 years ago
- Keywords needs-devnote added
When this lands, it should be broadcast loudly.
We also need to remember that core jQuery is included on the frontend of sites and that those may not have dropped support for older versions of IE. If this goes in, we should make sure the themes team and plugins team are notified so that if they need to adjust requirements and recommendations, they can.
We may also want to keep the older version as jquery-legacy
or some other similar name to assist plugins/themes that can't upgrade due to browser support requirements.
#13
@
7 years ago
When this lands, it should be broadcast loudly.
Absolutely!
We may also want to keep the older version as jquery-legacy or some other similar name to assist plugins/themes that can't upgrade due to browser support requirements.
Not sure about this - I wonder how many plugins/themes really need this? What about maintaining the additional file and the increase in the overall package size? How long do we keep it around?
In case we do decide to keep it, here is a patch: 37110.2.diff:
- include current jQuery 1.12.4 with 'jquery-legacy' handle.
#14
@
7 years ago
Note: Seeing some unit test failures that need addressing after this swap: https://travis-ci.org/adamsilverstein/wordpress-develop-fork/jobs/263633261
#15
@
7 years ago
37110.3.diff passes tests and clears some warnings; still seeing many warnings and some items not working correctly in customizer that will require more investigation.
#16
@
7 years ago
Not sure about this - I wonder how many plugins/themes really need this? What about maintaining the additional file and the increase in the overall package size? How long do we keep it around?
In terms of a version, I would say probably start thinking about it for 6.0 at the very earliest. Government sites will still need to support old versions of IE (e.g. The Department of Ed's FAFSA site supports IE 7)
#17
@
7 years ago
Not sure about this - I wonder how many plugins/themes really need this? What about maintaining the additional file and the increase in the overall package size? How long do we keep it around?
If we are worried about package size, as long as we can a place that has the no-conflict by default version, there is precedence for loading from an external site (see: script.aculo.us. )
If we add it, I say we keep it forever.
An alternative could be a core recommended "oldQuery" plugin.
#18
@
7 years ago
- Keywords needs-dev-note added; needs-devnote removed
- Milestone changed from 4.9 to Future Release
Punting as we are entering beta.
#19
follow-up:
↓ 20
@
7 years ago
Since it hasn't yet been mentioned in this ticket... the version of jQuery currently in WordPress core has an XSS vulnerability that is over 6 months old:
#20
in reply to:
↑ 19
;
follow-ups:
↓ 21
↓ 25
@
7 years ago
#22
@
7 years ago
While waiting for this to land in core, there is a plugin (which I've not tested) which upgrades jQuery to 3.2.1 (the current version): https://wordpress.org/plugins/jquery-updater/
I suggest any additional changes made in 37110.3.diff be submitted to the GitHub project for wider testing (there are 40k+ active installs): https://github.com/Ramoonus/jQuery-Updater
This will get a very good base of users to test the jQuery upgrade in core.
#23
@
7 years ago
@westonruter This plugin is a very basic one, most of it's functionality is 2 lines:
wp_deregister_script('jquery');
wp_enqueue_script('jquery', plugins_url('/js/jquery-3.2.1.min.js', __FILE__), false, '3.2.1');
So there's not much to test about it. 2c
#24
@
7 years ago
@Presskopp yes, so that's why I suggest additional improvements in 37110.3.diff be submitted as PRs. In either case, it provides a way to get users to test with jQuery 3 without forcing them to write a plugin.
#25
in reply to:
↑ 20
@
7 years ago
Replying to pento:
That security issue was backported to the jQuery 1 branch (commit), and was released in jQuery 1.12.3. WordPress 4.5 included this update, added in [37164].
That patch seems to have been reverted in jQuery 1.12.4, which is the version WP currently includes.
https://github.com/jquery/jquery/commit/cfe830eefdd7f1e7cb87e9841d1d732d6d99ffae
Also jQuery 1.x and 2.x are officially end of life and no longer receiving patches.
https://github.com/jquery/jquery.com/issues/162
#26
follow-up:
↓ 27
@
7 years ago
Shouldn't this given a higher priority since basically the current version of WordPress (including 4.9 beta) contains an older version of a 3rd party library that has officially been unsupported by the vendor and containing an XSS vulnerability that will not be fixed.
It would also be great for plugin/theme developers since Bootstrap 4 will be requiring jQuery 3 and up.
#27
in reply to:
↑ 26
@
7 years ago
- Keywords needs-screenshots added
- Severity changed from normal to critical
The answer is almost certainly yes but unfortunately WP continues to ship a library with a vulnerability instead of updating it.
Replying to onokazu:
Shouldn't this given a higher priority since basically the current version of WordPress (including 4.9 beta) contains an older version of a 3rd party library that has officially been unsupported by the vendor and containing an XSS vulnerability that will not be fixed.
It would also be great for plugin/theme developers since Bootstrap 4 will be requiring jQuery 3 and up.
This ticket was mentioned in Slack in #core by presskopp. View the logs.
7 years ago
#29
@
7 years ago
Looks like Google is considering WordPress "not best practice" for using a vulnerable library. Just tested my sites with Google Lighthouse and this was flagged and is likely affecting site ranking, albeit slightly.
The severity is "medium", by the way, which is rather scary.
#30
follow-up:
↓ 51
@
7 years ago
37110.4.diff is a build of jQuery with the fix from https://github.com/jquery/jquery/commit/f60729f3903d17917dc351f3ac87794de379b0cc
All unit tests pass: https://travis-ci.org/adamsilverstein/wordpress-develop-fork/builds/299867300
Going to test this out locally, appreciate any additional testing.
This ticket was mentioned in Slack in #themereview by poena. View the logs.
7 years ago
#33
follow-up:
↓ 34
@
7 years ago
I have clients for whom PCI DSS compliance is a requirement, and in their most recent scan they got flagged for the jQuery library in WP Core, with the instruction to upgrade to 3.0.0 or higher, in order to fix CVE 2015-9251 and CVE 2016-10707. Is there any way to fast track this change so that other people with similar requirements don't get stuck?
#34
in reply to:
↑ 33
@
7 years ago
Replying to bigcloudmedia:
I have clients for whom PCI DSS compliance is a requirement, and in their most recent scan they got flagged for the jQuery library in WP Core, with the instruction to upgrade to 3.0.0 or higher, in order to fix CVE 2015-9251 and CVE 2016-10707. Is there any way to fast track this change so that other people with similar requirements don't get stuck?
You might want to implement a plugin that de-registers jquery
in WordPress and re-registers it either with a CDN copy of jQuery v3.x or include a copy with the plugin. That will get them compliant in that regard ASAP.
It is odd to note that there does not seem to be much movement on this issue. @adamsilverstein put out a patch for testing and that was the last thing... 4 months ago.
#36
@
7 years ago
Where can the jQuery core team help with this? Are there things in Wordpress core that require the older jQuery and/or jQuery Migrate? If so can we help with those changes or with testing? Ideally Wordpress would be on jQuery 3+ and not need the Migrate plugin because it introduces behavior that isn't the norm for the version of jQuery being used.
#37
@
7 years ago
@dmethvin Thanks for your offer of help. The biggest thing we can use help with is testing and explaining the changes to developers.
I think the biggest concern preventing this from landing is maintaining backwards compatibility, especially since jQuery is often enqueued on the front end as @jorbin pointed out. Nevertheless, WordPress 5.0 will already be our biggest breaking change ever, and updating jQuery at the same time makes sense to me. I'm going to refresh this patch with the latest version of jQuery and hopefully land this soon in trunk.
#38
@
7 years ago
37110.5.diff includes the latest jquery and jquery migrate (plus other changes from 37110.3.diff - some tests are failing, I'll work on getting those fixed.
This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.
7 years ago
This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.
7 years ago
#41
@
7 years ago
37110.5.diff - update jquery & jquery ui versions in packages.json since we now have a build process for these files
This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.
7 years ago
#43
@
6 years ago
Hi Adam,
I think that
wp.customize.on( 'ready', function() {
in customize-controls.js should be
$(wp.customize).ready( function() {
The .on( "ready", fn)
seems to have been removed from jQuery 3.0: https://jquery.com/upgrade-guide/3.0/#breaking-change-on-quot-ready-quot-fn-removed
#44
@
6 years ago
Also, you don't need to change it in src/wp-admin/includes/class-wp-internal-pointers.php
on line 140
#45
follow-up:
↓ 46
@
6 years ago
in 37110.9.diff i started from scratch - three tests are still failing; see https://travis-ci.org/adamsilverstein/wordpress-develop-fork/jobs/392319225
#46
in reply to:
↑ 45
@
6 years ago
Replying to adamsilverstein:
in 37110.9.diff i started from scratch - three tests are still failing; see https://travis-ci.org/adamsilverstein/wordpress-develop-fork/jobs/392319225
I didn't get any QUnit errors testing 37110.9.diff locally.
#47
@
6 years ago
37110.10.diff includes only the upgrade on jquery and jquery migrate. after installing this patch (and running npm install && npm build), the only notable failure is the customizer menus section, which fails to properly load the 'add new' panel.
### Steps to reproduce
- open customizer->menus->add new
- note that the panel opens but is blank, the fields to add the new menu are missing
other sections of the customizer work fine, adding menus on the regular screen works fine. other customizer sections work fine. I do see some qunit test failing as well: https://travis-ci.org/adamsilverstein/wordpress-develop-fork/jobs/393334653
i have spent many hours trying to track down what is failing to initialize but have yet to discover the underlying cause. given jquery migrate, i would have expected warnings but no errors/failures. I do see many migrate warnings and have handled these in another branch, but none of these changes fixed the menus issue.
My hunch is that the failure is due to changes in the way jQuery implements Promises and the ready event, although there are numerous breaking changes I have searched thru the codebase for usagees without any success: https://jquery.com/upgrade-guide/3.0/#breaking-change-document-ready-handlers-are-now-asynchronous
@westonruter when you have a chance, can you test this patch out and see if anything pops out as a possible cause for the issue? Thanks in advance!
This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.
6 years ago
#49
@
6 years ago
What little progress I may have made is in 37110.11.diff:
- Update versions in
script-loader.php
- Introduce
wp.customize.ready()
for providing an interface to boot the controls logic atDOMContentLoaded
. - Switch from
jQuery(window).load()
tojQuery(window).on('load')
in tests.
The issue with nav menus is not fixed still. Also, there are 4 failing QUnit assertions still, including tests for:
- Dynamically-created Customizer Control Model: Associating a control with a section allows it to be embedded
- Customize Sections: wp.customize.OuterSection: Test OuterSection
- Customize Nav Menus: changing a MenuNameControl change the corresponding menu value
#51
in reply to:
↑ 30
@
6 years ago
Replying to adamsilverstein:
37110.4.diff is a build of jQuery with the fix from https://github.com/jquery/jquery/commit/f60729f3903d17917dc351f3ac87794de379b0cc
All unit tests pass: https://travis-ci.org/adamsilverstein/wordpress-develop-fork/builds/299867300
Going to test this out locally, appreciate any additional testing.
Adam, is this in the current 4.x build of Wordpress or is this something for 5.0?
#53
in reply to:
↑ 52
@
6 years ago
Replying to Presskopp:
@markgoho Milestone is 'Future Release' - smells like 5.0
Ahh good call, I was having trouble figuring out where this patch had been applied.
So, to summarize: 4.x is still shipping with the insecure version of jQuery.
#54
@
6 years ago
@adamsilverstein @westonruter Sorry I haven't checked in for a while but I'd love to help you track this down. What's the fastest way to test this, assuming I don't have a local Wordpress setup right now?
#55
follow-up:
↓ 57
@
6 years ago
@dmethvin Thank you for your interest in contributing here.
At this point since we haven't merged to core you need to get a setup locally that lets you apply the latest patch uploaded to this ticket.
This is hopefully still a good place to start: https://developer.wordpress.org/themes/getting-started/setting-up-a-development-environment/ and I also know products like "Local by Flywheel" aim to make spinning up local WordPress installs painless.
Once you have a local setup, here are some instructions on testing a patch: https://make.wordpress.org/core/handbook/testing/patch/
Let me know if you have any trouble or further questions.
#56
@
6 years ago
@markgoho -
To summarize, we are still working on getting WordPress ready for jQuery 3 - ensuring the upgrade doesn't break core and also letting developers know how to upgrade their own code - help greatly appreciated!
#57
in reply to:
↑ 55
;
follow-up:
↓ 62
@
6 years ago
Hey Adam, I've had no problems getting the production WordPress 4.9.7 installed, but cloning the dev repo at https://develop.svn.wordpress.org/ has taken more than 24 hours via git svn
and from what I could gather from the docs this was the first step. Is there a better way to get a testing env set up? I got stuck on https://make.wordpress.org/core/handbook/testing/beta/ . This is on Windows BTW.
#58
@
6 years ago
@dmethvin If you're just wanting to test out a patch (rather than wanting to set up a Git repo with full history that tracks the SVN repo), then you should just do an ordinary SVN checkout; or, download the nightly zip: https://wordpress.org/nightly-builds/wordpress-latest.zip
This ticket was mentioned in Slack in #forums by jcastaneda. View the logs.
6 years ago
#60
@
6 years ago
I appreciation that an an update to jquery 3 is challenging, especially when considering plugin support as well.
Given that. is it worth splitting out a separate ticket covering a mitigation for the exploit from https://github.com/jquery/jquery/issues/2432 and leave this one to cover the full query update.
It appears that @adamsilverstein has produced something for the mitigation in comment:30
FWIW this is the approach that was taken for Drupal 7 ( and backported to D6 via the lts program)
#61
@
6 years ago
Wondering if it would be possible to ship the new versions of jQuery/UI on a new script handle? jquery3
?
then continue by getting the default themes to use the new version if they use jQuery. Then we can patch the older version and continue using it in wp-admin until we can upgrade or deprecate its use entirely. What happens when a page enqueues old and new versions or how do we handle that?
#62
in reply to:
↑ 57
@
6 years ago
Replying to dmethvin:
cloning the dev repo [...] has taken more than 24 hours via
git svn
I'm guessing you've worked around that by now, but for anyone else who runs into the same problem, the best way is probably to use the Git mirror directly:
git clone git://develop.git.wordpress.org/
...or the unsupported GitHub mirrror at https://github.com/WordPress/wordpress-develop
If you prefer git-svn
, though, then the log-window-size
param will speed things up a lot:
git svn clone https://develop.svn.wordpress.org/ --log-window-size=50000
It's still fairly slow, though, that's just the nature of git svn clone
.
#64
@
6 years ago
Guys, if we upgrade to jQuery 3, we should also do this in the footer or in the header with defer.
Using document ready is necessary for this in your scripts. See my error report: https://core.trac.wordpress.org/ticket/45130
//I don't know what the difference is between jQuery.noConflict(); and $.noConflict(); jQuery(function( $ ) { // $ Works! You can test it with next line if you like // console.log($); });
See: https://api.jquery.com/ready/ and https://api.jquery.com/jquery.noconflict/
Edit: I made a WP plugin to deal with these problems in the short term: https://wordpress.org/plugins/jquery-manager/ and GitHub repo: https://github.com/Remzi1993/jquery-manager
This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.
6 years ago
#69
@
6 years ago
I have witnessed a malware in a jquery.js file a few days ago, on a website that uses Wordpress. The installation was up-to-date, on the 4.x branch. This malware is believed to have allowed the attacker to steal credit card and personal information.
The original attack vector, which allowed this malware to be here, probably wasn't JQuery. However, it shows us how damaging a hole in this library is : the attacker has access to everything the user does. Because it is loaded in every Wordpress page.
I understand this is not an easy fix, but I believe security should have priority over backward plugin compatibility.
This ticket was mentioned in Slack in #core by jorbin. View the logs.
6 years ago
This ticket was mentioned in Slack in #core by clorith. View the logs.
6 years ago
#73
@
5 years ago
Is this still being worked on? I mean don't get me wrong this ticket is already 3 years.
I'm just a little bit worried. I know there is lot to do, but it seems to me that this is a important switch, because officially jQuery 1.x and 2.x are not supported anymore.
EDIT:
I think if this needs to be implemented in a backward compatibel way. It could be done like the image below:
#74
follow-up:
↓ 75
@
5 years ago
Trustwave, who certifies my PCI status, has been failing me for a few months now due to this old version of jquery:
jQuery Cross-Domain Asynchronous JavaScript and Extensible Markup Language Request Cross-site Scripting Vulnerability
https://www.evernote.com/l/AAE9aSM1l_1FTak5HMGPKnXFcC6kk4-Pl6I
#75
in reply to:
↑ 74
@
5 years ago
Replying to kevindaum:
Trustwave, who certifies my PCI status, has been failing me for a few months now due to this old version of jquery:
jQuery Cross-Domain Asynchronous JavaScript and Extensible Markup Language Request Cross-site Scripting Vulnerability
https://www.evernote.com/l/AAE9aSM1l_1FTak5HMGPKnXFcC6kk4-Pl6I
I've been dealing with similar issues from ControlScan. Here's a bit that fixes the XSS hole:
<?php function bcm_jquery_security_fix() { $js_path = str_replace('index.php', 'js', __FILE__); $js_url = str_replace( ABSPATH, get_bloginfo('url').'/', $js_path); wp_register_script( 'pci_security_fix', $js_url.'/security_fix.js', array('jquery') ); wp_enqueue_script('bcm_enm_pci_security_fix'); } add_action('wp_enqueue_scripts', 'bcm_jquery_security_fix');
// security_fix.js content // Prevent auto-execution of scripts when no explicit dataType was provided (See gh-2432) jQuery.ajaxPrefilter( function( s ) { if ( s.crossDomain ) { s.contents.script = false; } });
To finish appeasing the scanners I also had to use jQuery Updater (https://wordpress.org/plugins/jquery-updater/) and write a supplementary plugin that deregistered the jQuery UI components and re-registered the latest version of it:
<?php function bcm_jquery_updater() { if (!is_admin()) { // Deregister UI jQuery wp_deregister_script('jquery-ui-core'); wp_deregister_script('jquery-ui-widget'); wp_deregister_script('jquery-ui-mouse'); wp_deregister_script('jquery-ui-draggable'); wp_deregister_script('jquery-ui-slider'); wp_deregister_script('jquery-touch-punch'); wp_deregister_script('iris'); // Register wp_enqueue_script('jquery-ui-core', plugins_url('/js/jquery-ui-1.12.1.min.js', __FILE__), false, '1.12.1'); wp_enqueue_script('iris', get_bloginfo('url').'/wp-admin/js/iris.min.js', 'jquery-ui-core'); } } add_action('wp_enqueue_scripts', 'bcm_jquery_updater');
This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.
5 years ago
This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.
5 years ago
#78
follow-up:
↓ 79
@
5 years ago
Anybody working / assigned on this ?
Seriously, you should focus more on SECURITY and PCI compliance (especially for WooCommerce websites).
All our audited websites FAIL to comply with PCI / GDPR because of a single js file. (high velnerability risk) really ?
High candy and whistles is fun (aka Gutenberg), but hackable websites less, this issue has been reported 3 years ago now and still no fixes.
#79
in reply to:
↑ 78
;
follow-up:
↓ 81
@
5 years ago
Replying to jacklinkers:
Anybody working / assigned on this ?
Seriously, you should focus more on SECURITY and PCI compliance (especially for WooCommerce websites).
All our audited websites FAIL to comply with PCI / GDPR because of a single js file. (high velnerability risk) really ?
High candy and whistles is fun (aka Gutenberg), but hackable websites less, this issue has been reported 3 years ago now and still no fixes.
Hi @jacklinkers @kevindaum @bigcloudmedia
In the meantime everybody who needs a specific version of jQuery could use the plugin I made: https://wordpress.org/plugins/jquery-manager/
I understand that this is not the optimal solution. I think it's difficult to switch for the WP team, because there are so many plugins who may rely on version 1.x of jQuery.
But eventually I think WP needs to set an deadline, move on and abbonden old plugins. This is my personal opinion.
This ticket was mentioned in Slack in #core by jacklinkers. View the logs.
5 years ago
#81
in reply to:
↑ 79
@
5 years ago
@remzicavdar Thanks, but my question is security related. Adding an external plugin on top which increases risks is not an option (regardless your coding skills / code quality standards / compliance).
There is 2 well known critical security breaches in v1.12 (I will not publish here), which prevent PCI-DSS compliance (hundreds websites get hacked with everyday).
I agree with you, an EOL should have been put in place, there is no point holding / forcing other users to stick with outdated library (not talking in days, weeks, or months, but several years !!!) because of compat with crappy plugins it might break.
Look at HTTPS it's a common standard now. Search engines ignore not secured websites. Look at QUIC / HTTP/3 which will secure by default communications, look at Bootstrap 5 which will drop completely jQuery...
Stick to v1.12 fails on every industry standard
#82
@
5 years ago
Hi @jacklinkers
You're right about adding a plugin, but I think this is different when you're able to see the source code. The plugin is completely open source: https://github.com/Remzi1993/jquery-manager and https://wordpress.org/plugins/jquery-manager/
I take security very seriously, that's why we made a WP plugin at my previous job/company and decided to make this open source, so others are also able to benefit. Other devs have also contributed to the code and even someone has patched older versions of jQuery.
I hope you're able to change/patch jQuery by yourself or you could use some code from the plugin yourself.
See example code:
<?php // Front-end not excuted in the wp admin and the wp customizer (for compatibility reasons) // See: https://core.trac.wordpress.org/ticket/45130 and https://core.trac.wordpress.org/ticket/37110 function wp_jquery_manager_plugin_front_end_scripts() { $wp_admin = is_admin(); $wp_customizer = is_customize_preview(); // jQuery if ( $wp_admin || $wp_customizer ) { // echo 'We are in the WP Admin or in the WP Customizer'; return; } else { // Deregister WP core jQuery, see https://github.com/Remzi1993/wp-jquery-manager/issues/2 and https://github.com/WordPress/WordPress/blob/91da29d9afaa664eb84e1261ebb916b18a362aa9/wp-includes/script-loader.php#L226 wp_deregister_script( 'jquery' ); // the jquery handle is just an alias to load jquery-core with jquery-migrate // Deregister WP jQuery wp_deregister_script( 'jquery-core' ); // Deregister WP jQuery Migrate wp_deregister_script( 'jquery-migrate' ); // Register jQuery in the head wp_register_script( 'jquery-core', 'https://code.jquery.com/jquery-3.3.1.min.js', array(), null, false ); /** * Register jquery using jquery-core as a dependency, so other scripts could use the jquery handle * see https://wordpress.stackexchange.com/questions/283828/wp-register-script-multiple-identifiers * We first register the script and afther that we enqueue it, see why: * https://wordpress.stackexchange.com/questions/82490/when-should-i-use-wp-register-script-with-wp-enqueue-script-vs-just-wp-enque * https://stackoverflow.com/questions/39653993/what-is-diffrence-between-wp-enqueue-script-and-wp-register-script */ wp_register_script( 'jquery', false, array( 'jquery-core' ), null, false ); wp_enqueue_script( 'jquery' ); } } add_action( 'wp_enqueue_scripts', 'wp_jquery_manager_plugin_front_end_scripts' ); function add_jquery_attributes( $tag, $handle ) { if ( 'jquery-core' === $handle ) { return str_replace( "type='text/javascript'", "type='text/javascript' integrity='sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=' crossorigin='anonymous'", $tag ); } return $tag; } add_filter( 'script_loader_tag', 'add_jquery_attributes', 10, 2 );
This ticket was mentioned in Slack in #core by clorith. View the logs.
5 years ago
This ticket was mentioned in Slack in #core by ipstenu. View the logs.
5 years ago
#85
@
5 years ago
Can the jQuery security vulnerabilities in WordPress be fixed, please?
This thread has also been open for 4 years.
One vulnerability (identified as CVE-2019-11358) can allow people to assign themselves administrator privileges in a web application if they are using the old jQuery library code. This is a huge problem!!!!!!
It doesn't matter which edited version of jQuery WordPress has in it but if you know there are security risks and just load the standard version onto every website it's not good. Even Google drops website rankings because of this. This should warrant an urgent update. Also, why is it being left on purposes when there is even code on this page that gives users an option to select the old version if they have trouble? Linking to version 1.x or 2.x now is just not right. WordPress users should get warnings if the old versions are used but they should also be allowed to choose an older version if they like at their own risk. As new code that breaks websites is also not a cool option. Linking to the old code with vulnerabilities is also another reason why recently the number of hacked sites has started going up.
I manually edit out the security problem by deregistered it and load the latest version on all my websites. It's easy to do but took me a while to find out how to do it. This is not the biggest problem though. The plugin developers tell me they will not update their code either as they say the WordPress guidelines tell them they have to connect to the built-in code in WordPress!!!!! How do you expect people to start using the new version of jQuery if the guidelines tell them they must link to the old version in WordPress?
About a year ago, someone hacked one of my sites and I learned my lesson the hard way. I lost my top page position in Google (number 2) for 3 days because a hacker linked my site to a site that tried to infect computers. It also took about 3 months to completely recover and get a good spot on the top page again after the damage. It was almost impossible to go through all the code that had been added but I'm lucky I had backups of everything. I could just replace the whole site. This website had scrambled usernames and email addresses in it but I'm lucky the data wasn't stolen at the time.
If it's okay, can you please get at least one or two programmers to just add the code from the guy above to the core if it's nice programming? He has given you the code for free and it almost takes no effort to release a version where even a low-level user can choose an old version if they want to, also if their website is broken somehow. This WordPress update would even promote the updating plugins with the vulnerabilities. A jQuery compatibility filter could be added to the plugin repository so we know which plugins work. I could even update the website for free if needed, to help out.
Sorry for the super long message here but I think this has become a serious problem.
Regards,
Glen
expresstechsupport (@expresstechsupport)
3 hours, 10 minutes ago
Hi,
As per WordPress.org regulations, we must use WordPress included jQuery. We cannot be de-registering it and loading jQuery from other resources.
#86
@
5 years ago
Here's a thought: WordPress now pushes users to a minimum PHP version and plugins like Yoast SEO only support the last 2 versions of WordPress.
Why not do the same with front-end scripting languages used in core?
Perhaps Site Health can help facilitate this, but it'll also help to note which version of jQuery is required for plugins and themes in the repository and make authors consider moving forward.
#87
@
5 years ago
Wow, I just became aware of this.... four years are a lot. jQuery 1.12.4 is what is still currently included in core, which is ages old AND vulnerable to XSS --> even online tools like lighthouse will bring that up...
#88
follow-up:
↓ 89
@
5 years ago
Is there a way to show which plugins are running old versions and get recommendations for updates in the plugin area?
#89
in reply to:
↑ 88
@
5 years ago
Replying to a4jp.com:
Is there a way to show which plugins are running old versions and get recommendations for updates in the plugin area?
I doubt, but since my last incursion, I did more research and found a very interesting post :
https://wordpress.stackexchange.com/questions/244537/why-does-wordpress-use-outdated-jquery-v1-12-4/244543
While this doesn't solve the problem, it answered lot of questions I had.
On the other hand, it drives me nuts, I mean who cares about supporting EOL and unsecure stuff but WordPress? I guess it's their contribution to worldwide accessibility. Well, it has its limits.
For example, all clients we host know that we allow only a specific SSL CYPHER suit which will prevent old browsers (aka Nokia 6110 mobile owners still browsing the web with) to access their website for security reasons.
Some might care, some not, it's the way it is. But at the same time, we don't plan to host every website on the planet like WordPress would like to "Power" every website.
#90
follow-up:
↓ 91
@
5 years ago
Maybe there is another direction here.
As per the StackExchange page provided by @jacklinkers , PageSpeed/Lighthouse look at Snyk.io for vulnerability advice. Unfortunately, https://snyk.io/test/npm/jquery/1.12.4 does list a couple of issues.
However, if the version really is clean, as claimed on StackExchange, it's just a matter of letting Snyk.io know. If anyone reading this ticket feels confident enough about this, please contact them.
#91
in reply to:
↑ 90
;
follow-up:
↓ 92
@
5 years ago
Replying to galbaras:
Maybe there is another direction here.
As per the StackExchange page provided by @jacklinkers , PageSpeed/Lighthouse look at Snyk.io for vulnerability advice. Unfortunately, https://snyk.io/test/npm/jquery/1.12.4 does list a couple of issues.
However, if the version really is clean, as claimed on StackExchange, it's just a matter of letting Snyk.io know. If anyone reading this ticket feels confident enough about this, please contact them.
Speaking from experience having had to deal with PCI certification for customers running WooCommerce stores, this issue is a *constant* thorn in our side. The scanning vendors pick up that you have an old version installed, and sometimes they decide that they don't like your existing mitigation strategy anymore.
The first couple times it came up I was able to point out that it's in WordPress Core, and that I had an inherent business need to be running WordPress, and was able to get a waiver for certification.
When I last commented on this thread seven months ago I was working with the same scanning vendor, but they decided that simply needing to use WordPress was no longer an acceptable reason for having an old version of jQuery and forced me to deregister it from all places and re-register the latest version, then provide proof that there was no trace of the old version that was active.
Seriously, this is becoming a major problem, and it's only getting worse the longer we take to rip the band-aid off. If we can have freaking Gutenberg forced on us against our will (in spite of how it upends well-known and established workflows in WordPress), there's no excuse why this hasn't been done yet.
#92
in reply to:
↑ 91
;
follow-up:
↓ 94
@
5 years ago
Replying to bigcloudmedia:
Seriously, this is becoming a major problem, and it's only getting worse the longer we take to rip the band-aid off. If we can have freaking Gutenberg forced on us against our will (in spite of how it upends well-known and established workflows in WordPress), there's no excuse why this hasn't been done yet.
Well said. And don't forget the push to upgrading PHP, and major plugins now supporting only the last 2 major versions of WordPress.
In yet another direction, by the way, is there no way to plug the (apparent) security holes in 1.12.4? What about a custom WordPress-only jQuery version that doesn't have these issues?
#93
@
5 years ago
BTW, not the most ideal solution, but if WordPress is somehow able to remove the string "1.12.4" from the url, that will remove most of the red flags from automated scanners. It only hides the problem but would make a lot of people happy!
#95
@
5 years ago
@SergeyBiryukov In that case, why not change the version number INSIDE the script files (jQuery + Migrate)? I think this is where Lighthouse is looking, because it displays the vulnerability notice even when the "-wp" version is shown in the script URL.
This can be a super quick fix, while keeping things real, because there's not more vulnerability.
#96
@
5 years ago
I've had other scanning vendors pick up on some of the XSS vulnerabilities and other known issues with old jQuery versions while doing the scans. Not everyone simply checks the version number.
Seriously, we need to stop figuring out how to cheat the emissions test and actually bring this software into compliance. It's already a headache for those of us who are required to certify, and these non-solution band-aids to avoid actually properly doing the upgrade that should have been done years ago are not going to alleviate anything.
Let's fix this right, sort out the fallout from it, and move past it already.
#97
@
5 years ago
It’s really unacceptable that jquery continues to be outdated in core. Plugin developers being unwilling to update their plugin should not be an excuse.
This project literally shoved block editor down developers throats before they were ready.
#99
follow-up:
↓ 102
@
5 years ago
It would be better to use Vanilla JS in wordpress core and then feel free to do whatever developers want to load jquery 3.0 or not to use jquery depending on developers' intentions. Please remove Jquery in WordPress core and move to Vanilla JS. This is the development trend not to use Jquery, but Wordpress.
#100
@
5 years ago
Lighthouse reports:
Library Version Vulnerability Count Highest Severity jQuery@1.12.4 2 Medium jQuery UI@1.11.4 1 High
We're getting penalized for something that should have been done in core a long time ago.
#101
@
5 years ago
SVG files can be sanitized easily so I can't see why JQuery file can't get the same treatment. I was told SVG files don't get support because of security problems but JQuery files with actual security problems have been left in WordPress for so long. The iOS app developers also just say SVG files are too dangerous instead of making them viewable :/ Why the double standards? Can't both problem be fixed this time?
#102
in reply to:
↑ 99
@
5 years ago
Replying to stokim2012:
It would be better to use Vanilla JS in wordpress core and then feel free to do whatever developers want to load jquery 3.0 or not to use jquery depending on developers' intentions. Please remove Jquery in WordPress core and move to Vanilla JS. This is the development trend not to use Jquery, but WordPress.
Completely agree. There's really no reason to use jQuery in this day and age, especially when it's such a heavy library being included on the front-end part of the site as well. See http://youmightnotneedjquery.com/ and https://css-tricks.com/now-ever-might-not-need-jquery/ to really determine if it's necessary; I'd hazard a guess that it's not.
#103
@
5 years ago
are CVE-2015-9251 and CVE-2019-11358 actually backported in wordpress core js version 1.12.4? This will always be a scanning problem in all wordpress if not fixed. For now, how can we fix the vulnerability without being affected by future wordpress core updates?
#105
@
5 years ago
This has been a long time coming, and the longer the delay, the harder it gets. Looking at https://jquery.com/upgrade-guide/3.0/#jquery-migrate-plugin the recommended steps are:
- Disable jQuery Migrate 1.x.
- Update to jQuery 3.x and jQuery Migrate 3.x.
- Disable jQuery Migrate 3.x.
Seems that for best results each step should be in a separate release. It will take three WP releases to complete the update.
For back-compat there could be a (bundled?) plugin that will revert jQuery to 1.12.4 in order to "unbreak" sites that experience problems. This is far from ideal, but having an official plugin is better.
Thinking the update process can be started in WP 5.5 by disabling jQuery Migrate 1.x and moving it to a plugin. This may break a few old sites but generally should be quite safe.
Then the "big push" would be in WP 5.6 where *everybody* using WP should hear that they need to test their site with the updated jQuery. To be able to do this we'll make another testing plugin that replaces jQuery and jQuery UI with the latest versions.
#106
@
5 years ago
First of all, every major framework is dropping jQuery in favor of vanilla JS
https://github.blog/2018-09-06-removing-jquery-from-github-frontend/
https://github.com/twbs/bootstrap/pull/23586
List is endless
If jQuery is "mandatory", it should be moved as an selectionnable option, like a drop down where you can select the desired version.
@remzicavdar had an interesting approach with his plugin you can take inspiration from.
#107
@
5 years ago
We seem to be going around in circles, so perhaps we should first get a consensus on the direction, i.e. native JS or latest jQuery.
Either way, that decision should then result in a huge push for plugin and theme authors to conform.
Until the transition has ended, the default should be backward compatible, with core functions for letting WordPress know that jQuery is not required at all (perhaps via add_theme_support( 'native-js' )
and/or a new add_plugin_support( 'plugin-slug', 'native-js' )
function).
Support for 'native-js' by the theme and all the registered plugins should cause WordPress to dequeue the old jQuery+Migrate (and remove them as dependencies?).
Another option can be for 'jquery-3' support instead.
If at least one theme/plugin supports 'jquery-3', while the rest support 'native-js', WordPress should then dequeue the old jQuery+Migrate and enqueue the new ones instead (and replace the respective dependencies).
#108
follow-up:
↓ 109
@
5 years ago
I think @azaozz has the right idea here. If it's going to be kept, the only long-term solution is to keep it up-to-date.
As far as per-plugin solutions are concerned, that's going to cause conflicts the moment you have two plugins that don't agree on a version. It's best to have WordPress Core managing a resource like that so that developers can count on a specific version and feature set, rather than significantly increasing everyone's risk that plugins will be incompatible with each other (especially when new versions come out and early-adopting plugin developers throw a new version in the mix that might not be compatible with the "established" version in some manner).
#109
in reply to:
↑ 108
@
5 years ago
If this wasn't clear, my suggestion was to use the old jQuery+Migrate by default while plugin/theme authors are preparing, and perhaps switch to the opposite approach at a certain point in time.
@azaozz suggested a migration path to latest jQuery, and his approach fits that direction, but others have suggested native JS instead, and personally, I think it's a far more sustainable path to take.
Either way, my suggestion is complementary.
#110
@
5 years ago
If jQuery is "mandatory", it should be moved as an selectionnable option...
with core functions for letting WordPress know that jQuery is not required at all (perhaps via add_theme_support( 'native-js' )
...
Support for 'native-js' by the theme and all the registered plugins should cause WordPress to dequeue the old jQuery+Migrate (and remove them as dependencies?).
This is not how dependencies work. WP lists all available scripts (added by default and added by themes and plugins). Then the enqueued scripts "declare" what dependencies they need. If none of the enqueued scripts depends on jQuery, it will not be loaded. In some cases, like on many wp-admin screens, jQuery may be enqueued directly when there are inline scripts that need it.
every major framework is dropping jQuery in favor of vanilla JS
perhaps we should first get a consensus on the direction, i.e. native JS or latest jQuery
@jacklinkers @galbaras I hear you loud and clear :) but switching to native js has nothing to do with having to update the bundled jQuery to the latest version.
If themes and plugins want to switch to native js, they can do that at any time and stop requiring jQuery as a dependency. This is fully backwards compatible with scripts that are dependent on jQuery.
#111
follow-up:
↓ 112
@
5 years ago
Plain JS is fully easy, intuitive and even way faster than jQuery.
I can't understand the reason WordPress insist jQuery so far in 2020. Apart from themes and plugins,
WordPress Core should not use jQuery, and jQuery should be left as an option for themes and plugins.
#112
in reply to:
↑ 111
@
5 years ago
If it is fully backwards compatible and faster it seems like a wonderful thing. It also gets rid of two security problems left in version 1 of the old code.
#113
follow-ups:
↓ 114
↓ 117
@
5 years ago
@azaozz I guess, then, that switching WordPress itself to native JS and only enqueuing it if it's listed as a dependency anywhere may be a way to take a step forward in core.
One point that may have been missed along the way: the WP version of jQuery is safe, and loaded with ?ver=1.12.4-wp
, yet the security service still identifies it as 1.12.4, because inside the file, that's still the version number.
If there is no major significance to the inline version number, why not just change it and get rid of the security alert? Sure seems like a small, easy change to me.
Another way is to contribute the safe WP jQuery version back to jQuery as version 1.12.5, and change the inline version and URL version, because it will be official.
#114
in reply to:
↑ 113
@
5 years ago
Replying to galbaras:
One point that may have been missed along the way: the WP version of jQuery is safe, and loaded with
?ver=1.12.4-wp
, yet the security service still identifies it as 1.12.4, because inside the file, that's still the version number.
If there is no major significance to the inline version number, why not just change it and get rid of the security alert? Sure seems like a small, easy change to me.
Another way is to contribute the safe WP jQuery version back to jQuery as version 1.12.5, and change the inline version and URL version, because it will be official.
Speaking from direct experience with two different scanning companies in the past year, it gets flagged because it's *not* safe—they test for the known vulnerabilities directly and it comes back with known deficiencies (old and new) in those versions. Changing the version number to try and prevent it from getting flagged is no better than rolling the odometer back so you can say, "See! Low mileage! No problem here!"
#115
@
5 years ago
Not the case here. The test is done on 1.12.4 from jQuery, but the WordPress version is different and has no entry in any report.
#116
@
5 years ago
If it's loaded by WordPress when a site is loaded, it's being tested by the scanning companies, as they're checking for the ability to use exploits specifically, not simply looking at the version numbers and calling it a day.
I repeat: I've worked with two different companies in the past year, and both have done this. Both flagged it not just for being 1.12.4, but for having unpatched vulnerabilities that are fixed in later versions. And they were finding things to flag, even with the software fully updated.
#117
in reply to:
↑ 113
@
5 years ago
Replying to galbaras:
I guess, then, that switching WordPress itself to native JS and only enqueuing it if it's listed as a dependency anywhere may be a way to take a step forward in core.
Right. This is the best way to move to native JS. It is fully backwards compatible, and can be done at any time (not dependent on other changes in core). This is more straightforward for wp-admin as it supports only newer browsers. Would be more problematic for the front-end as generally "all browsers that are currently in use" should be supported.
If there is no major significance to the inline version number, why not just change it...
This may backfire. Even changing the (cache-busting) WP version string to 1.12.4-wp
brought some problems with plugins that were using it for other purposes, see #47342. Thinking that doing the work and updating jQuery is the best course of action :)
#118
@
5 years ago
Noting here that jQuery 3.5 was just released and it includes some important security fixes. The team wanted to save this until 4.0 because it creates a non-trivial amount of code breakage, but we couldn't justify waiting for 4.0 given the severity. We are working on some enhancements to jQuery Migrate that can help identify HTML strings that render differently now.
This ticket was mentioned in Slack in #core-js by azaozz. View the logs.
5 years ago
This ticket was mentioned in Slack in #core by azaozz. View the logs.
5 years ago
#121
@
5 years ago
I would really encourage to resolve this after so many years. I fully support the plan to make WordPress itself native JavaScript and make the latest version of jQuery available to plugin/theme developers to utilize. The upgrade path that @azaozz mentioned a week ago seems the way to go to me. Giving authors and site owners plenty of time to prepare.
This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.
5 years ago
#124
@
5 years ago
Seems that for best results each step should be in a separate release. It will take three WP releases to complete the update.
I like this plan @azaozz! One important piece of work we need to make this possible is ensuring core's use of jquery works correctly when it is upgraded. In my last round of testing, most things worked fine (with the migrate script loaded) - with the notable exception of some customizer features (see https://core.trac.wordpress.org/ticket/37110#comment:47).
For folks who want to contribute to the effort, resolving these core issues would helpful, these are blockers for upgrading our own use.
#125
@
5 years ago
How about introducing theme support for jQuery, which would cause WordPress to enqueue it and allow plugins to check for it and/or add it?
Basically, no matter how many times theme support is declared for jQuery, it will only be enqueued once, and every theme and plugin that needs it can then use it, but WordPress core will work without it.
This should help facilitate the transition, methinks.
#126
follow-ups:
↓ 127
↓ 166
@
4 years ago
Can someone make a plugin and include it with the WordPress update?
If the plugin is turned on by default and it disables jQuery@1.12.4 but we can turn the plugin off to get back the regular jQuery@1.12.4 with an option in the main WordPress settings when the site is broken, maybe it would kind of solve all our problems. No more security bugs and people would slowly look for plugins that work. Also how can we tag plugins in the directory that use jQuery@1.12.4? I would love to have better plugin search filters in the directory (like jQuery version, totally free, freeium, paid, trial, etc.). It's a bit of a pain now having to download and test heaps of plugins as they aren't labeled properly by almost anyone.
I'm happy to test any plugins and tell you if they are easy to use, or maybe I can start making something if I can figure out how to do it.
#127
in reply to:
↑ 126
@
4 years ago
Replying to a4jp.com:
Can someone make a plugin and include it with the WordPress update?
At the top of this thread, there are both a code snippet and a plugin reference for doing what you ask. You can install https://wordpress.org/plugins/jquery-manager/ on your sites and load whichever version of jQuery you like ... at your own risk.
This discussion is about the WordPress core direction with respect to jQuery.
#128
@
4 years ago
Why isn't something like that plugin just including in the core settings? That would be great as a standard setting.
#129
@
4 years ago
The Test jQuery Updates plugin is ready for testing. Please give it a try: https://github.com/WordPress/wp-jquery-update-test.
If the plugin works well, and there are no significant errors while testing, plan is to stop using jQuery Migrate in WP 5.5. If you run into any jQuery related errors while testing, please open an issue at https://github.com/azaozz/wp-jquery-update-test/issues with as much info as possible.
#130
@
4 years ago
Okay @azaozz
Thanks for the links here. Can't wait till the security issues get a fix.
#131
@
4 years ago
- Milestone changed from Future Release to 5.5
Moving to the 5.5 milestone as first step of the update, see comment 105.
In 37110.12.diff: disable jQuery Migrate 1.4.1. Does not remove the jquery-core
script handle for full backwards compatibility. jQuery Migrate 1.4.1 is still in WordPress so it's easy to enqueue if needed.
#133
@
4 years ago
Lets keep this ticket open for a bit longer, in case some tweaks are needed. Made #50564 as follow-up for WP 5.6.
#135
follow-up:
↓ 136
@
4 years ago
- Keywords close added; needs-refresh removed
@azaozz Seems nothing major has come up. Suggesting this be closed out in favor of other more specific individual bug tickets, and continuing to implement the roadmap in #50564.
This ticket was mentioned in Slack in #core-js by pbiron. View the logs.
4 years ago
#139
@
4 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
It appears there are a few plugins out there that will break the admin-side when upgrading to 5.5
Presumably plugins with outdated jQuery, relying on jquery-migrate
to function properly.
Expect alot of core-tickets/support-tickets once 5.5 is rolled out.
This is just a trickle for now. But it's safe to assume there are more out there.
#50820
https://wordpress.org/support/topic/error-when-upgrading-to-wp-5-5-rc1
I've re-opened this because it's not only the plugins themselves not working. They're throwing uncaught errors - and breaking wp-core's functionality. Admin menu script-based submenu hover, screen-meta-links, and presumably other plugins' functionality that relies on javascript.
#140
@
4 years ago
A valid concern, but no matter how we approach this, it _will_ cause ripples like this, jQuery has been in core for so long that it really is a matter of ripping the bandaid off, as they say, or never updating and committing to that.
I suspect the use of .live
will be the most common problem, as I seem to remember it was for jQuery in general when they removed that old function name in favor of .on
.
A quick list of plugins that appear to reference this https://wpdirectory.net/search/01EEHR8NG4D24DGHTGFF8N43QB with a list it is also possible to send a heads up to these specific authors, although the "Are your plugins ready for WordPress 5.5" email also goes out some time around now (shortly after the field guide is posted, pinging @ipstenu as she knows more about that than I)
And for completeness sake, there are themes that reference this function as well, that list can be seen at https://wpdirectory.net/search/01EEHRG42J39A12A0GHBY0CD3G, I don't think there's an email blast for theme authors, but they did get their own field fuide (https://make.wordpress.org/core/2020/07/30/themes-field-guide-wordpress-5-5/) where I've asked to ahve the jQuery stuff added as well :)
#141
@
4 years ago
A valid concern, but no matter how we approach this, it _will_ cause ripples like this
Would it not be possible to add a jquery-migrate-migrate
-type polyfill script with a javascript version of _doing_it_wrong
outputting to console? At least for 5.5?
#142
follow-up:
↓ 155
@
4 years ago
- Keywords close removed
So I've been thinking this over a bit and discussing with @Clorith. Here are some thoughts I have.
There will be breakage during this process, but the bandage has to be ripped off at some point. However, we should try and limit the number of breaks to as few as possible. I have a few thoughts how to whittle down the number of plugins and themes that will actually be affected.
First, I have been thinking about what if a plugin or theme just needs more time to update. This may be a wake up call for them (maybe they did not see the Make Core communication), and they want to update their code but just don't have enough time between now and 5.5. What can we recommend to those authors?
Right now, the only recommendation we could make is to add a really low priority wp_enqueue_scripts
hook that enqueues jquery-migrate
. However that wouldn't be 100% as there is always the possibility another plugin had a lower priority, and was enqueuing something that would cause loading order issues.
jquery-migrate
needs to be loaded after jquery
. Before 5.5, this was controlled by specifying the dependencies for jquery
in order (jquery-core
, jquery-migrate
). Really, jquery
should have been a dependency of jquery-migrate
all along. But because jquery
was a pseudo script handle of sorts, the loading order was enforced through the order of dependencies in the list.
If we update jquery-migrate
to require jquery
, then someone could use this example to re-enqueue jquery-migrate
temporarily.
function myplugin_enqueue_jquery_migrate() { wp_enqueue_script( 'jquery-migrate' ); }
This is a very low risk change that I think can be made during RC (patch incoming). Though there is no guarantee that the site owner updates the plugin or theme with this snippet before updating to 5.5, at least there would be a fix available.
Of course, we would rather developers update their code to be compatible with newer versions of jQuery instead, but it's not unreasonable to expect that some may just need more time. This can only be a temporary fix for them anyway, because step 2 of the roadmap is to update jquery-migrate
to the most recent version.
Since this is also a simple snippet, it becomes much easier to detect plugins and themes calling wp_enqueue_script( 'jquery-migrate' )
or even just 'jquery-migrate'
in the future. This would allow us to search the directory again, and send out some email blasts encouraging devs to be more proactive and give them a true ultimatum and cut off date for when jquery-migrate
will be updated. As much as we like to think that Make Core posts are read by a lot of people, the reach is still limited. Emailing devs directly when their code contains potential issues would hopefully result in more updates. And if it does not, we gave fair and reasonable notice.
My other thoughts are around the links @Clorith included above. Yes, there are 11670 plugins and 1144 themes, but how many of those over a certain active install threshold have been updated recently? Note: none of the numbers below are factual, just trying to determine how we can be more comfortable with the number of affected plugins and themes on the back of a napkin.
Say we look at the number of plugins with 20k active installs or more. That puts the list at around 134 plugins. Then, if we look at the ones in that list that have updated in the last 5 months (the last major release was just over 4 months ago). Say that number is 80%. With 134 plugins having more than 20k active installs (which is a much more manageable chunk than 11k total plugins), 80% is roughly 107 plugins we can reasonably expect to update. I also think it's a reasonable assumption that there is a correlation between more active installs and the likelihood of updating.
Some other ballpark numbers with the plugin results:
- Plugins with 5k or more installs: 434
- Plugins with 1k or more installs: 672
Though the entire list is 11k, I'd argue that all of these are reasonable cutoff points, and each of these points greatly reduces the number of potentially affected sites.
Some other things to consider looking through that search:
- Only 14 of the first 100 plugins have more than one occurrence of
.live()
. - For several of the plugins with 1 occurrence on the first page, the only occurrence of
.live()
is found within a bundled library (most commonly jQuery Colorbox, which has not been updated in over 4 years).
Of course these are only small segments of things that may potentially cause compatibility issues that jQuery Migrate addresses, but I think this is important context to have for the data.
#143
@
4 years ago
Also, I am working to add this as a call out in the Theme field guide and 5.5 Field Guide, but just need to have a more solid recommendation before adding that.
I think this could also deserve an additional post, specifying what is shipping in 5.5 for this roadmap, and how to adjust code.
@azaozz I'll leave that for you to decide since you are spearheading this effort.
This ticket was mentioned in Slack in #core-js by desrosj. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by desrosj. View the logs.
4 years ago
#146
@
4 years ago
How about a more generic Javascript error handler, as was discussed in Javascript chats a long time ago? WP should be more resilient, and catch the errors, but keep working regardless of what plugins and themes do wrong.
#147
@
4 years ago
That's a different topic and ticket, let's keep this about the jQuery migration for now :)
I like the approach proposed in 37110-add-dependency.diff, and also think it makes sense to introduce this simple behind the scenes dependency to make it easier to "un-break" stuff during a period while things are fixed up. We know that not everyone reads field guides, release notes etc, or keep up with them before a release, especially as many plugins and themes are projects of passion, for when people have the spare time, and if we can give them an easy temporary solution so they get the chance to get things right, and doesn't introduce any issues from our end, it's an easy choice.
Worst case, it makes it much easier to help guide a user towards implementing their own hotfix by just adding ~2 lines to a not yet updated themes functions file for example.
#148
@
4 years ago
Just to clarify here, we send the email out _AFTER_ the Field Guide, so we can, y'know, point devs at it ;)
#149
@
4 years ago
The solutions posted above still treat this like it's a plugin-territory problem. When it's the entire wp-core admin-side breaking. These plugins will break wp-core's common.js
functionality.
Even if most offending plugins will promptly fix this, not everyone has automatic updates set on their site/plugins. And I'm not sure how many will opt-in after 5.5 will have introduced this break.
I've no idea about the amount of work needed to create a wp version of jquery-migrate
that logs _doing_it_wrong
messages to console. But I know installations will break. Not everyone can do the whole Health Check & Troubleshooting process and find the offending plugin. They'll just know their site broke when updating to 5.5 (which it will have).
IMO jquery-migrate
could be kept at least for this cycle. Preferably with _doing_it_wrong
messaging to allow for a smoother transition down the line (if that's something that can be introduced in time).
At the very least a .live()
(the most likely offender) should be polyfilled for 5.5 - with debug console logs to alert plugin devs for a whole cycle.
#150
@
4 years ago
jquery-migrate
also doe the console logging, if you bundle the development version, not the production one.
But honestly, logging to the JS console won't help the average user, they don't know that's a thing, if their site breaks, they reach out to support, be that community support, their hosting provider, their agency etc.
So doing more polyfilling won't make more of a difference here, those who know to check the console also knwo to see what caused the error that came up I would argue.
The current roadmap is solid, it was outlined early, we're just looking to sort out an easy way to hotfix it for those who didn't see catch up in time :)
#151
@
4 years ago
- Keywords commit added
I like the patch from @desrosj and am +1 on it's inclusion as it will help ease the transition.
Like others have said, we need to rip the bandaid. Developers have had years to fix these incompatibilities, and over a month since the announcement was made that WordPress 5.5 would include this update.
#152
follow-up:
↓ 153
@
4 years ago
But honestly, logging to the JS console won't help the average user
My suggestion was to keep jquery-migrate
for this cycle so that no plugins will break. The average user would not see anything.
The console logs would be exclusively for plugin devs to print out deprecation notices ahead of 5.6
And again - at the very least .live()
should be polyfilled, with a dev-targeted deprecation notice.
#153
in reply to:
↑ 152
@
4 years ago
Replying to apedog:
My suggestion was to keep
jquery-migrate
for this cycle so that no plugins will break. The average user would not see anything.
If jquery-migrate
stays this release, and gets removed in 5.6, that won't change the fact that plugins and themes that won't update for 5.5 probably won't update for 5.6 either. The exact same predicament will come up during 5.6.
And again - at the very least
.live()
should be polyfilled, with a dev-targeted deprecation notice.
Building a custom polyfill, in my opinion, is not worth the effort or maintenance burden. That is what jquery-migrate
is for.
A deprecated or incorrect usage notice could possibly be thrown when jquery-migrate
is enqueued, but adding back the migrate script would cause every site to throw that notice on every page load that loads jQuery.
#154
follow-up:
↓ 157
@
4 years ago
@desrosj
If my suggestion is to be given serious consideration, then:
- a custom-wp
jquery-migrate
/live
-polyfill that throws out deprecation notes would only need to be maintained for one cycle. - deprecation/doing_it_wrong notices could be made to print only if
WP_DEBUG
is set to true. Same as PHP does. Thereby only targeting plugin devs. - console.log deprecation notices will have a MUCH wider reach than dev- and release-notes. Every single dev will get a chance to see them for an entire cycle. Not on the web - but in their console!
- An entire cycle with the deprecation notes (perhaps even with a 5.6 deadline explicitly mentioned in every log) is more likely to reduce the burden of non-complying plugins. Hopefully, auto-updates will be adopted more widely by then - reducing the risk of breakage even further. Plugins can take their time complying.
- I understand the wish of developers (the majority of decision-makers) to work with modern architecture/tools. Therefore the "bandaid" analogy. Clunky jQuery 1.9 must go. But it doesn't have to be a bandaid. It can be a careful transition.
I'm immensely impressed by the care the auto-updates team has taken to facilitate as smooth a transition as possible and as little breakage as possible. Would love to see the same happen here.
#155
in reply to:
↑ 142
@
4 years ago
Replying to desrosj:
So I've been thinking this over a bit...
Same here :)
Right now, the only recommendation we could make is to add a really low priority
wp_enqueue_scripts
hook that enqueuesjquery-migrate
...
jquery-migrate
needs to be loaded afterjquery
...
There's a way to do this, see the testing plugin: https://github.com/WordPress/wp-jquery-update-test/blob/trunk/class_wp_jquery_update_test.php#L140.
Of course, we would rather developers update their code to be compatible with newer versions of jQuery instead, but it's not unreasonable to expect that some may just need more time. This can only be a temporary fix for them anyway, because step 2 of the roadmap is to update
jquery-migrate
to the most recent version.
Right. jQuery 3.x plus jQuery Migrate 3.x (WP 5.6) will not be backwards compatible with super old code. They require step 5 of this list: https://jquery.com/upgrade-guide/3.0/#jquery-migrate-plugin (latest 1.x without migrate).
Been thinking about what would be the best way to give more time to both plugin/theme authors and users. Perhaps making a simple "back-compat" plugin and releasing it with 5.5 would serve that purpose? As far as I see the plugin can be "fully automatic", detect what version of WP is used and enqueue/change scripts as needed.
This runs the risk of letting some site owners to continue running old code and not updating. Thinking if somebody wants to not update, they will find a way in any case.
On the other hand having a separate (core/canonical) plugin will allow WP to do some "intervention" (perhaps a metabox on the Dashboard for admins?) and ask the users to update their plugins/themes and turn the plugin off. It can also include some code to try to determine when it will be safe to do so.
Some other ballpark numbers with the plugin results:
- Plugins with 5k or more installs: 434
- Plugins with 1k or more installs: 672
Though the entire list is 11k, I'd argue that all of these are reasonable cutoff points, and each of these points greatly reduces the number of potentially affected sites.
Some other things to consider looking through that search:
- Only 14 of the first 100 plugins have more than one occurrence of
.live()
.- For several of the plugins with 1 occurrence on the first page, the only occurrence of
.live()
is found within a bundled library (most commonly jQuery Colorbox, which has not been updated in over 4 years).Of course these are only small segments of things that may potentially cause compatibility issues that jQuery Migrate addresses, but I think this is important context to have for the data.
In theory, if there is a back-compat plugin (see above), and there are many confirmed cases of breakage, WP can ship the plugin as part of core and enable it by default when one of the more common breakage cases is detected. Not sure it this will be needed, but... it's a possibility.
#156
@
4 years ago
Looking at 37110-add-dependency.diff, it makes sense for 5.5, but not for 5.6 when the new version of jQuery Migrate will be enabled.
The downside is that it requires plugins and themes to be changed to enqueue migrate, but this will stop working for very old code in 5.6. Adding this now and removing it for 5.6 seems not a good idea, so perhaps better to not go that way?
#157
in reply to:
↑ 154
;
follow-up:
↓ 159
@
4 years ago
Replying to apedog:
If my suggestion is to be given serious consideration, then:
Just wanted to make sure any disagreement expressed here was not interpreted as not taking any ideas expressed here seriously. Any and all concerns/ideas are taken seriously. But opinions and conclusions will be made when evaluating the information available.
@apedog The outline and plan that you described is exactly what jquery-migrate
does. If a debug mode is on, it will throw console warnings. The 1.4.x version of jQuery Migrate has been in WP core for over 4 years since [37072]. If developers have not noticed these notices with debug mode enabled and fixed them by now, then this method of bringing compatibility issues to their attention is not going to work for the remaining plugins and themes.
I'm immensely impressed by the care the auto-updates team has taken to facilitate as smooth a transition as possible and as little breakage as possible. Would love to see the same happen here.
I don't think this is an apples to apples comparison. Auto-updates (which many folks that have participated on this ticket also helped with that effort, including myself) has been possible since 3.7, but the usage was very low (lower than jQuery 1.12.x by far) because it required developer knowledge, or the use of a plugin specifically meant to enable and manage feature.
The downside is that it requires plugins and themes to be changed to enqueue migrate, but this will stop working for very old code in 5.6
@azaozz If a plugin or theme adds an enqueue for jQuery migrate, they are acknowledging that they are aware of the problem, researched why it happened, and made a purposeful change to temporarily fix the issue. If they then do not update the code in the next 3-5 months before 5.6, then that's on them at that point, in my opinion. If they do update their code, then in 5.6 when jquery-migrate
is updated to the latest version, then there would be no problems as Core intends to re-add migrate as an enqueue. The only difference is that it will be for migrating to a newer version of jQuery.
As for creating a plugin or polyfill to solve this (other than 37110-add-dependency.diff), I am still of the opinion that creating a custom wheel here should be avoided. If it's decided that there is enough potential for breakage that action should be taken, then my vote would be to revert [48323] and use a more aggressive outreach program (emailing plugin and theme authors directly, and often), and retry again in 5.6.
#158
@
4 years ago
Sorry to butt in here, but I'm trying to unsubscribe from trac email notifications for this thread, but can't. I'm not listed as a watcher of this ticket, and I even tried watching and unwatching, but I continue to get the email likely simply because I commented on the issue a few months ago.
Does anyone know why this is happening and what needs to be done to unsubscribe? There's no unsubscribe link in notifications either.
Thanks.
#159
in reply to:
↑ 157
;
follow-up:
↓ 160
@
4 years ago
Replying to desrosj:
If a plugin or theme adds an enqueue for jQuery migrate, they are acknowledging that they are aware of the problem, researched why it happened, and made a purposeful change to temporarily fix the issue.
True. At the same time letting jquery-migrate
be enqueued separately (instead of jquery
) will bring problems/make things messier in the future, when jQuery Migrate is updated. After that too, when it is disabled/removed again in 5.7+. Then the only way to control this would be to remove Migrate from core and fail all these plugins and themes...
So the options here are:
- Add support for direct enqueuing of jQuery Migrate "temporarily" only for 5.5, then remove it in 5.6. This will break all plugins and themes that still use it at that time.
- Add support for migrate and keep it in core "forever". This will make it even harder to update jQuery in the future, almost impossible, considering that some plugins will expect some versions of jQuery with some versions of Migrate, others will expect different, ... :)
As for creating a plugin or polyfill to solve this (other than 37110-add-dependency.diff), I am still of the opinion that creating a custom wheel here should be avoided.
Generally if the core team doesn't create a plugin, somebody else will (in few hours). Then the core team will be "stuck" with having to consider users of that plugin as well, instead of having opportunity to reach users that still need to update old scripts.
If it's decided that there is enough potential for breakage that action should be taken, then my vote would be to revert [48323] and use a more aggressive outreach program (emailing plugin and theme authors directly, and often), and retry again in 5.6.
Yeah, this is also a possibility, but... There will always be some breakage, and always will be need of old code to be updated. Not sure what kind of "aggressive outreach" you have in mind, thinking a good example would be to have a postbox on the dashboards of all WP installs that still have old scripts. That would be doable by a canonical plugin, would also be doable directly in core, but..? :)
#160
in reply to:
↑ 159
@
4 years ago
Replying to azaozz:
True. At the same time letting
jquery-migrate
be enqueued separately (instead ofjquery
) will bring problems/make things messier in the future, when jQuery Migrate is updated.
I think I feel the same way about this as I do about intentionally adding the migrate enqueue. Expecting migrate to be updated the future is something that would then be expected.
- Add support for direct enqueuing of jQuery Migrate "temporarily" only for 5.5, then remove it in 5.6. This will break all plugins and themes that still use it at that time.
The current plan is to remove migrate after the jQuery update is shipped (which would be the more likely breaking change). Calling wp_enqueue_script()
on an unregistered script would just result in nothing happening.
- Add support for migrate and keep it in core "forever". This will make it even harder to update jQuery in the future, almost impossible, considering that some plugins will expect some versions of jQuery with some versions of Migrate, others will expect different
If we can get jQuery to the latest version, and then update every time there is a release, we can bring jQuery more inline with how other External Libraries are maintained, with an expectation that you keep plugin code up to date. We include external libraries all the time that potentially have breaking changes. The difference is that they are updated regularly. I don't know why we couldn't establish the same pattern here.
Not sure what kind of "aggressive outreach" you have in mind, thinking a good example would be to have a postbox on the dashboards of all WP installs that still have old scripts.
"emailing plugin and theme authors directly, and often" was what I had in mind initially. This could also be combined with any combination of a WordPress.org News post calling this out, outreach to various WP related news sources with requests to publish articles, maybe WordCamp talks or workshops helping devs update, etc. The exact communication plan could be discussed and refined to ensure maximum reach.
@archon810 sorry, I am not aware of a way to unsubscribe from a ticket when you have commented on it previously.
This ticket was mentioned in Slack in #core by desrosj. View the logs.
4 years ago
#162
@
4 years ago
The outline and plan that you described is exactly what jquery-migrate does [...] this method of bringing compatibility issues to their attention is not going to work for the remaining plugins and themes.
Not exaclty the same. That's jquery-migrate throwing those notices. Not wp-core. There never was any need to fix those issues. They could be safely ignored. jquery-migrate would pick up the slack. It's not the same as wp-core giving specific notice about WP deprecation of jquery-migrate. Perhaps with links to the relevant notes. That's "aggressive" outreach :) A canonical plugin for this purpose would work. Keeping core clean of any transitional fix.
I still think giving an extra cycle for users to enable auto-updates, and then for plugin devs to be notified (via canonical plugin/console, email or both) of this deprecation will lead to a smoother transition and less user-side breakage. Breakage (of core's common.js
) upon upgrade is guaranteed as things stand now. There are simply enough plugins in use today that rely on jquery-migrate, and not enough (any) users auto-updating to avoid that. Auto-updates needs to go in first.
This might mean pushing some of the jQuery Upgrade milestones back by one.. :(
@archon810 "Trac UI Preferences" link at bottom right of this page allows adding "Never Notify" subscription rules. That might do the trick.
#163
follow-up:
↓ 169
@
4 years ago
I only wanted to unsubscribe from this thread, but get notified otherwise when I reply to future threads. What Trac should be doing is synchronizing the notification status with the "Watch this ticket" status, allowing granular unsubscriptions from individual posts. It seems to be a bug or limitation of Trac then? Oh well.
#164
@
4 years ago
Are you considering the point of view of the plugin devs?
To support multiple versions of WP, they could need different sets of code, because they are always supposed to use the version of scripts that are bundled in WP.
I don't quite understand why the migrate script would be removed in 5.5 and jQuery left alone, waiting for the next release to update to a newer jQuery. Why isn't it at the same time, so there's no gap?
#165
follow-up:
↓ 167
@
4 years ago
37110-add-dependency.diff
Why is the same jQuery script added twice, with only the 'jquery'
handle referenced later?
there are 11670 plugins and 1144 themes
Despite the wide variety of plugins and themes in the repository, let's keep in mind those available from other sources, the authors of which may not be contactable by email like wp.org authors. Specifically for themes, I'd say that's the majority of sites out there.
Either way, step 1 is to ensure that WordPress works correctly with the latest standard theme and no plugins. Then, there should be a way for specific site owners to enable jQuery and/or Migrate specifically for their site, until most people adapt.
Ultimately, isn't this like any deprecation?
#166
in reply to:
↑ 126
@
4 years ago
Replying to a4jp.com:
Also how can we tag plugins in the directory that use jQuery@1.12.4?
Not sure if this has been discussed elsewhere and if it was, please ignore this comment.
This is a good point. I see the conversation on this ticket mainly focuses on what will happen to users who have offending plugins already installed and active. What about offending plugins that are going to be installed?
Will the WordPress plugins directory list offending plugins with no warning they will break the admin? Not sure how it can be done from a technical perspective, but I'd say that at the very least all plugins that use jQuery live()
should be clearly marked as: "This plugin is not compatible with WordPress 5.5 and later".
#167
in reply to:
↑ 165
@
4 years ago
Let's not forget that the .live feature was removed from jQuery 7,5! years ago. Plenty of time for everyone to take a serious look at their codebase and improve things. As a plugin developer that's the thing you commit to. That being said, I think it is time to pull the trigger in 5.5 and not wait any longer. Yes, there will be loads of topics, yes, quite some admin pages will break but let's hope it will be a wake up call for many of the developers.
An e-mail to the mentioned plugin/theme authors to inform them about the upcoming change would be a good thing to do. Warning site owners about incompatible plugins even better.
Despite the wide variety of plugins and themes in the repository, let's keep in mind those available from other sources, the authors of which may not be contactable by email like wp.org authors. Specifically for themes, I'd say that's the majority of sites out there.
Regarding external plugins and theme's outside the repositories: these are mainly premium anyway and people make a living out of them so it's even more of a wakeup call to them to ship good products.
This might be a harsh statement to many of you but something has to happen, this is slacking for way to long and there is no pretty way to do it.
#168
@
4 years ago
Don't waste your time on jQuery. It's 2020, not 2010!
Vanilla JS is fully sweet, easy and even fast!
#169
in reply to:
↑ 163
;
follow-up:
↓ 170
@
4 years ago
Replying to archon810:
I only wanted to unsubscribe from this thread, but get notified otherwise when I reply to future threads. What Trac should be doing is synchronizing the notification status with the "Watch this ticket" status, allowing granular unsubscriptions from individual posts. It seems to be a bug or limitation of Trac then? Oh well.
This used to work in the past, but has been broken for a while now after one of Trac updates. See #meta3594 for more details.
#170
in reply to:
↑ 169
@
4 years ago
Replying to SergeyBiryukov:
Replying to archon810:
I only wanted to unsubscribe from this thread, but get notified otherwise when I reply to future threads. What Trac should be doing is synchronizing the notification status with the "Watch this ticket" status, allowing granular unsubscriptions from individual posts. It seems to be a bug or limitation of Trac then? Oh well.
This used to work in the past, but has been broken for a while now after one of Trac updates. See #meta3594 for more details.
Thanks for the link. Wow, the bug is now 2 years old.
#171
follow-up:
↓ 172
@
4 years ago
Looking a bit more at 37110-add-dependency.diff, it may introduce a circular dependency (jquery
depends on jquery-migragte
, and jquery-migragte
depends on jquery
) if a plugin restores the way the jquery
script-handle used to work in WP 5.4 and earlier. For example the https://github.com/WordPress/wp-jquery-update-test does this with the appropriate settings, see https://github.com/WordPress/wp-jquery-update-test/blob/trunk/class_wp_jquery_update_test.php#L59.
If core has to provide an easy way for plugins and themes to still be able to load jQuery with jQuery Migrate in WP 5.5, something like 37110-add-dependency.2.diff will be preferable. Then, once jQuery is updated to 3.x, the temporary script-handle can be removed. This means plugins and themes that still use it at that point will fail to load their scripts (as a dependency will be missing), but will not cause "fatal errors" breaking the rest of js.
#172
in reply to:
↑ 171
@
4 years ago
37110-add-dependency.3.diff just fixes a typo in the inline comment: "relying" vs. "relaying".
This ticket was mentioned in Slack in #core-js by desrosj. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by azaozz. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by desrosj. View the logs.
4 years ago
#176
follow-up:
↓ 180
@
4 years ago
I just posted a lengthy summary of some more research I did with @Clorith in #core. I am posting here for anyone that is not in Slack or following #core.
I have been doing some experimenting and testing on different plugins that were flagged in the list of ~11k as potentially breaking when jQuery Migrate is not loaded. As I started to dig in, though, there were a ton of false positives.
The original plugin search was flagging 9 different functions/patterns that may cause issues. This paints a complete picture of everything that could break when jQuery gets upgraded to 3.x. But that's not what we need to be looking at right now. We need to be looking at what plugins or themes could break if jQuery Migrate is not loaded and jQuery 1.12.x is loaded (the version currently shipping with WordPress).
That whittles down the list of functions/patterns to 6. These will cause deprecated notices in the console, but they will not break sites until jQuery is upgraded to 3.x. This only decreases the number of results by a few hundred. However, there are still a very large number of false positives.
There are two uses for load, a way to inject content from a remote source is removed in 1.9, but the same function used as a shortcut for .on('load') is not removed until 3.x. The latter needs to be weeded out of the results. Also, Colorbox (a common lightbox script back in the day) is packaged with many plugins and themes. But this library contains a compatibility check, only using load incorrectly if jQuery <1.9 is being loaded.
I was just working with @clorith, and he was able to massage the regex search to account for these false positives. This results in ~2400 plugins with the potential to break when jQuery Migrate is disabled upon upgrading to 5.5.
There are still some Colorbox false positives for plugins and themes that have slightly older versions of the library, and some compatibility checks (I spotted 3-4 on a quick scan of the first page of results), but this is significantly less than the original list that we have been using in the discussions so far, and there are NO plugins with over 1m active installs on the list (the only one there is a false positive).
For themes, these changes to the search bring the results from ~2600 themes to ~250 themes, with only 5 having more than 10k active installs.
With this updated information in mind, I think that we are on the right path for proceeding as is (disabling jQuery Migrate in 5.5). We should still make it easy for plugin/theme developers to re-add Migrate if they need more time. The plugin that is being built should still be released and plugin devs/site owners can still install this if they need more time updating their code (and don't want to re-enqueue it themselves) or experience any issues upon upgrading to 5.5.
But I wanted to summarize this information here for further discussion, just in case @clorith and I are misinterpreting something.
With all this in mind, I think 37110-add-dependency.3.diff is a low risk way to add a way for devs to re-enable jQuery Migrate, and can be complicated with the jQuery Tester plugin that @Clorith and @azaozz are working on (for non-devs, and those that don't want to add a code snippet). 37110-add-dependency.3.diff will not break anything when we remove it along with the jQuery 3.x and jQuery Migrate update in step 2.
#177
@
4 years ago
- Owner set to SergeyBiryukov
- Resolution set to fixed
- Status changed from reopened to closed
In 48753:
#178
@
4 years ago
- Keywords dev-feedback added
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening for the 5.5 branch.
This ticket was mentioned in Slack in #core by sergey. View the logs.
4 years ago
#180
in reply to:
↑ 176
@
4 years ago
Replying to desrosj:
Thanks for doing this and posting the summary!
With all this in mind, I think 37110-add-dependency.3.diff is a low risk way to add a way for devs to re-enable jQuery Migrate...
Thinking more about this, not really sure it is a good idea. The "official" way to re-enable migrate is the core plugin. It will be supported and updated as needed for WP 5.5.x, 5.6, etc.
If other plugins are willing to re-enable migrate without the official plugin, they are free to do so. However they will have to take responsibility to maintain their code. Thinking there's no need of more "temp hand holding" there :)
#181
@
4 years ago
Just for the record: There are two plugins associated with this ticket:
- Test jQuery Updates, https://github.com/WordPress/wp-jquery-update-test, is for testing different versions of the jQuery libraries. It is not intended for production.
- Enable jQuery Migrate Helper, https://github.com/WordPress/jquery-migrate-helper, is for re-enabling of jQuery Migrate in WordPress 5.5 (in case some old js code needs it). It is intended for production. It will show the warnings coming form migrate to site admins, so they are informed and can take steps to fix them.
#182
follow-up:
↓ 184
@
4 years ago
Based on the above, thinking it's probably better to not add the jquery-migrate-compat-5.5
script handle for now. There are few more days of testing until the release. The handle can be re-added if a compelling reason is found.
#184
in reply to:
↑ 182
@
4 years ago
- Keywords commit dev-feedback removed
Replying to azaozz:
Based on the above, thinking it's probably better to not add the
jquery-migrate-compat-5.5
script handle for now.
Yes, with the considerations above, I agree this is not necessary. Thanks for the comments and for handling the revert :)
This ticket was mentioned in Slack in #core by mike. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by mgol. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by david.baumwald. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
#192
@
4 years ago
- Milestone changed from 5.6 to Future Release
Moving to Future Release for now to avoid confusion, as this was only left open as a tracking ticket, and the milestone for 5.7 is not created yet.
- For step 2 in WordPress 5.6, see #50564.
- For step 3, a new ticket should be created as well.
#194
@
4 years ago
- Milestone changed from Future Release to 5.7
Moving into 5.7
Moving to Future Release for now to avoid confusion, as this was only left open as a tracking ticket, and the milestone for 5.7 is not created yet.
This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-test by hellofromtonya. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-test by hellofromtonya. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-test by hellofromtonya. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-test by hellofromtonya. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by chaion07. View the logs.
3 years ago
#207
@
3 years ago
Thanks @jorbin for reporting this. As we discussed this ticket during a recent bug-scrub session, we still don't have any actionable items. Considering jQuery migration being a long term, multi-release project; the team is aiming for small steps to be made during the 6.0 cycle.
Props to @peterwilsoncc
Cheers!
This ticket was mentioned in Slack in #core by chaion07. View the logs.
3 years ago
#209
@
3 years ago
- Milestone changed from 6.0 to 6.1
With 6.0 RC1 tomorrow, moving this to the 6.1 milestone for work to continue.
This ticket was mentioned in Slack in #core by chaion07. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
#212
@
3 years ago
- Resolution set to fixed
- Status changed from reopened to closed
The upgrade to jQuery 3.5.1 was implemented in [49101], and released with version 5.6; With that in mind, I'm marking this ticket as fixed for the purpose it was created.
Given that the final step is to not have jQuery migrate enabled by default (which has its own ticket in #51812), and any areas that may have been missed should get their own tickets so they are not missed in a massive tracking ticket, it just makes sense to not create an overburdened ticket that is hard to keep track of for any new items that may pop up.
For part of this, I think we should see if we can make changed to wp-admin can support both the 1.12 and 3.0 versions, which will make it easier to eventually switch. This would enable a plugin to provide 3.0 and make it easier for other plugins and themes to test jQuery 3.0. This piece may be worth doing as early as 4.5 (and can be split off to a separate ticket if we think it's worth it).