[wp-trac] [WordPress Trac] #37110: Update to jQuery 3.*

WordPress Trac noreply at wordpress.org
Fri Jul 31 14:41:44 UTC 2020


#37110: Update to jQuery 3.*
-------------------------------------------------+-------------------------
 Reporter:  jorbin                               |       Owner:  (none)
     Type:  task (blessed)                       |      Status:  reopened
 Priority:  normal                               |   Milestone:  5.5
Component:  External Libraries                   |     Version:
 Severity:  critical                             |  Resolution:
 Keywords:  early has-patch needs-testing        |     Focuses:  javascript
  needs-screenshots has-dev-note                 |
-------------------------------------------------+-------------------------
Changes (by desrosj):

 * keywords:  early has-patch needs-testing needs-screenshots close has-dev-
     note => early has-patch needs-testing needs-screenshots has-dev-note


Comment:

 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 [https://wpdirectory.net/search/01EEHR8NG4D24DGHTGFF8N43QB 11670
 plugins] and [https://wpdirectory.net/search/01EEHRG42J39A12A0GHBY0CD3G
 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/37110#comment:142>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list