WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 5 weeks ago

#37110 new task (blessed)

Update to jQuery 3.*

Reported by: jorbin Owned by:
Milestone: Future Release Priority: normal
Severity: critical Version:
Component: External Libraries Keywords: early has-patch needs-testing needs-dev-note needs-screenshots needs-refresh
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 (11)

37110.diff (398.9 KB) - added by adamsilverstein 3 years ago.
37110.2.diff (494.1 KB) - added by adamsilverstein 3 years ago.
37110.3.diff (532.1 KB) - added by adamsilverstein 3 years ago.
37110.4.diff (189.7 KB) - added by adamsilverstein 3 years ago.
37110.5.diff (370.5 KB) - added by adamsilverstein 2 years ago.
37110.6.diff (4.9 KB) - added by adamsilverstein 2 years ago.
37110.7.diff (14.2 KB) - added by adamsilverstein 2 years ago.
37110.8.diff (13.9 KB) - added by adamsilverstein 2 years ago.
37110.9.diff (4.3 KB) - added by adamsilverstein 2 years ago.
37110.10.diff (1.7 KB) - added by adamsilverstein 2 years ago.
37110.11.diff (7.5 KB) - added by westonruter 2 years ago.

Download all attachments as: .zip

Change History (132)

#1 @jorbin
4 years ago

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).

#2 follow-up: @ocean90
4 years ago

Previously: #24132

#3 in reply to: ↑ 2 @jorbin
4 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.


4 years ago

#5 @ocean90
3 years ago

#39160 was marked as a duplicate.

#6 @ocean90
3 years ago

  • Summary changed from Update to jQuery 3.0 to Update to jQuery 3.*

#7 @bkerensa
3 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.

#8 @Presskopp
3 years ago

FYI: jQuery 3.2.1 Is Now Available (2017-03-20)

#9 @westonruter
3 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 @westonruter
3 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 @adamsilverstein
3 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 @jorbin
3 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 @adamsilverstein
3 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 @adamsilverstein
3 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 @adamsilverstein
3 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. We may want to upgrade jQuery UI at the same time, several of the warnings I fixed were JQuery UI modules.

Last edited 3 years ago by adamsilverstein (previous) (diff)

#16 @zakkath
3 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 @jorbin
3 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 @ocean90
3 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: @retlehs
3 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: @pento
3 years ago

Replying to retlehs:

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].

#21 in reply to: ↑ 20 @retlehs
3 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].

Whoops. Thank you.

#22 @westonruter
3 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 @Presskopp
3 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 @westonruter
3 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 @onokazu
3 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

Last edited 3 years ago by onokazu (previous) (diff)

#26 follow-up: @onokazu
3 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 @bkerensa
3 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.


3 years ago

#29 @galbaras
3 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: @adamsilverstein
3 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.


2 years ago

#33 follow-up: @bigcloudmedia
2 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 @zakkath
2 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.

#35 @adamsilverstein
2 years ago

#43694 was marked as a duplicate.

#36 @dmethvin
2 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 @adamsilverstein
2 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 @adamsilverstein
2 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.

Last edited 2 years ago by adamsilverstein (previous) (diff)

This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.


2 years ago

This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.


2 years ago

#41 @adamsilverstein
2 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.


2 years ago

#43 @LittleBigThing
2 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 @LittleBigThing
2 years ago

Also, you don't need to change it in src/wp-admin/includes/class-wp-internal-pointers.php on line 140

#46 in reply to: ↑ 45 @netweb
2 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 @adamsilverstein
2 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.


2 years ago

@westonruter
2 years ago

#49 @westonruter
2 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 at DOMContentLoaded.
  • Switch from jQuery(window).load() to jQuery(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

#50 @adamsilverstein
2 years ago

Thanks for giving it a pass @westonruter!

#51 in reply to: ↑ 30 @markgoho
2 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?

Last edited 2 years ago by markgoho (previous) (diff)

#52 follow-up: @Presskopp
2 years ago

@markgoho Milestone is 'Future Release' - smells like 5.0

#53 in reply to: ↑ 52 @markgoho
2 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 @dmethvin
2 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: @adamsilverstein
2 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 @adamsilverstein
2 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: @dmethvin
23 months 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 @DavidAnderson
23 months 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.


22 months ago

#60 @daverobinsonpw
22 months 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 @adamsilverstein
22 months 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 @iandunn
21 months 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.

#63 @Clorith
20 months ago

#45015 was marked as a duplicate.

#64 @remzicavdar
20 months 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

Last edited 11 months ago by remzicavdar (previous) (diff)

#65 @swissspidy
19 months ago

#45310 was marked as a duplicate.

#66 @chriscct7
17 months ago

#45953 was marked as a duplicate.

This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.


17 months ago

#68 @pento
17 months ago

#45953 was marked as a duplicate.

#69 @tw0flower
15 months 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.


15 months ago

This ticket was mentioned in Slack in #core by clorith. View the logs.


13 months ago

#73 @remzicavdar
11 months 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:
https://i.ibb.co/VS6FSR2/screenshot-1.png
https://i.ibb.co/4R2S0Nz/screenshot-2.png

Last edited 11 months ago by remzicavdar (previous) (diff)

#74 follow-up: @kevindaum
10 months 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 @bigcloudmedia
10 months 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.


10 months ago

This ticket was mentioned in Slack in #core-js by adamsilverstein. View the logs.


9 months ago

#78 follow-up: @jacklinkers
7 months 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: @remzicavdar
7 months 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.


7 months ago

#81 in reply to: ↑ 79 @jacklinkers
7 months 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 @remzicavdar
6 months 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 );
Last edited 6 months ago by remzicavdar (previous) (diff)

This ticket was mentioned in Slack in #core by clorith. View the logs.


6 months ago

This ticket was mentioned in Slack in #core by ipstenu. View the logs.


5 months ago

#85 @a4jp.com
5 months 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.


https://a4jp.com/test/bugs/Screen-Shot-01-11-20-at-12-14-AM.PNG

#86 @galbaras
5 months 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 @Dani3l3
4 months 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: @a4jp.com
4 months 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 @jacklinkers
4 months 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: @galbaras
4 months 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: @bigcloudmedia
4 months 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: @galbaras
4 months 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 @collinmanderson
4 months 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!

#94 in reply to: ↑ 92 @SergeyBiryukov
4 months ago

Replying to galbaras:

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?

That's exactly what was done in [45342] / #47020.

#95 @galbaras
4 months 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 @bigcloudmedia
4 months 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 @nasiralamreeki
4 months 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.

#98 @max2348
3 months ago

Do we know which famous plugins are still relying on old jQuery?

#99 follow-up: @stokim2012
3 months 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 @archon810
3 months 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 @a4jp.com
3 months 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?

Last edited 3 months ago by a4jp.com (previous) (diff)

#102 in reply to: ↑ 99 @getsnoopy
2 months 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 @yongkai
2 months 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?

#104 @tpainton
6 weeks ago

It appears to have been backported.

https://core.trac.wordpress.org/ticket/47020

#105 @azaozz
6 weeks 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:

  1. Disable jQuery Migrate 1.x.
  2. Update to jQuery 3.x and jQuery Migrate 3.x.
  3. 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 @jacklinkers
6 weeks 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.

Last edited 6 weeks ago by jacklinkers (previous) (diff)

#107 @galbaras
6 weeks 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: @bigcloudmedia
6 weeks 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 @galbaras
6 weeks 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 @azaozz
6 weeks 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.

Last edited 6 weeks ago by azaozz (previous) (diff)

#111 follow-up: @stokim
6 weeks 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.

Last edited 6 weeks ago by stokim (previous) (diff)

#112 in reply to: ↑ 111 @a4jp.com
6 weeks 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: @galbaras
6 weeks 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 @bigcloudmedia
6 weeks 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 @galbaras
6 weeks 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 @bigcloudmedia
6 weeks 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 @azaozz
6 weeks 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 :)

Last edited 6 weeks ago by azaozz (previous) (diff)

#118 @dmethvin
6 weeks 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.

https://jquery.com/upgrade-guide/3.5/

https://github.com/jquery/jquery/issues/4681

This ticket was mentioned in Slack in #core-js by azaozz. View the logs.


6 weeks ago

This ticket was mentioned in Slack in #core by azaozz. View the logs.


5 weeks ago

#121 @Levdbas
5 weeks 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.

Note: See TracTickets for help on using tickets.